Nostr.how – A Complete Guide to Nostr
nostr.how
nostr.how
- 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.
- 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)
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?
There are alternatives like ENS. I don't mind Nostr just simply having its own system.
There are the universally accepted root servers, ICANN, national registrars, etc.
But nothing prevents you from trusting additional root servers, with TLDs if your choice, delegation of subdomains from them, etc. All the standard mechanisms will just work. Your router likely supports the .lan TLD out if the box.
DNS the system that we all depend on depends on the assumption that we all use the ICANN root servers.
I would say there's still some degree of centrality for ENS, but it is more decentralized than DNS.
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.
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.
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?
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
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.
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.
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.
Yes, a user can transmit a previously created note to a new relay at any time.
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.
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.
At the same time, nothing prevents a user from migrating to a different client that has no "algorithm".
Moderation is vital for public social platforms.
This is just crowdsourced moderation then? Which relies heavily on there not being bad actors that can be incentivised to run up botnets to generate bogus flags/reports to push their own agenda.
Just spit ballin
Choosing the right amount of freedom is always a balancing act.
The same thing is not true for say, Twitter, where I only see posts from people I explicitly follow.
If you are in control of your mail server you can block email addresses, even entire domains or IP spaces. I do not understand this statement.
Of course you can set your email server to reject every single email that you do not have in a whitelist, but that’s not a feature of the protocol. Plus it’s something you need to manually do (because most people don’t want -or expect that- from email).
People expect Twitter (or similar apps/protocols) to not show them messages other than from people that are explicitly followed.
edit: Opt-in, not opt-out. Whitelist, not blacklist.
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.
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.
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.
I'm confused. Doesn't this apply to a lot of projects offering hosting for E2EE services? Why should it be a problem?
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.
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.)
SSB has something like this but it requires a user to download another user’s entire post history before being able to see one post. Makes the experience very slow.
Timestamping is already possible using the bitcoin blockchain. No token scam or new blockchain needed
I didn't say decentralised timestamping is required for a social network or any blockchain needed
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.
That said I do prefer a mail-based system like Delta Chat [1] over these ActivityPub-based things since everyone already has a mail address and there is a wide range of software to choose from.
Gateway operators are paid to store data
Gateway operators are paid to mix client-side encrypted messages and shred message metadata
Gateway operators are staking their nodes to ensure cryptographically correct operation
If you want to see more, spend some time reading how blockchain-based networks with incentives work.
Decentralized namespace registries - see Farcaster.
Autonomous and decentralized mechanism that rewards & incentivizes users to run nodes/servers - see Ethereum staking, Filecoin.
Another solution that is arguably more resistant to capture and censorship would be to use a blockchain to manage user name aliases - like Farcaster is doing with fnames.[1]
[1] https://github.com/farcasterxyz/protocol#22-farcaster-names
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.
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
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.
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?
> to "follow" someone a user just instructs their client to query the relays it knows for posts from that public key.
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.
I imagine relay services will get better over time here but something to be aware of.
Only Gemini came close, but even though that was technically simpler it still wasn’t as intuitive as just saying ‘use JSON’.
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.
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.
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.
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.
A timeline of a single person (Damus) shouting into the void?
Still seems like they generate new PK’s once in a while though, so it’s impossible to keep up.
Also https://nostr.directory helps me find people on Twitter in nostr.
Took a bit I’m happy with my normal feed now and use Global less and less.
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".
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?
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.
In the end, most people aren't hardcore libertarians and do want content moderation, centralized discovery, spam blocking... I would really find it interesting if it came about a protocol that actually cared about those things and provided a way to handle them other than a megacorp doing all of it. But all those protocols operate under the assumption that people are okay with seeing really bad things that real people come up with (even CP like commented elsewhere in this thread) themselves under the guise of "full decentralized liberty".
I suspect that's why they all ultimately fail or at least remain niche things. If the alternative to megacorps is this wild west, people will remain in the megacorps' social media.
If this happened, users would be free to opt-out of that and switch out their client and/or relay with other options that fit their needs without friction. They would keep their identity, note history, friend list, etc.
Could be as simple as one client releasing a UI change the user hates. They could just download a different app and keep going.
To be clear, Damus already offers some level of content moderation. Other clients are accepting PRs to implement as well. Nostr itself offers some level of centralized discovery with NIP-05. Relays are starting to look at spam filtering (via pay-to-post models mainly).
And of course all the dynamics you talk about emerge naturally. With scale comes concentration and hierarchies out of necessity, the power to blocklist 'relays' across the largest instances, etc.
All these experiments basically are a venture in rediscovering economics and politics. The internet started out decentralized. Reinventing html and web servers isn't changing anything.
If so it’s only a happy path and doesn’t handle the very common migration scenarios of falling out of favor with your server owner.
No, nostr does not have a blockchain.