A new revision of the Snapchain paper is now out. 

It might be one of the most important improvements we've made to the Farcaster experience. 

- Message delays will be fixed 
- Adding apps will cost nothing 
- Removing apps won't delete data 

https://warpcast.notion.site/Snapchain-v2-Public-10e6a6c0c101807aadfacbcddda8ce4f

Snapchain read together.

Let's go through it live. I haven't read the current iteration, excited to see

Snapchain read together.

Let's go through it live. I haven't read the current iteration, excited to see 
https://events.xyz/events/87fbe2

Developer 🤓 build, develop and operate Farcaster solutions @ dtech.vision also love tech, decentralization, fitness and oldschool rap 😎

LIVE https://youtube.com/live/O2niSA8aRvQ

BDFL of Quilibrium, Eng @ Farcaster, ex-Coinbase, always opinionated, never hydrated

/quilibrium

"Snapchain is a replacement for Farcaster’s deltagraph that solves this problem. It uses the blockchain pattern to introduce ordering and achieve real-time delivery"

@cassie calls this a Timechain see https://youtu.be/9P3eTJl9ZlY

I see "app keys" mention a lot in the Snapchain proposal once snapchain launches can we then rebrand it everywhere from signer to app key? like also in the spec and docs everywhere? 

"Transactions are broadcast into a mempool and then sequenced into blocks. A block contains blockchain and snapchain transactions along with a link to the previous block, a signature from the block producer and the global state root. The root is computed by creating a global state trie whose leaves are the state roots of each account. "

The above clearly sounds like eventually to prove honesty and keep each snap producer honest there will be stakes/slashing or some other mechanism but since each producer is uniquely identified it can work just like Ethereum, Bitcoin and other blockchains do it. So the path to decentralization looks like figuring that system out and getting there

now replace Mainchain with Snapchain and you have a visualisation for how sharding and who validates what in Snapchain will work (taken from the Near Nightshade paper Figure 17)

though take note:
"
A shard chain must have at least three validators and store all relevant account state. Validators may be automatically or manually rotated between shards through a validator schedule in the epoch block. Erasure coding is used to distribute account state from one shard across validators in other shards so that the data is still available even if all validators within a shard fail. 
"

THE BEST PART IS SYNC!!!!

Why?

First because if you run a read hub then you can now subscribe to only the shards (set of FIDs) you care about!!!! and not recieve traffic or anything else for what you don't care about (if we are at per FID sharing, not today but likely later)

AND you can check for real! if you have the latest state so a readyness check can be made to see if that hub should be read from or not! Lovely for any K8s user <3 as K8s can handle all that routing complexity just based on you defining a readyness check

Re Governance:

it is of utmost importance that no 2/3 majority in any setting gets formed.

Say two countries are at war. And one country censors the other and vice versa, then we should never have one of these have a 2/3 majority. and that needs to be planned and accounted for.

ALso if some have veto rights (reading Appendix in a bit) then UN style blocking and in action to remove malicious validators should be accounted for so it always happens somehow.

Acknowledgements, can we add @vrypan.eth cc @v I think it is highly deserved to have @vrypan.eth in the acknoledgments of Snapchain

"A user’s account state is a set of blockchain and snapchain transactions. A new transaction either adds itself to the account state or replaces or deletes a prior transaction. "

THis also means less state growth as we the deletion of overwritten messages (e.g. unlike -> remove the like in the first place) ensures minimal use of storage