Get the top HN stories in your inbox every day.
pointlessone
Zamicol
I dug into Nostr this week. IMHO, these are some of my engineering concerns.
- User accounts are tightly coupled to a single key. There's currently no account abstraction.
- Nostr is tightly coupled to a specific crypto primitive and doesn't attempt any sort of crypto agility.
- The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md)
evv
> - The plan appears that user names are delegated to the centralized DNS system (https://github.com/nostr-protocol/nips/blob/master/05.md)
DNS is not centralized, it is distributed. A name server can delegate authority to other servers. Every nation has their own, which I consider sufficient decentralization. (Although it does rely on IANA to list addresses of root name servers, which is perhaps the centralization you refer to)
Do you propose another naming system?
Zamicol
DNS is centrally controlled by ICANN.
There are alternatives like ENS. I don't mind Nostr just simply having its own system.
leishman
I’ve built a Nostr relay from scratch to learn the protocol and while there are some odd quirks, the fact that it’s maximally simple and the core spec can be understood in 5-10 minutes has way more value than you may immediately realize. It lowers the barrier to entry for builders substantially.
leesalminen
I also had a similar experience. I’ve built a handful of little things that speak nostr over the past month just to get a feel for it.
Time-to-grok is fast and then you’re off to the races building.
I never even bothered to build anything on ActivityPub because the minimum bar is much higher.
anothernostrich
> The protocol doesn't define a transport but seem to use WebSockets.
The protocol transport is over WebSockets.
> How does it handle poor/dropping connections?
The way HTTP underneath it handles poor/dropping connections. It is request-response like HTTP, there isn't state to recover, just try again.
> Does it allow usage of alternate transport protocols?
If you think it is useful, write a NIP for it.
> Messages are defined as JSON but doesn't use much of its structure anyway. Some fields are just arrays of values. And even then some parts are just strings with some other arbitrary syntax. Seems like a poor choice.
Being readable is helpful for debugging. I agree there is less structure than could be used, but it is well-defined and libraries can more strongly type the data and name the fields, for example. One thing you can't easily do is go back and change the protocol, that would create far too much complexity.
> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?
The part that is signed is defined well enough that at least dozens (probably near a hundred now) coding implementations are inter-operating on this without issue. Is the definition formal and rigid enough to ensure nobody misinterprets it? Probably not. I've had to ask for clarification and when I got it, I put in a PR to change the NIP. It was accepted right away.
It is not XMPP. Have you read the XMPP RFCs? I couldn't even get through the table of contents of the first one. The guiding principle of nostr is that it is the simplest protocol that has a chance of working.
lapcat
> It's unclear how to preserve/port data. A relay is supposed to keep (or not) messages and the client is supposed to send messages to multiple relays. But what happens when a relay goes down? Can a client send messages to a new relay? Should the client keep all messages just for such a case?
https://www.nostr.how/relays "If all the relays that you have used in the past go offline, all your posts will be unretrievable. This is one reason that Nostr allows users to connect to many relays – this ensures some degree of backup. That said, if you're really interested in being uncensorable, you can run your own personal relay."
So clearly, relays are retaining copies of your data. The question is really storage capacity: if nostr becomes popular, will individual relays have enough storage capacity for all of its users?
Aeolun
I’m really confused as to why they’re called relays. As it is now they’re not relaying anything. They’re just a default server/client.
leesalminen
I think relays should scale horizontally, meaning relays should become topic-based, geography-based, etc.
Also, I also don’t think relays are under the obligation to store notes forever. Part of scaling horizontally is hosting your own long term storage (or pay a provider to do that for you).
If a relay needs to scale vertically, they could start charging for access or do data mining+ad injection, all kinds of stuff to monetize.
One of the writers of the NIPs posted this earlier today:
> Other relay ideas (not very good, just to sparkle your imagination):
- a relay only for people with top-level domain names (no "@" at the NIP-05)
- a relay that only stores the most recent post of people
- a relay that only stores posts that have received at least 10 replies from other people (big threads)
- a relay that only serves posts to people having $X tag on their profile metadata
pointlessone
How does client decide which relay to send a message to?
Those relay ideas seem like the whole new level of screaming into the void. It doesn’t sit well with me that not only there’s no promise of saving my data but rather ideas of not keeping my data for me are floated around as a normal thing.
kemitchell
> Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?
Systems I've seen (and written) that do this use deterministic serialization algorithms that sort keys and do other things standard, general-purpose implementations don't. The implementations in core libraries, browsers, and the like tend to be faster, but the payloads being signed in the apps usually aren't that large.
leesalminen
Taking a look at NIP-01, the serialized data that gets hashed and signed is a flat array, not an object. So no sorting of keys here. I don’t think any json serializer would change the order of items in an array, right?
pointlessone
That's true but there's still plenty of room for incompatibility. JSON doesn't put any requirements on floats precision, for instance. Another example is that any character may be escaped (that's in the RFC, literally, verbatim) so while it's recommended to use UTF-8 for serialization a random lib can decide that ASCII is the way and escape all your emojis. To be fair, NIP-01 specifies that it has to be UTF-8 but no mention of float precision can be found. I'm almost certain these two are not the only ways a JSON can be divergent while still being valid.
And I have to point out that we're doomed to repeat our mistakes. XML is also very flexible. And people wanted to sign XML documents and they found this to be a problem. So they came up with Canonical XML form — a way to remove some of that flexibility to make sure it's possible to reliably derive a stable variant that can be signed and verified. Unfortunately, we haven't came up with Canonical JSON yet. But maybe we will soon.
leesalminen
> Can a client send messages to a new relay?
Yes, a user can transmit a previously created note to a new relay at any time.
class4behavior
The whole premise of Nostr is that you consider your access point hostile, yet its provider is still offering one. That contradiction just incentivizes bad and toxic actors to participate and dominate this network.
That's why, it seems, the developers actively conflate what one would expect from a private communication platform and a social media platform. But this isn't an alternative to Mastodon or Twitter, it's an alternative to Berty, Cwtch, Speek, Briar, Anonymous Messenger, and maybe Matrix if you use it for encrypted communication only.
It has a legitimate use case for people who may be forced to switch relays very often due to government censorship but still want to continue to talk in public. To anyone else the quality and culture of the moderation system is what defines the quality of their platform, but Nostr undermines the former by design.
As such, it comes to no surprise that the free speech warriors from the crypto community are the main drivers of this protocol. It's just a pity that Snowden seems to have become one of them as well - and it isn't that he supports it, but how. He's just repeating the devs' own flawed narrative.
Decentralization is the right path forward, but you want social media on federated platforms as you need to take care of communities with enforceable rules and provide a service to users, while for private interpersonal or group communication you can opt to federated or peer-to-peer networks.
gray_charger
I think centralized moderation is the problem with social media servers. Users should be the ones to control their own moderation. See a post you don't like? Hide the post. Don't like any posts from a particular user? Block the user. It's not difficult to do and if users are really only following friends and famous accounts (celebrities, bots, news, etc.) they won't experience much spam anyway.
I think the real issue is discovery. How does one find other accounts that post about similar topics (other than friend-of-a-friend approach) and that aren't spam.
lapcat
AFAICT at first glance, on nostr you would only see posts from accounts you follow. There isn't any "algorithm" to feed content to you. Someone can correct me if I'm wrong, but this is my impression. Therefore, it's all self-moderation, and you wouldn't have any spam or messages from hostile randos, because you wouldn't be following them in the first place. And as you say, "the real issue is discovery".
leesalminen
That's all that exists today. Nothing prevents a client from developing some sort of algorithm, querying the relays appropriately, and rendering notes from users not followed.
At the same time, nothing prevents a user from migrating to a different client that has no "algorithm".
topranks
I don’t want to have to look at abuse material just to tell my machine to block a user. And play whack-a-mole as they reappear etc.
Moderation is vital for public social platforms.
leesalminen
These notes can already be flagged and reported. This action generates another note of a specific type. A nostr client could use this data and hide notes from users before they ever see them.
21eleven
Discovery could be done via "retweet"/repost functionality. Perhaps there could be some feed of most reposted over the last day.
Just spit ballin
gtirloni
Saw some CP, just block it, right? No one to be notified so it stops spreading.
leesalminen
Damus currently has a report note button which broadcasts another event with a specific kind ID. Anyone could connect to relays and collect all the IDs of reported notes and do either good or bad things with this information. Other clients can add this button too, and can choose to not display previously reported notes (above a threshold etc).
antisocialist
In most jurisdictions you're supposed to report it to the police, so that they can identify who has accessed it and who attempts to access it next.
nine_k
That's how technology works. If it works for you, it works for your most bitter opponent. If it limits your opponents, it also limits your dearest friends.
Choosing the right amount of freedom is always a balancing act.
antisocialist
> But this isn't an alternative to Mastodon or Twitter, it's an alternative to Berty, Cwtch, Speek, Briar, Anonymous Messenger, and maybe Matrix
And (not maybe) xx Network.
Nostr isn't an alternative to these messaging and chat apps because it has weak anonymity and privacy. Take a look at how those other apps/platforms work, and then compare them with Nostr.
> As such, it comes to no surprise that the free speech warriors from the crypto community are the main drivers of this protocol.
Nostr has weak privacy protections compared to most of of the above mentioned platforms, so I don't think it's something free speech advocates should feel comfortable promoting - anyone who truly needs free speech and uses Nostr won't last long.
anothernostrich
So far, there haven't been many "bad and toxic actors". I have met one bad actor among thousands on nostr and I muted him. I heard there was porn in global chat, but my client doesn't even offer global chat.
People don't consider their relays "hostile", but they don't trust them with things they don't need to trust them with. That's not the contradiction you imagine. Relay operators are trusted with things like spam filtering, illegal content removal, etc. One method is that a proof-of-work is required to start writing to a relay, and your public key can be banned quickly for bad behavior, resulting in another long proof-of-work to try again.
Trusting a relay with account management, for example, is horrible. Trust as little as necessary.
arp242
> So far, there haven't been many "bad and toxic actors"
It's also obscure enough to not even have a Wikipedia article, the "first & best iOS client for Nostr" wasn't published on GitHub until less than a year ago (but wasn't in the app store until this week according to another comment), the Android client they recommend wasn't on GitHub until last month, and the web client they recommend (Iris) didn't add Nostr support until 2 months ago. Edward Snowden seems to be the most prominent user, and he has 5 followers. I don't know if this is broken, because it seems a ridiculously low number, but that's what it displays.
There's lots of things that work well at small scale, but not so well at scale.
solarkraft
> The whole premise of Nostr is that you consider your access point hostile, yet its provider is still offering one.
I'm confused. Doesn't this apply to a lot of projects offering hosting for E2EE services? Why should it be a problem?
class4behavior
As I said in my post - if you read it - private communication and social media are not the same. The expectations are different. On a social media platform you want some level of persistence, you want someone to be able to nurture a healthy discussion culture.
But if all of your users were just fine, there are barely any advantages over a federated platform where you can migrate; much more disadvantages instead.
lapcat
My previous Mastodon instance (mstdn.plus) broke this week, the administrator MIA, leaving 4500 active users including myself unable to move their followers to new instances or even archive their data: https://lapcatsoftware.com/articles/mastodon.html
lazzlazzlazz
Mastodon is essentially centralized — you just pick who you trust with full centralized authority before they have a change of heart, fail, begin rent collecting, whatever.
Nobody seems to understand how difficult it is to make a system that can guarantee its neutrality within the protocol. (Sorry HN: it requires crypto.)
anonkogudhyfhhf
Crypto meaning cryptography yes it's needed. If you a referencing bitcoin like technology used for money no they don't help here. Please enough with this "crypto" ignorance
hem777
Think of cryptos more like “incentives to rational behavior” than “money” and it starts to make sense. You can incentivize, for example, data availability with cryptos and that opens the design space for distributed systems that don’t need to be controlled by one entity (like Twitter, for example).
lazzlazzlazz
How do you guarantee data availability and avoid double spending without Byzantine fault tolerant consensus (that is, blockchain crypto)? If you have an answer you will be onto something huge.
pkulak
Then host your own instance. Your definition of "centralized" as "optionally requiring any trust at all" is pretty broad, and sweeps up even email.
zdragnar
ActivityPub is a protocol designed for decentralization, but the Mastadon software itself really is not a great option for self hosting. In practical terms, for non-technical users (i.e. the people you need for broad adaptation) self-hosting it is a non-starter.
The same is definitely true for email. There are many providers, so "centralized" is a bit of a loose label, but running your own email server comes with non-trivial pitfalls that keep most people away.
immibis
This is why I installed my own Pleroma instance (immibis@social.immibis.com). It's not very difficult. I hear Mastodon is much more painful to install.
libraryatnight
It may need cryptography. I think the majority of HN likes cryptography. When you say crypto, and apologize for it, I assume you mean the stupid coins and all the nonsense that comes with that group of fools, and that is not required.
hem777
It seems to me it does require cryptos. Which luckily are based on cryptography so we all get to like the path forward :)
lazzlazzlazz
How do you guarantee data availability and avoid double spending without Byzantine fault tolerant consensus?
class4behavior
On Nostr, just the migration is easier, but you still need to have your data stored on your device or somewhere else. In turn you communicate with a lot more servers (privacy), those servers have much less incentives to moderate, even if you pay them, or earn its communities trust - hence all the ads and tracking already in place.
dkobia
I’ve been using Nostr, Mastodon and Twitter concurrently for the last few months. Nostr is absolutely fascinating in its simplicity and I really enjoyed writing a Python relay in a few days - more than I should have.
My thoughts:
- The NIPS are not as rigorously defined as RFC's but this is a vibrant community and things are taking shape.
- Relay scaling will be a problem, something Mastodon has discovered with the Twitter migration. The Damus app launch this week brought many relays to their knees. Inevitably as scale becomes necessary relays will centralize.
- Spam, which is free speech in itself, is getting out of control in the relays. Proof of work regulates bots but not crypto spammers.
- The relay construct while powerful, makes it difficult to build real communities with real constructive discourse, which requires some form of moderation. Some might call this censorship.
Aeolun
As it is it seems like very basic spam measures would be enough to cut down on almost all the spam in relays.
leesalminen
Damus recently added a Report button. This button broadcasts a new event of a specific kind to relays with the offending note ID. Other relays/clients are free to take spam measures with this user generated data.
micro_charm
The article doesn't support the claims of how nostr is better than mastodon.
From my quick glance at the site, it looks like relays are the equivalent to servers in mastodon, given that it's unclear why relay owners can't also ban you (as they suggest mastodon servers can ban you), why you can't post to multiple mastodon servers simultaneously (similar to broadcasting to multiple relays in nostr) and so on.
Nonetheless it's good to see the broader adoption of "account creation as equivalent to public/private key creation" in social media services
piperswe
With Nostr, your identity isn't attached to a relay, so if one relay doesn't like you other relays will still relay your content, while still keeping your followerbase
pointlessone
How would my followers (or whatever they’re called in nostr) know where to get my events from?
It seems like optimal strategy is to send to/fetch from every relay possible. Effectively, every relay would host the whole network. In this regard federation seem a little more scalable.
pessimizer
> How would my followers (or whatever they’re called in nostr) know where to get my events from?
I don't know anything about Nostr, but couldn't that easily be solved by adding the relays that you use as a field in your event? Or even using a DHT to find relays that carry content from a particular user?
CodexArcana
I don't know if clients support this yet but you can transmit a suggested relay with your post that people can add to their list of relays. That suggested relay should be one you control. That way they always have a point of truth for your notes.
anothernostrich
This is a current problem. The solution is sending a small message telling everyone where you post to lots and lots of relays, then just posting to a few of them.
lapcat
Yes, this aspect seems problematic.
> to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.
leesalminen
The main difference is that on mastodon your identity is tied to the server you registered on.
So, if a mastodon server bans you, you lose your account, your friends list, and your post history.
On nostr, your identity is a key pair and not tied to any particular relay. If a relay bans you, you can just connect to a new relay, re-broadcast your old notes to it, and keep going. Your friends list stays in-tact.
erskingardner
Yup spot on. The main issue though is that if you want to ensure that you have absolutely unassailable content, you need to run you own relay that ensures all your events are stored. You can’t assume that the relays you connect to via clients are perfect.
I imagine relay services will get better over time here but something to be aware of.
dack
I don't quite understand why a client can't do it's own backup... it's really not that much data i would think. you could sync it to google drive or equivalent, and while your posts may temporarily be unavailable if all the relays are down, you could theoretically re-populate another relay (or your own) with that backed up data right?
Aeolun
People have a lot of complaints, but fact is I can understand this ‘protocol’ without any effort in 5 minutes.
Only Gemini came close, but even though that was technically simpler it still wasn’t as intuitive as just saying ‘use JSON’.
erskingardner
I’m the dev behind Nostr.how. I’d love to hear your feedback on how I can make the site more clear/better at explaining Nostr.
That said, while I am not the core dev on the protocol or any client/relay it’s been awesome to see the points of confusion from the comments and questions here. Keep them coming - great fodder for new guides.
jasonjmcghee
Search doesn't seem to work for me. There are always no results.
leesalminen
Check out https://nostrview.com/search for a nostr search engine and https://nostr.net for a list of various things built on nostr.
erskingardner
Still waiting on the Algolia docsearch team to get me some api keys.
cactusplant7374
I was surprised when I learned it's not really related to Bitcoin. I didn't think Jack would support something that isn't adjacent.
drexlspivey
It’s not really related to Bitcoin but it uses the same crypto primitives, schnorr signatures, secp256k1 elliptic curve etc, if you are building for nostr you can reuse the numerous bitcoin libraries. As a result it’s trivial to implement support for lightning network payments.
leesalminen
It’s trivial to implement support for Lightning network payments virtually anywhere at this point. Damus isn’t using any crypto primitives directly to have a pay button.
legutierr
If anyone is interested in trying out Nostr, I would recommend downloading Damus, the iOS client that’s currently available.
https://apps.apple.com/us/app/damus/id1628663131
It’s not perfect, but it feels a lot like the Twitter iOS client, and gives you an idea of what Nostr can become.
ursuscamp
Also, if you are interested in trying the many web clients, you could try Nostore: https://testflight.apple.com/join/ouPWAQAV
It’s a Safari extension that will store your keys and sign events for you, so you don’t need to enter them into every web page.
Disclaimer: I wrote it.
dom96
Why is it designed for iPad? Surely that's always going to be secondary to iPhone use
lrae
Did you open the link on a Mac (or maybe desktop overall)?
If so I think it just prefers to show you if it is also optimized for iPad usage, because the usage on a mac would be closer to that.
leishman
It works on iPad afaik but isn’t natively built for it. Also works on macOS.
erskingardner
Agreed. Damus is great. Iris.to is probably the easiest to use web client.
Aeolun
> what Nostr can become.
A timeline of a single person (Damus) shouting into the void?
legutierr
The search function can help you find accounts. Your timeline is generated from who you are following. Follow some people and it gets more interesting.
Aeolun
I missed the global function. After blocking a bunch of spammers it seems better.
Still seems like they generate new PK’s once in a while though, so it’s impossible to keep up.
antisocialist
Nostr "relay" nodes have no economic incentive to relay and store data.
Because of that, authors and readers of least popular opinions - which may be legal content that's censored elsewhere - are most likely to be easily identified and tracked.
No incentive to store data, no incentive to relay data, weak privacy, no censorship resistance, relay nodes may be legally responsible for knowingly relaying data from accounts censored by the rest of the network, etc.
For Nostr relay nodes it's like running a Tor Exit node where you may be the only exit node for illegal content.
And for users it's like using Tor to browse the Internet thinking your metadata isn't being captured, without knowing there's just 1 or 2 exit nodes out there.
There are no privacy and pseudo-anonymity advantages over "Twitter over Tor".
therein
I saw this mentioned somewhere else the other day and checked it out. Seems immature to me, something about the lack of structure in their messages, the loose ties to the type enum that they have for messages, feels as if it is not thoroughly thought out.
ursuscamp
It’s something we’re building in real time, as we use it. If you visit the NIPs repo, you will see it changing by the idea. As the clients and relays try things, ideas propagate quickly. In that sense it is extremely exciting.
therein
It is definitely interesting and exciting, at least the end goal. I am still not sold on the architecture but I want to be.
So relays are not able to talk to one another and if I want to be able to interact with another user in any way, we have to be sharing a relay, right?
These seem like really strong limitations to me and I am having a hard time understanding why they exist. Why not start with some relay-to-relay capabilities as well like XMPP has?
CodexArcana
Relays are not prohibited from communicating with each other. There just isn't a defined and agreed on method to do so. Maybe there never will be. But that doesn't mean you can't build a relay server that has a replication feature. It would simply be proprietary.
ursuscamp
I believe multiple relay operators are currently working on R2R communication. It will probably be pretty common soon.
anonymousnotme
I went to:
Then went to:
https://www.nostr.how/get-started
It has a link near the bottom for client comparision:
https://www.nostr.how/clients/comparison
The return code for that page is 404.
Get the top HN stories in your inbox every day.
I read everything there and all NIPs (they look like underage RFCs, but also drunk) and I'm a little confused.
- The protocol doesn't define a transport but seem to use WebSockets. How does it handle poor/dropping connections? Does it allow usage of alternate transport protocols?
- Messages are defined as JSON but doesn't use much of its structure anyway. Some fields are just arrays of values. And even then some parts are just strings with some other arbitrary syntax. Seems like a poor choice.
- Message signatures are signatures of stringified JSON. Given that JSON is not particularly well defined to guarantee representation stability are implementation differences handled?
- Messages are just sent around without any delivery confirmation. There's a NIP to introduce delivery confirmation from the client to relay. And then there's another NIP to signal completion of messages retrieval from the relay. Both are optional.
- It's unclear how to preserve/port data. A relay is supposed to keep (or not) messages and the client is supposed to send messages to multiple relays. But what happens when a relay goes down? Can a client send messages to a new relay? Should the client keep all messages just for such a case?
Overall feeling after reading all that is it's XMPP but worse. It's worse defined. It's not quite decentralised as there's a single point of failure: relay. And it's unspecified how to handle demise of a relay and port data to another relay. Signing and encryption is nice but message structure makes me feel dirty. XMPP wasn't inititally meant for a decentralised public messaging but there are a few XEPs that do exactly that, as well as signing and E2E encryption. And all other good stuff like BOSH (XMPP over HTTP), for example.