[HN Gopher] Nostr is a stupid simple P2P protocol that works, bu...
___________________________________________________________________
Nostr is a stupid simple P2P protocol that works, built by builders
I have been seeing a lot of shilling for mastodon lately, so I
thought I would step in and shill Nostr for a bit.
https://github.com/nostr-protocol/nostr Fun facts about Nostr: *
Nostr stands for "Notes and Other Stuff Transmitted by Relays". It
is an odd acronym, but I like it. * Nostr uses websockets and
relays to build a really simple P2P network. We also steal a few
ideas from bitcoin (ECDSA ids, schnorr-signed events). * Relays
are simply dumb data stores for events that clients publish and
subscribe to. * Clients don't trust relays to be honest, so all
events are self-signed. Your pubkey is your userid. * It is stupid
simple to build a Nostr client. You can easily do it in less than
400 lines of JavaScript. And it runs in the browser. (shameless
self plug) https://github.com/cmdruid/nostr-emitter * Nostr is
powerful enough to host chat apps very easily. Here is a rip of
Telegram, running on Nostr: https://anigma.io * There's a lot of
fun things you can do with Nostr. Check out all these cool
projects! https://github.com/aljazceru/awesome-nostr * We are
constantly discussing how to improve the protocol. Come join the
conversation here: https://t.me/nostr_protocol https://anigma.io
https://damus.io https://github.com/nostr-protocol/nips Thank you
for reading my nostr shill post. I did not create nostr, nor do I
get any monies for promotion. I just think it's really cool and I
have a lot of fun building stuff that punches though nats. If you
have any questions about nostr please feel free to ask. Also,
Happy Thanksgiving to everyone! I hope we're all feeling fat and
sassy today. :-D
Author : kdragon
Score : 82 points
Date : 2022-11-25 20:22 UTC (2 hours ago)
| jesusixos wrote:
| Cool
| Cameri wrote:
| I don't agree Nostr is P2P since clients must connect to relays
| and there's no provision at the time for client to client
| connectivity. I found out about Nostr and due to the simplicity
| of the protocol I was able to start building right away. I
| implemented a relay using Typescript:
| https://github.com/Cameri/nostr-ts-relay I also wrote this dead
| simple SMTP to Nostr gateway: https://github.com/Cameri/smtp-
| nostr-gateway
| chromatin wrote:
| Link to nostr NIPs (nostr improvement proposals):
| https://github.com/nostr-protocol/nips/blob/master/README.md
|
| One of the neat things about nostr is that while it has already
| been used to build a decentralized Twitter like social network,
| the protocol could also be used to build encrypted P2P chat,
| traditional discussion forum, alerting/push style notifications,
| and numerous other applications.
| remram wrote:
| Might be worth going with "enhancement proposal" instead so you
| don't call your governance documents "nips".
| klabb3 wrote:
| Not saying this is the future, but something like it is. All of
| the core decisions here are solid (pub key identities, signed
| events, dumb relays).
|
| There are still features that many apps will need such as tying
| multiple devices to an identity, abuse prevention for relay
| operators, etc.
| chromatin wrote:
| A couple of ideas that have been tossed around for relay abuse
| prevention:
|
| - Proof of work: computing some hash, which is not enough to be
| onerous but enough to reduce spam
|
| - micropayment over Bitcoin lightning network
| procrastitron wrote:
| "All of the core decisions here are solid (pub key
| identities..."
|
| I agree, except for the bit about public keys as identities.
|
| I think public key identities are a step in the right
| direction, but there's still a gap between that and what the
| ultimate solution is going to wind up being.
|
| We need to have some layer of indirection between user
| identities and public keys so that users can do things like
| rotate keys, have multiple keys, and recover their identities.
|
| I don't know what the right solution to that is; I think it's
| an open problem and probably one of the most important ones to
| solve. Keybase probably came closest to a good solution, but it
| wasn't decentralized.
| fiatjaf wrote:
| Is there a way to do what you're suggesting with identities?
| I don't think there is. How are you going to rotate keys
| without a master key?
|
| And even if you're ok with the master key, the only way to
| solve this without centralized providers is with blockchains.
| A blockchain for rotating keys doesn't make sense.
|
| But I do want to know if you're ok with a master key and
| subkeys that can be rotated.
| frizlab wrote:
| Something like passkey?
| kdragon wrote:
| My vote is for extended keys, something based off HD Wallets:
|
| https://github.com/bitcoin/bips/blob/master/bip-0032.mediawi.
| ..
|
| Easy rotation and recovery of individual keys, but you do
| have to protect your master seed.
|
| Nostr also supports user verification through DNS hostnames.
|
| https://github.com/nostr-protocol/nips/blob/master/05.md
| fiatjaf wrote:
| How can you rotate that? No one knows the second key is
| related to the first. You still need to publish your second
| key somewhere along with an invalidation certificate for
| the first key.
| alexeldeib wrote:
| I was reading about algorand rekeying today, as well as DIDs
| and atproto/bluesky.
|
| Both seem to use a "signed rotation" approach. Algorand keeps
| your public key stable while adding metadata that your spend
| key has changed and links the two. Atproto similarly uses the
| recovery key to sign a rotation op which can regenerate your
| signing key, additionally readjusting the tree to preattack
| state (by setting prev of the rotation to the last
| precompromise state).
|
| This seems like an improvement of some kind, but still leaves
| gaps for lost keys. Keybase style approach, or multisig
| social recovery may also help.
| Reventlov wrote:
| The inability of people to spell Mastodon correctly will always
| surprise me. Also, isn't << nips >> a slang for nipples ?
| kdragon wrote:
| fixed >_<
| rgbrgb wrote:
| Cool! How do you discover users to follow on nostr?
| fiatjaf wrote:
| How do you discover users to follow on Twitter?
|
| I doubt anyone has ever been successful into signing up on any
| social platform and just followed the big names that are
| suggested automatically at the beginning or based on some "key
| interests" you select.
|
| But hey, if you want that, it's easy for a third-party website
| to grab a ton of public Nostr data and build custom
| recommendation lists and whatnot.
| TheSkyHasEyes wrote:
| https://github.com/nostr-protocol/nostr
|
| See FAQ, second question.
| kdragon wrote:
| Great question! Relays aren't involved in curation or
| discovery, so it fall on the client.
|
| You can request very broad subscriptions from relays! For
| example, here is a site that subscribes to everything, showing
| you a gods-eye view of events streaming into a relay:
|
| https://nostr.info/relays
|
| Events have different "kinds", so you can filter this based on
| the type of traffic you are looking for (like public posts or
| user profiles).
|
| Platforms like damus.io are more user-friendly, and offer
| better tools for discovering users and content.
|
| You can subscribe to a user's feed via their pubkey, so
| discovery methods typically revolve around learning pub keys.
| rgbrgb wrote:
| Makes sense, thank you!
| egypturnash wrote:
| So how does nostr propose to solve the problem where there is, in
| fact, quite a lot of content that you _want_ to filter out,
| whether because it makes for a better experience for the people
| using this protocol to talk to each other, or because there are
| some pretty solid laws about things that various governments
| require people to filter out?
|
| https://abovethelaw.com/2022/11/hey-elon-let-me-help-you-spe...
| is a pretty decent rundown of a mix of these things; it is
| specifically pointed at Elon Musk's decision to buy Twitter and
| make it a haven for "free speech" but it is a glimpse at what is
| in the future for _anyone_ setting up a "free speech" platform.
|
| My experience as someone who has been running a Mastodon server
| since 2017 is that while "we are all for FREE SPEECH, we only
| block what the government ABSOLUTELY requires us to block!"
| sounds noble, in practice nodes of the Fediverse that say this
| become havens for people who are only there to be assholes to
| other people, and any sane admin will sigh and block the whole
| server, because it's just going to be a continual source of rude
| nasty bullshit.
| Cameri wrote:
| Nostr lets you specify who and what you subscribe to, so unless
| you subscribe to everything and everyone this isn't really a
| problem. You can also subscribe to followers' followers and
| expand that way.
| kdragon wrote:
| Yes this is the crux of any social media application. I don't
| know if there will ever be a perfect solution.
|
| I like that nostr abstracts this problem away from the relays.
| Relays only focus on storing data and handling subscriptions.
| They can choose to censor and/or curate content if need be, but
| it's not their concern.
|
| It's up to the client to come up with a solution, and that
| client can be a platform or a protocol of its own.
|
| _edit_ it also feels really great to work on that problem from
| the application layer. I can come up with a solution that isn
| 't confined to the parent protocol.
| fiatjaf wrote:
| Unlike what OP says Nostr relays are not dumb, they can have
| their own policies and to me they look like a better version of
| Mastodon servers. They can have identities, "themes" and
| policies as they wish. On Nostr it's totally fine for one relay
| to only allow certain kinds of content and block everything
| else. Users can just connect to multiple relays if they want to
| read/write about different things.
| huimang wrote:
| At this point I don't see much point in adopting something that
| doesn't support ActivityPub. I'd rather just use
| Mastodon/Pleroma/Akkoma with some heavy blocklists.
| remram wrote:
| I've been looking at alternative implementations since I don't
| want to run the entire Mastodon app for just myself. The fact
| that every single ActivityPub implementation runs into so many
| interoperability issues, such that they have to be fixed to
| work with each other system one by one, is a sign to me that
| the protocol is either too complicated or not robust enough
| (probably both).
|
| There is tremendous value in a much simpler protocol,
| especially if it can deal with the identity migration issues
| that Mastodon has faced since day one.
| nine_k wrote:
| A stupid simple message relay protocol can be used for stuff
| other than social media.
|
| OTOH websockets are hard outside the browser :(
| eternityforest wrote:
| Websockets are almost trivial now if you just use a library
| RustyRussell wrote:
| Actually, websockets are trivial full stop. I implemented a
| web socket proxy in C in a day by reading the excellent RFC
| (sure, there's weird shit in there, but it's not _hard_ ).
| [deleted]
| akkartik wrote:
| Last year: https://news.ycombinator.com/item?id=29749061
| ilaksh wrote:
| If everything goes through relays then is it really P2P? Why not
| even try to have a direct connection of any sort, such as WebRTC?
| nine_k wrote:
| Is email p2p? Can you configure multiple relays like MX records
| for email? Can a receiver be its own relay?
|
| Relays are important for two readoms: peer discovery and
| communicating when one of the parties is offline. Same as with
| other p2p networks.
| bawolff wrote:
| I mean, the pure P2P solution would be supernodes.
|
| Edit: i RTFA. Sounds like relays can be run by anyone. That
| sounds p2p to me.
| kdragon wrote:
| You can argue that it is not true P2P, since you rely on a
| public-facing intermediary.
|
| A lot of p2p protocols cheat with relays, it is really hard to
| traverse nats otherwise.
|
| Nostr can be used for peer discovery to bootstrap a direct p2p
| connection.
|
| You could also use a client/relay hybrid application, similar
| to other p2p networks. That would be fun to build. :-)
___________________________________________________________________
(page generated 2022-11-25 23:00 UTC)