Nostr and ATProto (2024)
shreyanjain.net
shreyanjain.net
i don't get that same feeling when reading atproto or activitypub docs. ultimately, there's a reason why all these protocols get complicated at scale, but in the simple case, nostr is very easy to make a client for and start playing with.
nostr feels like a good example case for gall's law: "a complex system that works is invariably found to have evolved from a simple system that worked."
[1]: https://github.com/nostr-protocol/nips/blob/master/01.md
Tools like http://pdsls.dev in particular can be helpful to see how things fit together.
i know eventually i'd need to implement a ton more than the absolute bare minimum, but my gut-feeling "average developer brain" says nostr's absolute minimum feels smaller that AT's absolute minimum. i guess i'm looking for an AT doc for devs that shows the absolute minimum for creating a client that is equally approachable as NIP-1.
i appreciate bsky's focus on user ux and community building and look forward to seeing more sharing of ideas between nostr and AT.
edit to add: to nerd-snipe my brain into wanting to make stuff with AT (or any future protocol) is to focus on a quick-start or tutorial showing the absolute minimal client to send one message.
once i can do that... i'm ready to learn all the rest of the vocabulary and server-side stuff, but not until i can send one simple message from a barely functional minimal client.
but starting with a library tutorial makes me wonder how many stacks of turtles are being hidden. if i can see the turtles upfront, i'll appreciate what the library does for me -- and i'll have a better sense of how to debug when things break.
This isn’t quite what you want but should illuminate at least the “fetch on demand” part in detail: https://overreacted.io/where-its-at/
>You can read and leave comments on this post here on Bluesky, or here on Nostr, or even here on Mastodon.
the only link that doesn't work is the Nostr one, the content doesn't load for me
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.
both projects are "controlled chaos", where nostr is a little heavier on the "chaos", atproto is a little heavier on the "control".
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.
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.
The substantive difference is that we didn’t do a mix & match spec process because we knew the ambiguity of spec support causes problems, just as it did with XMPP. Protocol specs only get implemented a few times. The meaningful developer choices are in schemas and business logic.
perhaps this a roundabout way of hoping there is already a developer-focused quick start or tutorial for making a barely functional AT client. it either already exists, but i didn't look hard enough for it, or it might only be one chatgpt or claude prompt away.
Reading and implementing NIP-01 can be done in an afternoon (or a weekend if you're taking your time), and it gets you relays that can accommodate multiple clients and applications. From the client perspective, only implementing NIP-01 gets you a simple Twitter clone with an identity that belongs to you.
Technology doesn't make or break these things, the users do.
Quite telling between centralized vs decentralized environments. NOSTR is indeed more resilient.
If the author intentionally deactivated their Bluesky account, does the fact that he can successfully do that on Bluesky lead to the conclusion that it's less resilient?
That really means that once you publish something, the internet won't forget it.
It is OK if you prefer walled gardens, other people prefer the outdoors.
I think "trying to make a thing that can work through rogue or stupid nodes" is just prohibitively harder than "work on making nodes more reliable" (which I absolutely grant is extremely hard.)
Nothing. You must always have this in mind when posting online: It's impossible to ensure that data is deleted and gone forever.
Taking this idea further -- this is the sort of thing that really makes me consider whether or not ATProto might be literally the worst idea in all of social media.
Which is to say "can track you just as intrusively as any private service, but now your history is cryptographically signable and even EASIER to share and move everywhere"
Didn't even took a year to see where the texts are still readable today.
Someone said it really well; if your solution relies on "maybe people will learn about or do new complex thing X" it's just not likely to take off.
But for the sake of argument, let's try going down that road for this. Along the way you'll be communicating with people, building trust, etc etc.
But now YOU'VE ALREADY DONE THE THING YOU'RE trying to optimize for, and for which we already have an extremely resilient model, aka Mastodon-which-is-very-analogous-to-email. At that point, just make a mastodon server or servers with with those people.
It just feels like the smart bet is doing that analogously to email, a model that definitely works, then trying to do the same thing PLUS invent a whole new idea of "take everything with you" at the user level.
Mastodon is “many copies of the same app emailing each other”. There’s no global shared view of the network so you can’t have features like globally accurate like counts, shared identity, global search, algorithmic feeds across instances, etc.
On the other hand, in AT, the idea is just that apps aggregate information from different repos. So each application’s server has information aggregated from the entire network. Everybody sees the same consistent information; apps exist to separate experiences rather than communities.
For example, Tangled (https://tangled.org) and Leaflet (https://leaflet.pub) are AT apps, but they’re nothing similar to “mastodon servers”. These are complete apps that implement different experiences but on the same global network.
Crucially, normal people don’t need to “buy into” the protocol stuff with AT. Most Bluesky users don’t know what AT is and don’t care about it; they’re just using the app. There’s interesting crossovers you can do (each AT app sees each other AT app’s public data) which do bleed into the user experience (eg my Tangled avatar is actually populated from Bluesky) but overall apps compete on their merit with centralized apps.
Hope that makes sense. See https://overreacted.io/open-social/ for a longer article I wrote about AT with visual explanations.
What do you mean by this? ATProto requires a giant indexing database that has access to every post in the network. Mastodon is more like a feed reader—you only get notified about the posts you care about. How is needing a giant database that knows about every RSS feed in the world closer to the plain old web?
RSS is a way to aggregate data from many sites into one place. AT lets you do the same, but with bells and whistles (the data is signed and typed, and there's a realtime stream in addition to pulling on demand). If you're forced to describe AT via existing technologies, AT is basically like RSS for typed JSON in Git over HTTP or WebSockets that scales to millions of users.
It is completely up to you what you decide to index. If you want to build an app that listens to records of "Bluesky post" type that are created only by people you follow, you absolutely can.
See https://bsky.app/profile/why.bsky.team/post/3m2fjnh5hpc2f (which runs locally and indexes posts relevant to you) and https://reddwarf.whey.party/ (which doesn't have a database at all and pulls data from original servers on demand + using https://constellation.microcosm.blue/ for some queries).
The reason you don't see more of these is because an isolated experience is... well, isolated. So people are less interested in running something like this compared to, say, a whole new AT app. But AT can scale down to Mastodon-like use cases too.
>ATProto requires a giant indexing database that has access to every post in the network.
Only if you want to index every post, i.e. if you want to run a full-scale social app for millions of users. As an app builder, you get to choose what you index.
For a start, you probably only want to store the records relevant to your app. For example, I doubt that Tangled (https://tangled.org/), which is an AT app, has a database with every Bluesky post. That seems absurd because Tangled is focused on a completely different use case — a social layer around Git. So Tangled only indexes records like "Tangled repo", "Tangled follow", "Tangled star", and so on.
Naturally, Tangled wants to index all posts related to Tangled — that's just how apps work. If you wanted to build a centralized app, you'd also want it to contain the whole database of what you want the app to show. This isn't specific to AT, that's just common sense—to be able to show every possible post on demand with aggregated information (such as like counts), you have to index that information, hit someone else's index, or fetch posts from the source (but then you won't know the aggregated like counts).
That said — if you want to build a copy of a specific app (like Bluesky) but filtered down to just the people you follow (with no global search, algorithmic feeds, etc), you absolutely can, as I've linked earlier. Or you can build something hybrid relying on global caches, or some other subset of the network (say, last 2 weeks of posts). How you do indexing is up to you. You're the developer here.
I don't understand why you become isolated once you've built your own app, it it because the bluesky firehouse has to decide to index posts I make on my server? I guess I'm asking how does an application decide which sources to index from, just anyone advertising that they are serving that lexicon? Why then would I become isolated by virtue of hosting only data I want to host/indexing only feeds I care to index?
(Thanks in advance I do want to grok this...)
There’s really two main kinds of nodes in the system. Hosting servers and app servers. They’re completely unrelated and completely decoupled. It’s like Dropbox vs apps that put data in your Dropbox.
A hosting server stores your personal data. This is similar to having a Git repository with data from all social apps. Or like a Dropbox folder. That’s usually called a “PDS” — a personal data server. Running one is extremely cheap since it’s only your data. It is also optional (eg Bluesky provides AT hosting for free). But this is not an app — it’s literally like Git hosting. Just the data (for all apps).
Then you have app backends. Those are just normal servers. They’re what you’d typically think of web applications. The Bluesky app is one of them. An application server listens to events from all known hosting servers and updates its local database with whatever it’s interested in from the stream. For example, the Bluesky application server updates its local database to put all “post created”, “like created” etc events from all hosting servers into its database that it can query.
So as an app author you have a lot of freedom for what to build:
- You can build a new app that only listens to record of your app’s type. So naturally it would only index your app’s users’ content. Which is presumably not much.
- You can take an app server for existing app (if it’s open source) and run it yourself. But then of course if this app has a million of users, you need to decide which records you want. Do you want to index them all (like the original app)? Do you want to index a subset? Which subset? It could be historical (eg two last weeks of post, one last week of likes etc). Or it could be by proximity (only profiles, posts and likes within one follow from you). Or something else. You decide what to store.
- You can also build something hybrid — an app that remixes data from multiple apps. And you can fetch data from hosting servers without storing it (but this doesn’t give you aggregation) or fetch aggregated data from community indexes (if the aggregation you need already exists and is provided by someone else).
Hope this makes sense.
(As a performance optimization, instead of aggregating from millions of repositories individually, you’d listen to a stream that combines them. That’s called “relay”. Relays are mostly dumb websocket retransmitters and don’t have any app-specific logic. Bluesky runs one, Blacksky runs their own, and it would generally cost $30/mo to run one today. Any hosting server can ask any relay to crawl it. Any relay may also choose to crawl a new hosting server if it encounters links to content on that server. Relays are common infra and you shouldn’t expect there to be a lot of them. App servers choose which relay to listen to, if at all.)
---
Now answering your specific questions:
>I don't understand why you become isolated once you've built your own app
If you've built an app that looks like Bluesky, but only you and your friends' posts/likes show up, is that much better than just using Bluesky? My point is that usually this isn't a differentiator and feels kind of pointless. You might as well just curate your Following feed on Bluesky. So people don't do that often.
>it it because the bluesky firehouse has to decide to index posts I make on my server?
This seems like a misconception; moving your data (to your own hosting) is a completely separate thing from creating an app. See the distinction above. You can move your hosting to a different hosting server, but this wouldn't affect your experience in the Bluesky app at all. The Bluesky application server would simply start ingesting your posts from your new server instead once it gets notified about your account move.
>I guess I'm asking how does an application decide which sources to index from, just anyone advertising that they are serving that lexicon?
Typically an application just listens to a relay (like the one hosted on Bluesky) which already retransmits events from all known repositories. If you operate your own repository, you can send a "request crawl" command to Bluesky's relay, and it will index you. This is kind of similar to a website getting picked up by Google search. Links may also do it but a "request crawl" is the explicit way. See https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1.... for a live feed of the relay operated by Bluesky (it's not specific to the Bluesky app).
>Why then would I become isolated by virtue of hosting only data I want to host/indexing only feeds I care to index?
Hosting data !== indexing, again these are separate things.
Hosting your own data doesn't make you isolated — it is pretty much indistinguishable in the apps. You don't see where someone's data is hosted since in the app it all appears seamlessly aggregated.
Creating an app that only shows 0.000001% of the network's content when there's already an app that shows 100% of the same content is what I call isolating. I'm just not sure what it accomplishes since the network is still shared. So this isn't very compelling to most app builders. What's compelling is usually building completely new experiences. Although some people do experiment with more "limited" Bluesky clones.
Moderation in AT is layered. Hosting servers do their own moderation but it’s very minimal (just trying to catch illegal content early). Relay operators also have levers to stop broadcasting from specific nodes if they’re problematic (but again, this is reserved for either extreme illegal content or for network abuse). Most of what you’d think as moderation happens at the app server level, which is the same as in non-AT apps. The app server can easily choose to not serve a certain user’s posts even if they exist upstream at their hosting.
One wrinkle is that AT goes a step further and extracts moderation primitives (“labelers”) as a separate thing — for example, you can ingest Bluesky’s moderation decisions from a separate service (and the Bluesky app server listens to the same service). This makes moderation composable, and also lets someone make a fork of Bluesky that “listens” to a different moderation authority.
But thanks for the link to Konbini! That looks really exciting and promising and I would love to start using it if I can run it completely decoupled from Bluesky infrastructure.
I agree that some information seems important to know, like blocks. (Although in different apps it's reasonable to expect blocks to be app-specific.) Blocks are public on Bluesky though, for this exact reason. DMs are a disconnected service but the eventual idea is some kind of E2E (https://www.germnetwork.com/ is also building something now). Follower-only things could work through some variation of private state mechanism (see https://pfrazee.leaflet.pub/3lzhmtognls2q, https://pfrazee.leaflet.pub/3lzhui2zbxk2b).
>I would love to start using it if I can run it completely decoupled from Bluesky infrastructure.
You could use Blacksky's relay as the input source (https://atproto.africa/), or run your own relay. The only piece you'd then depend on is PLC registry (since it resolves PLC identity). Bluesky is in the process of separating it into a separate entity in Switzerland, but if that's a hard goal, I guess you could forbid `did:plc` identities in your app (vast majority of users) and only ingest data about `did:web` ones? Or do you feel OK about PLC resolution?
The beauty of Nostr is that it turns the server into a dumb relay, the server controls and owns nothing and you can replace it with another one at anytime or broadcast to multiple at once to begin with. The user is in full control and everything is held together by public-key crypto.
So you can do it, but it’s not really designed for that use case.
I would be great if there were a full-featured single user ActivityPub server, but last time I looked, there wasn’t really.
Which is to say, all of the potentially intrusive human information gathering and spying that you can encounter on twitter, but now cryptographically signable and EASIER to move from place to place.
Perhaps the ability of your mastodons and emails to lose your info might be just as much a feature as a bug.
Not that it's easy, but still possible.
I must not be the target audience for this older article. Several paragraphs in, I had no idea what this was about. That’s how ATProto describes itself.
and that probably came up because more people are wondering about the future of github as it becomes more integrated into microsoft. as things become more centralized, interest in decentralization goes up.
Since all data lives in a single conceptual space, you start seeing community services like https://constellation.microcosm.blue/ (backlinks without running your own index), https://slices.network/ (indexes data you want and gives you a GraphQL/REST endpoint), independent relays (https://atproto.africa/), and so on.
To give you an example, https://slices-teal-relay.bigmoves.deno.net/ is a demo of Slices showing the latest teal.fm records (like Last.fm scrobbles). The thing is, teal.fm is not even launched as an app. It's just its developers already listen to music through it, the records get created in their repos, and so any other developer can aggregate their records and display them.
It's a web of realtime hyperlinked JSON created by different apps. That's exciting.
I have thought Key Event Receipt Infrastructure (KERI [0]) is the best solution to this but don't know if there's an implementation of it anywhere