Live data from Hacker News

Nostr and ATProto (2024)

shreyanjain.net

21–30 of 74 posts

Re: Nostr and ATProto (2024)

#21

> 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.

I wrote an intro to AT that should be broadly accessible and states the problems before the solutions. You might find it helpful: https://overreacted.io/open-social/

Re: Nostr and ATProto (2024)

#22
post #18

Earlier quoted context omitted.

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.

thanks. also, fwiw, i'm also a very a happy AT user (@hugs.bsky.social) besides also being a happy nostr user.

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.

Re: Nostr and ATProto (2024)

#23
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,…

I kind of feel like you’re taking one of the specs from nostr - the first one written - and calling that the whole protocol. Then you’re comparing all of the atproto specs to that one spec.

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.

Re: Nostr and ATProto (2024)

#24
post #23
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,…

I kind of feel like you’re taking one of the specs from nostr - the first one written - and calling that the whole protocol. Then you’re comparing all of the atproto specs to that one spec. 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 de…

the spirit of my comment was more psychological than technical. nip-1 successfully nerd-sniped my brain into thinking it was easy to get started with a simple, barely functional client. (even though, you're right, at scale, everything gets complicated and is not easy.)

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.

Re: Nostr and ATProto (2024)

#25
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.

The docs are bad, sadly that’s true.

Re: Nostr and ATProto (2024)

#26
post #24
post #23

Earlier quoted context omitted.

I kind of feel like you’re taking one of the specs from nostr - the first one written - and calling that the whole protocol. Then you’re comparing all of the atproto specs to that one spec. 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 de…

the spirit of my comment was more psychological than technical. nip-1 successfully nerd-sniped my brain into thinking it was easy to get started with a simple, barely functional client. (even though, you're right, at scale, everything gets complicated and is not easy.) 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 eith…

Yeah that’s fair

Re: Nostr and ATProto (2024)

#27
post #22

Earlier quoted context omitted.

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

thanks. also, fwiw, i'm also a very a happy AT user (@hugs.bsky.social) besides also being a happy nostr user. 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 se…

Would it be ok to use a library or is the requirement to keep it to raw primitives like curl?

Re: Nostr and ATProto (2024)

#28
post #22

Earlier quoted context omitted.

thanks. also, fwiw, i'm also a very a happy AT user (@hugs.bsky.social) besides also being a happy nostr user. 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 se…

Would it be ok to use a library or is the requirement to keep it to raw primitives like curl?

i like seeing a bit of the raw, low-level protocol first. a few curl examples are perfect for understanding what’s really happening under the hood. once i get that, i'm happy to use a library to handle all the edge cases.

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.

Re: Nostr and ATProto (2024)

#29
post #28

Earlier quoted context omitted.

Would it be ok to use a library or is the requirement to keep it to raw primitives like curl?

i like seeing a bit of the raw, low-level protocol first. a few curl examples are perfect for understanding what’s really happening under the hood. once i get that, i'm happy to use a library to handle all the edge cases. 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 be…

Absolutely. I think it’s a great constraint actually. I have a few other pieces in the backlog but I’ll keep this one in mind.

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/

Re: Nostr and ATProto (2024)

#30
post #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.

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