Replying to Avatar Garbage nsec

Good summary of the core differences between ActivityPub/Mastodon and ATProto/Bluesky, source link at bottom.

"Roughly speaking, you can think of Mastodon as a bunch of little independently hosted copies of Twitter that "email" (loosely speaking) each other to propagate information that isn't on your server. So it's cheap to run a server for a bunch of friends but it's cut off from what's happening in the world. Your identity is tied to your server (that's your webapp), and when you want to follow someone on another server, your server essentially asks that other server to send stuff to yours. This means that by default your view of the network is extremely fragmented — replies, threads, like counts are all desynchronized and partial[1] depending on which server you're looking from and which information is being forwarded to it.

ATProto, on the other hand, is designed with a goal of actually being competitive with centralized services. This means that it's partitioned differently – it's not "many Twitters talking to each other" which is Mastodon's model. Instead, in ATProto, there is a separation of concerns: you have swappable hosting (your hosting is the source of truth for your data like posts, likes, follows, etc) and you have applications (which aggregate data from the former). This might remind you of traditional web: it's like every social media user posts JSON to "their own website" (i.e. hosting) while apps aggregate all that data, similar to how Google Reader might aggregate RSS. As a result, in ATProto, the default behavior is that everyone operates with a shared view of the world — you always see all replies, all comments, all likes are counted, etc. It's not partial by default.

With this difference in mind, "decentralizing" ATProto is sort of multidimensional. In Mastodon, the only primitive is an "instance" — i.e. an entire Twitter-like webapp you can host for your users. But in ATProto, there are multiple decentralized primitives:

- PDS (personal data hosting) is application-agnostic data store. Bluesky's implementation is open source (it uses sqlite database per user). There are also alternative implementations for the same protocol. Bluesky the company does operate the largest ones. However, running a PDS for yourself is extremely cheap (like maybe $1/mo?). It's basically just a structured KV JSON storage organized as a Merkle tree. A bit like Git hosting.

- AppViews are actual "application backends". Bluesky operates the bsky.app appview, i.e. what people know as the Bluesky app. Importantly, in ATProto, there is no reason for everyone to run their own AppView. You can run one (and it costs about $300/mo to run a Bluesky AppView ingesting all data currently on the network in real time if you want to do that). Of course, if you were happy with tradeoffs chosen by Mastodon (partial view of the network, you only see what your servers' users follow), you could run that for a lot cheaper — so that's why I'm saying it's not apples-to-apples. ATProto makes it easy to have an actually cohesive experience on the network but the costs are usually being compared with fragmented experience of Mastodon. ATProto can scale down to Mastodon-like UX (with Mastodon-like costs) but it's just not very appealing when you can have the real thing.

- Relays are things "in between" PDS's and AppViews. Essentially a Relay is just an optimization to avoid many-to-many connections between AppViews and PDS's. A Relay just rebroadcasts updates from all PDS's as a single stream (that AppViews can subscribe to). Running a Relay used to be expensive but it got a lot cheaper since "Sync 1.1" (when a change in protocol allowed Relays to be non-archiving). Now it costs about $30/mo to run a Relay.

So all in all, running PDSs and Relays is cheap. Running full AppViews is more expensive but there's simply no equivalent to that in the Mastodon world because Mastodon is always fragmented. And running a partial AppView (comparable to Mastodon behavior) should be much, much cheaper — but also not very appealing so I don't know anyone who's actually doing that."

https://news.ycombinator.com/item?id=45077986

ATProto sounds a bit like Pubky but without pkarr and pkdns, but with added complexities, which makes me wonder if Pubky can scale to Bluesky's current numbers. Just armchair speculation from me.

Also the costs and complexity seem like an overall L for ATProto and it seems clear that it's "decentralized" between large entities only.

Reply to this note

Please Login to reply.

Discussion

Thing is nobody seems to have a useful scorecard for decentralisation. For ATProto, Pubky, Nostr, Farcaster, ActivityPub, Keet, etc., each has certain "decentralisation categories" where it's the winner, and each has certain decentralisation categories where it's the loser.

Far as I can see ATProto's ethos seems to be that relatively few people in the grand scheme are going to put up with this fragmentation stuff and therefore fragmented social networks are never going to get past the size of, say, Mastodon. And if they never get past that size then what’s the point?

The scorecard is keet is on top and everything else is less decentralized

Far as I know, as of today there aren't any alternative clients that are interoperable with keet via holepunch, giving it a bottom score on the client rug-abliity metric. I don't even think you can export contacts and whatnot out of the keet app. Unless things have changed.

I believe they have published enough source that it's quite possible to make an app that could interact with keet, I have seen others do such things since a long time ago

Your "contacts" in keet are the rooms you are a member to, so what ever keys that allow that plus your own local hypercores. The function to make a copy of these "contacts" is to link another device which will then replicate them all on that device which is technically just another instance of keet whether it's on another device is not actually important. And the action of linking the "device" is actually a new identity joining each room with one overall identity linking each of your devices/identities in the room. Interesting point your identity per room is unique opening the possibility to have a different screen name etc per room but this has yet to be implemented, it's just the foundation has been built for it

If you wanted to get into somantics it would be possible with keet to store the info necessary to join any room in text and then store that in keet or any app

As to rugability, it's built on a completely open source and P2P foundation meaning there is no servers to maintain ie it can't be shutdown, yes parts of the app are not currently open but there is certainly enough open to build chat apps and you should be able to make them keet compatible, if you have the keet install files which are publically available you can keep installing and using keet even if holepunch the parent company went bankrupt and stopped, which you can not say for things like signal, WhatsApp or telegram and most other apps

This all may be true but it demands a LOT of work and know how. For 99% of keet users, if keet goes down then that person's holepunch world goes down with it.

Same for Bluesky, for 99% of users if Bluesky the app goes down their ATProtocol world goes down with it, even though in theory you can restore your PDS to an outside host, appview and relay running on independent infra and it's also all open source too.

None of this is the case with nostr clients, one goes down then the bulk of the users can simply access their nostr world from another client, in five seconds, no technical knowledge needed.

Keet can't go down tho? Do you understand how it works? It's P2P, if you have the app it works, it has no servers

If you have the install file you can install it and it works, again no servers

If you join a room and use it you make another copy of it, you can give that copy to anyone

How are you imagining Keet stops working or goes down?

Holepunch Inc, the company, ceases to exist, or pulls the app from the stores.

For 99% of iOS users, that is effectively the end of their holepunch expereince. They cannot invite friends (who also not tech savvy) to install and join them for a chat, and if they lose their local copy of the app (get a new phone, etc.) that's the end of their own connection too.

Yes 1% might compile from code and install via their own personal testflight or whatever, but when talking about general adoption of decentralised tools there is no sense talking bout that 1%. Most people don't even know what the word "key" means, let's not forget.

iOS is a stawman argument, it's a small platform with limitations, where as the other platforms can keep installing if holepunch disappear

The vast majority of normies (or semi-normies, seeing as normies aren't there yet) using Holepunch are using Keet on iOS.

I myself am not interested in protocols that normies will never care about. Sure some tiny number of developers can do whatever they want with some open source code they pulled from Github before a repo went down. But that's of very little interest to me, it's essentially little more than an open hackathon.

Developers are fond of saying "you can just do this" and "you can just do that" but we all know that normies will never ever "just do" these things.