Hacker News Reader

Comment by kevinak | Hacker News Reader

This so much. ATProto just seems so complicated in comparison.

Both of these systems are rebellions against the structure of secure-scuttlebot, but took different paths as they rebelled.

Beyond using different cryptography, the biggest difference between the "ATProto System" and the "Nostr System" is that Jay Graber wanted to account for deletes and the re-organization of the message structure of an entire feed.

In early ATProto, aka smor-serve, https://github.com/arcalinea/smor-serve Jay didn't like that we couldn't delete a message on SSB so she centralized all of the operations into a "repo" where we can modify our social feed as much as we want, including even backdating posts. We can see how that evolved into how ATProto currently works today by browsing a repo with pdsls.

For Nostr NIP-01 to work, we generate a keypair, sign a message and blast it at a relay. There's no structure at all to how the messages are organized. Messages are out there once they are sent to the relays. This lack of structure leads to all kinds of issues about how one develops a strategy for syncing an entire history of a feed.

Both of these systems have developed into far larger complex systems that are impossible to hold in anyone's mind at this point, but the key difference is being able to delete a message. Most of the complexity in the "ATProto System" results from accounting for a message that one sends and then wants to unsend later. This is why everyone complains that Bluesky is centralized on the AppView/Index layer. But it's also centralized at the PDS layer.

Correct me if I'm wrong but I think another important aspect of AT is Lexicons, i.e. there's an officially suggested way to do schemas, and application authors are encouraged to create and distribute schemas for their apps. Data is grouped in the repo by its schema too.

True. Scuttlebot had msg types too.

nostr can get plenty complicated, too, but nostr successfully tricked me into thinking it was simple enough to get started.

The more nerds that get sniped by a simple-seeming protocol, the more likely it is to catch on. Hitting a 100 page spec doc full of XML and links to other specs is a big de-motivator to start hacking on the protocol.

NGL that's kind of been the appeal of atproto. Once you get into the weeds you start learning about all the many many many moving parts but at its face 99% of it is:

Hey here's some schema files we call lexicons. Every single interaction with the network is a JSON RPC call to the same domain (whatever your PDS is) with the lexicon's path appended to it.

The fact that it's trivial to hack on atproto via the devtools console or a curl prompt makes things so much more fun to play with.

Yeah, although I would argue that there are far fewer moving pieces in Nostr than there are in ATProto and that's part of why it's so simple - it's just clients and relays. That's it!

Edit: another thing I thought about just now is that you don't really have to worry about implementing most NIPs - many are not relevant if you're just building an application. All the Bitcoin Lightning Network stuff, for example, or private messaging, Blossom, etc.

yes, "there are too many NIPs!" feels like a red herring. at the moment, as a developer, i feel comfortable picking and choosing which NIPs i might want to use for whatever i'm building. but i can also understand why that might be a little confusing/frustrating to others. might be a education/communication issue more than anything else.

both projects are "controlled chaos", where nostr is a little heavier on the "chaos", atproto is a little heavier on the "control".

Reply on news.ycombinator.com