> 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.
Nostr and ATProto (2024)
21–30 of 74 posts
Re: Nostr and ATProto (2024)
#22Earlier 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.
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)
#23from 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,…
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)
#24from 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…
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)
#25from 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)
#26Earlier 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…
Re: Nostr and ATProto (2024)
#27Earlier 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…
Re: Nostr and ATProto (2024)
#28Earlier 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?
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)
#29Earlier 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…
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)
#30from 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.