5 ms·
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 spe
by hugs 1y ago
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, 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 https://github.com/nostr-protocol/nips/blob/master/01.md
- danabramov 1y agoWhat 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 http://pdsls.dev in particular can be helpful to see how things fit together.
- hugs 1y agoi 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.
- danabramov 1y agoThanks, that’s helpful. I’ll see if I can write something in that spirit later.
- hugs 1y agothanks. 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.
- danabramov 1y agoWould it be ok to use a library or is the requirement to keep it to raw primitives like curl?
- hugs 1y agoi 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.
- danabramov 1y agoAbsolutely. 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/ https://overreacted.io/where-its-at/
- hugs 1y agoyeah, that looks like a good base for a simplified remix. thanks!
- pfraze 1y agoThe docs are bad, sadly that’s true.
- moelf 1y agotrue, 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
- kevinak 1y agoThat'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/nevent1qqsqfeuezj38syyppscdpu0c0zwermxlnztm24akusu2qrm7xmz05cqppemhxue69uhkummn9ekx7mp0qgs0srw78gjffynj2gd762vc67r24kc70dssm048sp2e74g5tnkfregrqsqqqqqpxzjc9q https://primal.net/e/nevent1qqsqfeuezj38syyppscdpu0c0zwermxl...
- kragen 1y agoOkay, so I think this is the first time I've seen something posted on Nostr. Unless maybe I saw it on another client where it looked very different?
- kevinak 1y agoThis so much. ATProto just seems so complicated in comparison.
- hugs 1y agonostr can get plenty complicated, too, but nostr successfully tricked me into thinking it was simple enough to get started.
- kevinak 1y agoYeah, 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.
- hugs 1y agoyes, "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".
- clarkmoody 1y agoThe 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.
- OneDeuxTriSeiGo 1y agoNGL 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.
- pfraze 1y agoI 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.
- hugs 1y agothe 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.
- pfraze 1y agoYeah that’s fair
- gkbrk 1y agoBut that's essentially the whole protocol. You can implement a client or a server reading only NIP-01 and it will be able to interoperate with the rest of Nostr. 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.
- pjc50 1y agoFor me, as a veteran of social networks since Fidonet, the question that actually matters is the social construction: who's using it, for what purposes and topics, and - crucially - how is the work of moderation (including spam and abuse prevention) handled. Technology doesn't make or break these things, the users do.