An individual person's data under the AT Protocol is a signed chain of operations. A repository host is expected to always serve the most recent version of the repository to anyone who asks for it. The repository can survive the death of the host by being transferred to another host, and any responsible host is expected to facilitate these transfers. Repositories are also likely to be backed up in distributed storage, so even when hosts don't actively facilitate transfers, their state will basically always survive them.
The expectations placed on hosts correspond fully to the special features that allow blockchains to play host to decentralized finance, only instead of being proved by cryptography and game theory, they're going to be not-quite-proved by organizational incentives, monitoring, and possibly government audits and legal obligations, which are not as strong as proofs, and many in crypto would argue that they're not sufficiently strong for AT Protocol to be applicable to finance, and especially not strong enough for the AT Protocol to be preferred over other ledgers.
However, the AT Protocol has 6 million users (bluesky), and it has no scaling limits (consensus only requires checking in with a set of hosts who you trust not to collude).
No one plans for the AT Protocol to develop into a finance host, but it's almost inevitable that someone will build that functionality. And everyone will say, "Don't use the smart contract extensions, it's not as secure as a real ledger, and the trust model makes it prone to centralization," and even AT's authors might be saying this. But some people will use it for finance anyway, and then there will probably be no attacks on any major hosts, and people will keep using it for finance, and eventually enough people will be using it for finance that it'll settle over people that we didn't ever strictly need cryptographic or game theoretic proofs to build a system of computers that could be trusted to faithfully perform computations and serve most recent state. Human organizations can basically do that well enough.
Or, that could happen, as far as I can tell. I'm not sure whether it will. Place your bets.
Early close conditions:
NO: If ATProto is clearly dead, deprecated by another distributed social network protocol. (In which case I might make a market about that protocol instead)
NO: when a proper ledger with negligible transaction costs and good interoperability with AT (or its apps) gains mass adoption. This would signal that there is no need for ATproto to become a distributed ledger, so even if it happens after that point, it like, doesn't matter, it might as well not have.
YES: when the AT smart contracts thing is built and people are using it for finance and the userbase is definitely collectively storing over 7bn (inflation adjusted from August 2024) USD of assets on their PDSes.
1,000
1.00@retr0id They're strongly ordered within the individual repository level, and I intuit that's enough to build locking/syncing processes that relate variables between different repositories? (if not, then I don't know how holochain works)
Finality isn't guaranteed on the technical level but in practice hosts are never going to cheekily revoke an operation.
The thesis is that although these guarantees are nice to have on the technical level, having them on a governance level will turn out to be enough in practice, and even though no one wants to bet any money on that, it will get trialed just incidentally over the course of the history of the protocol and prove empirically true until it reaches a point where you'd have to be a paranoid freak to refuse to store money in an atproto:usgov repo.
@makoyass they're not even strongly ordered within an individual repo, the MST is explicitly oblivious to insertion order
@retr0id Uh, I'm guessing that what you're pointing at is that having a MST alone wont allow you to figure out the order of operations that produced it, in the same way that having a wallet balance wont tell you the history of transactions that produced it. You maintain the history separately by taking the hash of the MST and creating a log entry that links to the previous state and describes the edit. ATProto used to do (most of?) this, and the prevHash field is still there/restoring it would be trivial and will be needed as soon as people start wanting outside validation.
Right?
Uh, I'm guessing that what you're pointing at is that having a MST alone wont allow you to figure out the order of operations that produced it, in the same way that having a wallet balance wont tell you the history of transactions that produced it.
I suppose, yes. You could say that building a distributed ledger on top of atproto is like trying to build a cryptocurrency on top of a database that stores account balances. You perhaps could, with additional layers of stuff, but it seems like a poor starting point.
There's a reason the prev field isn't used anymore, it's prohibitively expensive in terms of storage space, at scale (if you want to keep the actual historic data around to verify). The official bsky infra doesn't use nor verify it. And, nobody really wants a signed log of their historic social media activity that includes deleted posts. Even if you did start using prev, there's nothing to stop you from rewriting history - unless you log your hashes in some other real distributed ledger, but then why not just use that one?
I'm sure you could build some kind of ledger on top of it, but like, why? You'd have to replace/reimplement so many things that it doesn't really make sense to me.
@retr0id lol, what are we disagreeing about again, I also think the current odds are pretty accurate.