Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nostr and ATProto (2024)

shreyanjain.net

Post reply on HN
Print view View original

31–40 of 74 posts

Re: Nostr and ATProto (2024)

#31

Post by hugs »

danabramov wrote: post #29
hugs wrote: post #28

Earlier quoted context omitted.

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/

yeah, that looks like a good base for a simplified remix. thanks!

Re: Nostr and ATProto (2024)

#32

Post by kevinak »

hugs wrote: post #30
kevinak wrote: post #16

Earlier quoted context omitted.

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.

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

Re: Nostr and ATProto (2024)

#33

Post by hugs »

est wrote: post #8

nostr started as very simple but soon there are like millions of NIPs.

that is the best and worst aspect or nostr. it is a very interesting, semi-chaotic box of new toys to play with. reminds me of the early web. (the second best/worst aspect of nostr is key rotation.)

Re: Nostr and ATProto (2024)

#34

Post by hugs »

kevinak wrote: post #32
hugs wrote: post #30

Earlier quoted context omitted.

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

Yeah, 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 pr…

yes, "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".

Re: Nostr and ATProto (2024)

#35

Post by hugs »

danabramov wrote: post #12
jrm4 wrote: 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 informa…

i'm very curious about tangled. i'm building a new thing (tl;dr: an e2e testing and monitoring service) and hope to add more distributed/decentralized functionality into its core. i had been leaning heavily towards using nostr at the core, but it's nice to see atproto-based examples i can learn from, too.

Re: Nostr and ATProto (2024)

#36

Post by vivzkestrel »

whats with the sudden upsurge in interest in ATProto related stuff on HN? Not that I am complaining. I am glad to see something else take AI's spot but just curious. Last month or so has been very busy with something or the other ATProto related

Re: Nostr and ATProto (2024)

#37

Post by grumbel »

jrm4 wrote: 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…

If I'd wanted my user account tied to a server controlled by somebody else, I'd just use Twitter. Mastodon isn't solving any problems here.

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.

Re: Nostr and ATProto (2024)

#38

Post by nightpool »

danabramov wrote: post #12
jrm4 wrote: 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 informa…

> It’s much closer spiritually to RSS and plain old web

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?

Re: Nostr and ATProto (2024)

#39

Post by hugs »

vivzkestrel wrote: post #36

whats with the sudden upsurge in interest in ATProto related stuff on HN? Not that I am complaining. I am glad to see something else take AI's spot but just curious. Last month or so has been very busy with something or the other ATProto related

just a theory, but as atproto matures, there are now other example projects using the protocol for other things besides "distributed twitter clone". for example, tangled was talked about yesterday. [1]

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.

[1]: https://news.ycombinator.com/item?id=45543899

Re: Nostr and ATProto (2024)

#40

Post by gkbrk »

pfraze wrote: post #23
hugs wrote: 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…

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

Post reply on HN