4 ms·

Can someone tell me the basic difference between Bluesky and Nostr. Jack is a big fan of Nostr and I love it technical side of thing, I know not much about how

Can someone tell me the basic difference between Bluesky and Nostr. Jack is a big fan of Nostr and I love it technical side of thing, I know not much about how Bluesky works.

snorremd 3y ago
In Bluesky you create an account on a specific PDS (personal data server) and need to authenticate yourself against that server to write content (posts, likes, follows, etc) to your user repository. Content in this user repository is signed and discoverable by relay servers, and app view services. Currently you can't move your user repository to another PDS, so your user is tied to that server for the time being. When posting content you post to the specific server your user repository is hosted in. With Nostr your identity is truly decentralized. You create a user meaning a private and public key. You then choose which set of relay servers you want to post content to and which servers to pull content from. If you post content to servers A, B, and C users that pull from those servers see your posts. All posts are signed with your private key so the other users can verify that they were in fact posted by you. It does not matter which relay servers you post to, they will happily store your content unless they've specifically blocked you or require some form of white-listing. So in that way your Nostr identity is not connected to any specific server, you can always choose to post to a different relay. As of today I don't think Nostr relays federate/distribute content to other relays, but this seems to be a possibility for the future. Edit: Specified that Nostr relay servers don't have to be open by default.
unshavedyak 3y ago
Well now i kinda want to talk about Nostr. I heard of it before but i'm always wary of prototype projects dying. What's your opinion of Nostr? I like that they seem fond of SSB, and have the same opinions i do of SSB (and it's flaws!)[1]. Though i do find it odd that there doesn't seem to be more attention to somehow chaining/federating/propagating notes between relays. I don't think it needs a super robust method, but from this[1] it sounds like there was basically zero attention put towards that. [1]: https://fiatjaf.com/nostr.html https://fiatjaf.com/nostr.html
- mindszenty 3y ago
  I like Nostr because it is designed delightfully simple. I think it already solved most of technical problems (one of remaining ones are key rotation, but it is actively worked upon), and what it needs is solution of social ones (i.e. marketing). As for federation: first of all, one of basic ideas of Nostr is that a note is published on several relays at once. It adds robustness to the system - one recent analysis shows that on average, one note is published on several tens of relays. Relays do not talk to one other directly per Nostr protocol, so after the publication, notes do not propagate between relays by themselves - but a specialized client can replicate notes from one relay to another. I do not know how often it is done in practice, but it is trivially easy to implement.

Can someone tell me the basic difference between Bluesky and Nostr. Jack is a big fan of Nostr and I love it technical side of thing, I know not much about how Bluesky works.

snorremd 3y ago

In Bluesky you create an account on a specific PDS (personal data server) and need to authenticate yourself against that server to write content (posts, likes, follows, etc) to your user repository. Content in this user repository is signed and discoverable by relay servers, and app view services. Currently you can't move your user repository to another PDS, so your user is tied to that server for the time being. When posting content you post to the specific server your user repository is hosted in. With Nostr your identity is truly decentralized. You create a user meaning a private and public key. You then choose which set of relay servers you want to post content to and which servers to pull content from. If you post content to servers A, B, and C users that pull from those servers see your posts. All posts are signed with your private key so the other users can verify that they were in fact posted by you. It does not matter which relay servers you post to, they will happily store your content unless they've specifically blocked you or require some form of white-listing. So in that way your Nostr identity is not connected to any specific server, you can always choose to post to a different relay. As of today I don't think Nostr relays federate/distribute content to other relays, but this seems to be a possibility for the future. Edit: Specified that Nostr relay servers don't have to be open by default.

unshavedyak 3y ago

Well now i kinda want to talk about Nostr. I heard of it before but i'm always wary of prototype projects dying. What's your opinion of Nostr? I like that they seem fond of SSB, and have the same opinions i do of SSB (and it's flaws!)[1]. Though i do find it odd that there doesn't seem to be more attention to somehow chaining/federating/propagating notes between relays. I don't think it needs a super robust method, but from this[1] it sounds like there was basically zero attention put towards that. [1]: https://fiatjaf.com/nostr.html https://fiatjaf.com/nostr.html

mindszenty 3y ago
I like Nostr because it is designed delightfully simple. I think it already solved most of technical problems (one of remaining ones are key rotation, but it is actively worked upon), and what it needs is solution of social ones (i.e. marketing). As for federation: first of all, one of basic ideas of Nostr is that a note is published on several relays at once. It adds robustness to the system - one recent analysis shows that on average, one note is published on several tens of relays. Relays do not talk to one other directly per Nostr protocol, so after the publication, notes do not propagate between relays by themselves - but a specialized client can replicate notes from one relay to another. I do not know how often it is done in practice, but it is trivially easy to implement.