well I like your proposals and in-network and blockchain improving is the key I hope whenever HF25 OR MORE HF26,27 HAppen successfully 

Best signals, and trade bot! - https://jamm.to/
Best signals, and trade bot! - https://jamm.to/
Best signals, and trade bot! - https://jamm.to/
Best signals, and trade bot! - https://jamm.to/

The foundation layer needs to be finished. It needs to be protected, and that means the witness selection/retention system really does need a solid overhaul. I know people will scream all day long that what happened on steem can not happen on Hive, it needs to be foolproof. How many **dead** witness accounts are there? How many are current and up to date? A strong witness system will enable a lot more confidence in those that want to look at working with Hive Block Chain in a layer two system.

I see no problem with trying to protect the foundation layer from spam token, spam smart contracts. Right now there is nothing stopping anyone from building their own Hive Engine style place on Hive. No reason for others to not be able to build NFT type places either. Look at the number of games being built there was no *"you can't do that"* cause I did coming from you. If I remember correctly over on steem you even tried to help a few. 

You have shown people what the second layer can look like how it can function and how **valuable** it can be.

So witness selection/retention, and resource credit sharing are two of the things I would like to see to help solidify the foundation layer of Hive. Just a Hive users opinion.

As someone that was working on a layer 2 solution I've always appreciated your opinion on competition, and couldn't agree more. Documentation, easy on-ramps, and things of that nature are key to getting more apps on the chain.  

WordPress has a really lightweight core and then a huge ecosystem of plugins anyone can install to add the functionalities they want. I think this design principle was critical to the massive success of WordPress. People can use Hive for the basics and for any additional functionalities beyond the lightweight core they can use second-layer stuff that provide what they're interested in.

In regards to Lite accounts, did you see what Leofinance has already created? - https://peakd.com/hive-167922/@khaleelkazi/durnibxb

Good post, didnt know anything about the layer program before. Can you relate me to other post talking about this?

Its true that a fast an free of fees chain is one of the strongest points in hive. 

The worst problem is the SEO and the search system on the blockchain... Damn is preety bad, always was bad... But now with more data is just getting worse [HiveSearcher](https://hivesearcher.com/) is a great adition but almost no front end uses it.

There is a long way to create a perfect system but i think we are going in the right path. If you ask me i guess its prioritary to do something about that SEO thing...

You said it several different ways, but the one I like best is:

>Just, if the goal is to make Hive a great place for apps, let's not fuck up the one technical thing that we really have going for us and kill the fast, steady, free, and scalable block production by throwing a crap ton of smart contracts into the layer 1.

Count on all my support and whatever I can ever do to help!

What does the Hive-Keychain basically consist of?

imo we haven't got HF24 right and people are thinking about HF25 🤦‍♂️ 
<div class="pull-left">
    <center>
        <img src="https://www.cannon-linux.co.uk/wp-content/uploads/2020/09/SharingCaring.png" />
    </center>
</div>
<p>I shared this post on Twitter to try and get your work in front of more people.<br>
You can find your post and me on Twitter if you like? https://twitter.com/dick_turpin<br>I've also upvoted you and shared your content on Hive.<br>I read your post.  No Bots were used this was all done manually. Hope That Helps.</p>
<hr>
<center><em>"If you don't have enough power or Crypto to upvote me; reshare me instead. Reshares are worth their weight in gold!"</em><br />
<b>Don't forget, you can upvote peoples comments too!</b></center>

> Lastly, if we're going to get apps to develop here or board here there needs to be a focus on making sure all the libraries are easily accessible, readable, code is up to date, and as many examples are given in as many ways as possible.

This right here. I have chatted with @patrickulrich and others that there should be some written and video tutorials on how to interact or build dapps on the Hive blockchain. There are many video tutorials on youtube on "how to build a dapp". But guess which blockchain almost all of those tutorials use? Ethereum.  I did find one tutorial which used the Tron chain, but all the rest were for the ETH chain. 

I know we have some pretty awesome devs and content creators here on Hive. I would love it if a few of them would be willing to make some how to's on working with the Hive chain. And with those video's and written content that could possibly get more developers over here to make stuff or move their projects to Hive. 

I agree with you, the layer 1 shall be stable, fast, and preferably not complex. Am not too technical to understand what this means. I do think we need SMT as part of the core. Again, am not technical enough to determine if 'core' means layer 1, or if that is layer 2.

Your reasoning wrt Smart Contracts and such feature will result into none-scalable services build into smart contracts, I think is a weak argument against adoption of smart contracts to HIVE. In the end the robust, performing and scalable services will find mass adoption. Any service that can't keep up with increase of usage, will simply fail. This is regardless of implementation of services on whatever layer in whatever form.

If we need smart contracts as part of the core of HIVE? Again, am not qualified enough to take a position on it. That said, I do like the aim of the KOINOS team. They state they are designing a blockchain tackling all the core problems of any chain around: essentially robustness, scalability and modularity. They include smart contracts. They even intend to implement consensus algorithms as smart contracts to avoid the constant hardfork-ing we have at our HIVE chain. Are they wrong? I don't know, but their story sounds good and that team has a lot of knowledge of the HIVE chain. And I believe we shall stop all the hardforks. HF's leeds to unnecessary disruptions of the layer 1 which needs to be robust and stable, 24x7!

> We should be able to talk to a group with an existing app with an existing community and talk through how we could bring their thousands or millions of users here, have the app continue to function, and how the blockchain will handle that additional traffic.

Definitely we need to get to this! ASAP! Not sure what you mean with bringing those communities over to HIVE. I see it likes this: We enable other communities to make use of HIVE, but they don't have to come to HIVE. I mean: we enable eg tokenisation of xyz community by integrating into their own service. Tokens can be tradable tokens as we have them on our layer 1, and in HIVE Engine (layer 2 I suppose?). But tokens could also be just loyalty points, or stable tokens. Not sure what we need to allow these use cases, but I don't believe in the world coming to HIVE. HIVE needs to go to the world, and that starts with a B2B approach, and leaving the communities where they are; We just need to add HIVE features to their service; Thats it :)

I tried to voice my idea of tokinsed comments to 3rd part services in a recent post. In case you are interested; check this link: https://3speak.co/watch?v=edje/yzybtpbk

To finish: 3 seconds is fast, but it is not fast enough imho. Can't we get to 1 second? Some chains around can go as fast as 1 second. Waiting is something the mass won't do. When something else is faster, the mass will move to the faster service. It is as simple as that. Now, we may not need to be as fast as 1 second today, but I always learned from great software architects: The foundation is where the time is to be spend and needs to be developed in a solid way, before the rest is build on top of it. The more is build on top of the foundation, the less likely its gonna be the foundation is re-architected. Thats why in the software industry, a popular service/application is rebuild a few times from the ground up in its lifecycle. Most software and services are not well architected from the ground up, at day one; As you may know very well yourself.