4 ms·

Nostr Protocol

25 points by modinfo 4y ago

Nextgrid 4y ago
I like the idea though I'm not sure how this will cope with spam. However just like with most open-source projects, branding appears to be an issue: a popular web-based client (https://github.com/fiatjaf/branle https://github.com/fiatjaf/branle) is called "branle" which not only doesn't easily roll off the tongue but also means "to jerk off" in French.
an_ko 4y ago
> [Regarding SSB:] It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason) I think the reason for the chaining is that it creates a causal ordering of posts. You will never see the n+1th post without also seeing the nth post. Not having this means posts being dropped by a peer for some reason may change the meaning of the sequence of posts in the eyes of the readers. Imagine for example sending "The previous post is a joke." If posts aren't chained cryptographically, there's no way to know that you have a complete sequence of previous posts, or if some are missing.
- fiatjaf 4y ago
  Does that justify the loss of scalability and flexibility that requirement entails? I think not.
0des 4y ago
> It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works. I want to find out how relays handle all the spam if someone can just hop from point to point. I can only imagine someone will popularize permissioned, private, or otherwise limited relays, defeating the purpose of fighting the tiny-fiefdoms problem of server admins.
- fiatjaf 4y ago
  That's what I have in mind, too.
eternityforest 4y ago
> it does not rely on P2P techniques, therefore it works. That's awesome! Way more decentralized projects should be like this. I think it's worth keeping the custom protocol. SSB is a bit limited, it's missing the ability to pseudo-delete like most social sites have, and it's not natively multi-writer. That's a lot of complexity added. I was interested in building something with a similar model, for IoT devices, and one thing I was going to use to make things easier was a pseudo-DHT. There could be a list of servers with random IDs, that people could add themselves to using pull requests. Your suggested default server is the one in the default pool(Or whichever other pool you selected) that has the closest ID. Any two nodes could always find each other as long as they used the same pool. Also, another thing I was going to do was to have relays have "upstream pools", and know what their "peers" are, so that pools could join together. Your records would be replicated to the closest relay in the pool you select, and if the upstream pool had an even closer node, on that one too. After that I was going to have relays automatically try to fetch things from upstream, so that people could over time build a network that worked like a P2P network, but without the P2P. I think the big challenge with this is that open servers will fill up very fast with crap. Some way of clearing out said crap seems essential. Maybe relays should be able to request things from clients. After a few weeks they could drop old posts, but clients would mark themselves as archives, and the relay could get stuff again from the original poster or friends. This looks like an incredibly promising approach, maybe even one of the better ones I've seen. It's been a while since I saw something decentralized I might actually use!
- fiatjaf 4y ago
  Thank you, these ideas are great, and they totally fit the current Nostr model I think they are being at least partially implemented today in apps like https://damus.io/ https://damus.io/
dataangel 4y ago
Now just require minimal PoW (hashcash) to prevent spam
- simne 4y ago
  :))))) So where will go it's non-p2p-ness?

25 points by modinfo 4y ago

I like the idea though I'm not sure how this will cope with spam. However just like with most open-source projects, branding appears to be an issue: a popular web-based client (https://github.com/fiatjaf/branle https://github.com/fiatjaf/branle) is called "branle" which not only doesn't easily roll off the tongue but also means "to jerk off" in French.

an_ko 4y ago

> [Regarding SSB:] It insists on having a chain of updates from a single user, which feels unnecessary to me and something that adds bloat and rigidity to the thing — each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason) I think the reason for the chaining is that it creates a causal ordering of posts. You will never see the n+1th post without also seeing the nth post. Not having this means posts being dropped by a peer for some reason may change the meaning of the sequence of posts in the eyes of the readers. Imagine for example sending "The previous post is a joke." If posts aren't chained cryptographically, there's no way to know that you have a complete sequence of previous posts, or if some are missing.

fiatjaf 4y ago
Does that justify the loss of scalability and flexibility that requirement entails? I think not.

0des 4y ago

> It doesn't rely on any trusted central server, hence it is resilient; it is based on cryptographic keys and signatures, so it is tamperproof; it does not rely on P2P techniques, therefore it works. I want to find out how relays handle all the spam if someone can just hop from point to point. I can only imagine someone will popularize permissioned, private, or otherwise limited relays, defeating the purpose of fighting the tiny-fiefdoms problem of server admins.

fiatjaf 4y ago
That's what I have in mind, too.

eternityforest 4y ago

> it does not rely on P2P techniques, therefore it works. That's awesome! Way more decentralized projects should be like this. I think it's worth keeping the custom protocol. SSB is a bit limited, it's missing the ability to pseudo-delete like most social sites have, and it's not natively multi-writer. That's a lot of complexity added. I was interested in building something with a similar model, for IoT devices, and one thing I was going to use to make things easier was a pseudo-DHT. There could be a list of servers with random IDs, that people could add themselves to using pull requests. Your suggested default server is the one in the default pool(Or whichever other pool you selected) that has the closest ID. Any two nodes could always find each other as long as they used the same pool. Also, another thing I was going to do was to have relays have "upstream pools", and know what their "peers" are, so that pools could join together. Your records would be replicated to the closest relay in the pool you select, and if the upstream pool had an even closer node, on that one too. After that I was going to have relays automatically try to fetch things from upstream, so that people could over time build a network that worked like a P2P network, but without the P2P. I think the big challenge with this is that open servers will fill up very fast with crap. Some way of clearing out said crap seems essential. Maybe relays should be able to request things from clients. After a few weeks they could drop old posts, but clients would mark themselves as archives, and the relay could get stuff again from the original poster or friends. This looks like an incredibly promising approach, maybe even one of the better ones I've seen. It's been a while since I saw something decentralized I might actually use!

fiatjaf 4y ago
Thank you, these ideas are great, and they totally fit the current Nostr model I think they are being at least partially implemented today in apps like https://damus.io/ https://damus.io/

dataangel 4y ago

Now just require minimal PoW (hashcash) to prevent spam

simne 4y ago
:))))) So where will go it's non-p2p-ness?