Live data from Hacker News

Nostr and ATProto (2024)

shreyanjain.net

11–20 of 74 posts

Re: Nostr and ATProto (2024)

#11
post #10

from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"), my average developer brains thinks: i could do that. 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,…

What questions do you have about AT? I agree its docs are mostly “bad” and hard to understand. I find the actual tech approachable so happy to answer more concrete questions.

Tools like http://pdsls.dev in particular can be helpful to see how things fit together.

Re: Nostr and ATProto (2024)

#12
post #6

Been thinking about this lately and ultimately, I'm thinking that -- taking into account what we know about "federation" -- both the Nostr and ATProto models are generally pointless because they attack a problem with more complicated tech that must be solved with OR without that tech anyway. 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…

AT model is very different from Mastodon or email. It’s much closer spiritually to RSS and plain old web.

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.

Re: Nostr and ATProto (2024)

#13
post #2

Bummer that all three bluesky links in the intro are dead links now, and the author's bluesky account appears to be deactivated: https://bsky.app/profile/shreyanjain.net

By contrast, NOSTR comments continue to work just fine. Quite telling between centralized vs decentralized environments. NOSTR is indeed more resilient.

The author wanted to take down their account (to take a break) so this is actually working as designed. The takedown was issued from the author’s repository (which they control), and the downstream app server acknowledged the request.

Re: Nostr and ATProto (2024)

#14
post #7
post #4

Earlier quoted context omitted.

I'm not sure I would necessarily draw that conclusion. 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?

I think you've nailed a problem with all of these, they would make "deleting your stuff" HARDER. What's stopping the rogue node from saving all your stuff forever? 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.)

> What's stopping the rogue node from saving all your stuff forever?

Nothing. You must always have this in mind when posting online: It's impossible to ensure that data is deleted and gone forever.

Re: Nostr and ATProto (2024)

#15
post #10

from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"), my average developer brains thinks: i could do that. 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,…

true, however

>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

Re: Nostr and ATProto (2024)

#16
post #10

from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"), my average developer brains thinks: i could do that. 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,…

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

Re: Nostr and ATProto (2024)

#17
> The Authenticated Transfer Protocol, aka atproto, is a decentralized protocol for large-scale social web applications.

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.

Re: Nostr and ATProto (2024)

#18
post #10

from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"), my average developer brains thinks: i could do that. 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,…

What questions do you have about AT? I agree its docs are mostly “bad” and hard to understand. I find the actual tech approachable so happy to answer more concrete questions. Tools like http://pdsls.dev in particular can be helpful to see how things fit together.

i think it really is as simple as boiling it down into a doc that looks like nip-1 and saying, "this is the absolute minimum amount you need to understand and implement to start sending messages on an AT-based network." -- not from a user perspective, but from an average developer perspective.

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.

Re: Nostr and ATProto (2024)

#19
post #15
post #10

from an an average developer perspective, nostr is interesting because it's "just" a digitally signed json data structure sent over a websocket. reading the spec [1] for creating a simple nostr client (aka "nip-1"), my average developer brains thinks: i could do that. 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,…

true, however >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

That's not an issue with Nostr, it's an issue with the client that they decided to link to. Here's the content loading just fine in Primal: https://primal.net/e/nevent1qqsqfeuezj38syyppscdpu0c0zwermxl...

Re: Nostr and ATProto (2024)

#20
post #18

Earlier quoted context omitted.

What questions do you have about AT? I agree its docs are mostly “bad” and hard to understand. I find the actual tech approachable so happy to answer more concrete questions. Tools like http://pdsls.dev in particular can be helpful to see how things fit together.

i think it really is as simple as boiling it down into a doc that looks like nip-1 and saying, "this is the absolute minimum amount you need to understand and implement to start sending messages on an AT-based network." -- not from a user perspective, but from an average developer perspective. i know eventually i'd need to implement a ton more than the absolute bare minimum, but my gut-feeling "average developer brai…

Thanks, that’s helpful. I’ll see if I can write something in that spirit later.
Post reply on HN