I think it's worth knowing that the cryptography in Nostr appears to be a wreck. Here's a paper from EuroS&P this year, also presented at Black Hat on the crypto track:
* The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.
* Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.
* DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.
* The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).
* There's no key separation in the system, so you can trick users into running a subprotocol other than the messaging system, then establishing a session key, which will then be used for messaging.
These are really basic errors; this is mid-aughts-level cryptographic engineering. There are probably a variety of other reasons to use Nostr, but end-to-end security does not appear to be one of them.
So, I was part of the Nostr community for quite a while and was the author of a popular Nostr extension for Safari, before eventually giving up on Nostr for various reasons.
I haven't read that entire paper. Mainly, I skipped to the section you mention here:
> The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.
I think you and the authors perhaps misunderstand the Nostr protocol. Nostr is, effectively, an identity system tied to a public key. The cryptography is sound. Your identity is your public key. When you request a user's profile, or their events, you request it specifically by their public key. That is unforgeable (assuming no bugs in the implementation, like what the authors found in Damus).
This does present UX issues that can manifest as security issues, such as "how can you verify that a user with a certain public is who they say they are instead of an impostor". That is a separate issue from whether the cryptography itself is sound.
If you read the entire paper you'll see that the paper presents a formalized set of security goals that acknowledge Nostr uses public keys as identities. They haven't misunderstood the system. Meanwhile: the cryptography is obviously unsound: it relies on unauthenticated CBC, and signatures that aren't verified, and provides attackers with the ability to coerce users into following links.
Unfortunately this paper doesn't live up to its goal of being a cheap attack on Nostr.
The fact is that clients do verify signatures from events received from servers, that is in the protocol specification and should be obvious to anyone mildly honest.
The entire assumption of the paper is that clients don't do that and it is void. Yes, they did find a couple of clients 2 years ago that didn't verify signatures -- so much for a vulnerability in the protocol. I guess they wanted Nostr to have a code police arresting client developers who didn't finish their implementation?
Aside from that the attacks they demonstrated depend on a bunch of other absurd circumstances (like you have to manually and voluntarily type the URL of the attacker server in order to be attacked) but it's not even worth talking about them since the basic assumption is so completely false already.
The encrypted messages stuff is not even a core part of Nostr anyway, Nostr is a broadcasting protocol for public or semi-public content. Encryption can be added on top and there are multiple ways and proposals for how to do it, including an implementation of MLS and other methods and I personally mostly do not care about any.
I wish the paper authors were more honest and republished their work with the title: "the dangers of trusting a cryptographic signature without verifying it", but I imagine that it would have been too obvious and worthless if it was phrased like that.
They're academic cryptography researchers. They do not care what messaging system you use. This is what academic messaging cryptography papers look like; a paper like this is why Matrix transitioned (is transitioning?) from ad hoc cryptography to MLS.
> The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.
This is completely nonsense, most clients do in fact check signatures. All relays do as well.
> Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.
Author of Damus here. this is an analysis of an old version. This has since been fixed. In the early days we connected to a fixed relay list of trusted relays. These relays verified signatures. This was just a pragmatic tradeoff thing until we had an optimized work queue for verifying notes (this lead to nostrdb, a custom embedded nostr database built on lmdb. it's a sqlite but for nostr https://github.com/damus-io/nostrdb)
> DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.
not really true since the whole note is covered by a secp256k1 signature.
> The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).
you can turn off these, you can turn off images as well. people should run a VPN of course if they are worried about these things.
I don't think you can say "this is complete nonsense" and "this has since been fixed" in the same comment. Also: don't use ECC signatures as MACs. Signatures are not MACs.
The criticisms are either implementation dependent (not checking signatures, which defeats the entire purpose of the protocol), or based on a very early proof of concept encryption scheme which has since been superseded (by NIP 44, which was independently audited). There's nothing substantial or actionable here (any more).
why is this the first time that I came across these issues. Someone should talk about these issues asap.
What federated platform might be the more secure tho protocol wise, bluesky (at protocol) or fediverse
The paper seems to be referencing issues in client apps during early development of those apps that have since been fixed. So that's likely why it's not being talked about now.
A big misconception I've seen is the assumption that Nostr relays are federated and share messages between one another. This is not how it works. So if you're building a "Twitter clone" the client app must search multiple relays and post to multiple relays. If clients are not using a relay in common they cannot see one another.
The end result is a bad experience for both user and developer. Using a single relay is centralised and defeats the point. Using multiple relays is slow and cumbersome and requires the user to know/care which relays they are connecting to.
When I played with Nostr a couple years ago the "NIPs" were already a complete mess. Later NIPs supersede earlier NIPs changing how clients are supposed to interpret messages. At least some are flagged as "unrecommended: deprecated" now.
Relays can federate. The point is that Nostr as a protocol is saying nothing about this and does not care either.
I'm running an indexer (a relay) which federates with other relay indexers. Similar how activitypub relays work. Any client can connect to indexer to help bootstrapping and find metadata around events. There are many ways to discover stuff from clients even without being connected to the same relay.
This is a valid observation and hurdle of sorts. One to me, which is a fascinating problem to work on.
There are a few approaches to solve this. For instance NIP65, where one defines on their profile meta which relays they read/write to, giving clients the ability to discover all the right content. That's just one approach, and some are exploring other ideas. It seems like a very solvable problem anyway.
That's a misconception: you don't "use" relays (in the sense that you don't have to have a static list of relays you always use), you write to relays. When reading you connect to the relays of whatever the people you want to read from.
Some apps indeed use this method of selecting a static set of relays, and if that was the protocol you would be correct about centralization or bloat, but this is legacy from a naïve unfinished early implementation, most apps do the correct thing now and the rest is transitioning.
Most clients now support outbox, so you don't need a common relay. Users have inbox and outbox relays, and clients use these to retrieve and send notes.
Since relays don't own user generated content, there is no need to "federate" client's generally rely on user-selected relay sets. The user chooses where they want to read/write events to/from.
That said, many of the "larger" relays do store events from other relays (federation if you prefer). Primal does, TheForrest does, nostr.land and so on. Nostr.land specifically has a purpose of aggregating notes from many other public relays, with spam filtering. It's a paid relay built for that purpose. Don't want that, use someone else.
Most users get to see 99% of notes from the current relay federation now, but it's also impossible to check those metrics.
Certain clients and signers store notes privately so if a relay ever decides to censor your notes you just publish to a different relay if they don't have your notes already.
Chances are if you use ANY of the popular paid relay providers, your going to get warnings on 3/4 write events that the other relays _already_ have the note published to the first. It's usually that quick...
Finally, relays "federate" by acting as clients themselves. Most relay software available already offers this as an option, may use it as a local cache for when on mobile and network/wifi is slow. Their local relay slowly pulls notes from other relays (or outbox) and caches those notes for when they load their client up. It's cache and the client dev didn't even have to write that functionality, it was transparent.
Finally, other's mentioned outbox, which has it's own set of issues as well, but it doesn't matter because a client developer can choose to give the user the option if they want. Going from federated, to peer-to-peer which was the intention.
There are some messed up things on a few NIP because the technology evolved fast.
Most NIP are fine and continuously improved.
This is trivial to solve when there is there a periodic release of the NIP as done in other specs. So far there hasn't been much need for that formality, most developers understand quickly how to create tools on top of it.
Mastodon merged their server-side recursive fetching of remote replies feature in the summer of this year so unless instance admins used 3rd party scripts to achieve that you couldn't rely on your reply actually being shown to the recipient. ActivityPub is complicated like that.
Nostr has a better UX than ActivityPub IMO, for the basic reason that you do not need to learn how to self-host a server or depend on an unaccountable admin that might shut down the server at any time. In Nostr, you just create an account and go!
The big issue is the lack of content, but that's a social problem, not a UX problem.
Nostr’s UX on Primal is 10x better than Mastodon imo. I haven’t looked into how it works but every time I try an application with it, it’s been an unpleasant experience.
Why can't these projects separate the use-cases from philosophies and from implementation when presenting them?
At first glance I don't understand what this is. Is it a social network? A protocol? "Pro-censorship? I need to read some blog article...
It's been like this with scuttlebutt/gossip, and rest of the alternative internet/fediverse with mastodont and activitypub and diaspora. Instead of asking questions like "How is this different than email? How does it compare to twitter?", I have to start with "What am I looking at? A technical implementation or a product? Is it a website or an app? What am I supposed to do with this?
There's also Urbit, which I'm sure not a single one of you can explain exactly what it is.
It's not as bad as "Web3", I'll give it that.
Bluesky got it right.
So did gemini to some extent.
Nostr is essentially a compromise between p2p and traditional web architectures. It cuts with the grain of the internet by using web servers, while reducing the dependence users have on servers by using keys for identity and digital signatures for authenticating data.
The effect is that users have "credible exit" (among other things), which has been discussed for years. This doesn't really create any new "use cases", which is why the use case is often described as "whatever, it's the new internet".
What it does do is introduce a very different set of trade-offs which favor user control over platform control (with the attendant UX trade-offs (or at least a different set of UX idioms)).
The reason the focus is on social is because that represents the majority of applications that do exist, the original motivation for building the protocol, and a value proposition (censorship resistance) that lots of people can relate to.
I don't want to be mean, but this post has exactly the problem the person you're replying to was complaining about. The person you're replying to, I think, would like an explanation that reads more like "It's like Twitter, but not tied to a mega-corp, just for you and your pals". I don't know if that description actually fits Nostr though because, like the person you're replying to, I have a pretty hard time understanding what Nostr actually _is_.
My "apolitical" shirt has people asking a lot of questions already answered by my shirt. What an odd word to use in the first sentence of your product description, which also includes the word "open", an inherently political concept in this context.
Did/does Nostr have some cryptocurrency connection or am I thinking of something else?
They explicitly don't have a "nostr coin" or do anything "on chain" which I applaud them for especially since the Venn Diagram of Nostr and the crypto community is basically a circle.
I concur and "apolitical" is probably not the best word. I think it is an attempt to convey that the platform can't ban people. It is resistant from infrastructure censorship. Here is an example specific use case:
My back-burner idea: the equivalents of Nostr relays, Mastodon instances, Discord servers, etc. needs to be self-hostable in client apps for decentralized social media to work.
Not only classical P2P software did exactly this, it worked/works beautifully. The only reason classical P2P software did not work and did not replace WWW as application was because of piracy prosecutions that makes users responsible for hosting data with unknown content that would be later revealed to users to have been pirated content that the user would be criminally responsible a la illegal substances through airport checkpoints.
That's bad - both the fact that users' passive actions are incriminating, and substances too. So the next-gen P2P would have to have plausible logging content filters such as AI-based CP and Hollywood detectors that would stop relaying of such content so that users can defend themselves in criminal courts. Or the systems could also be in-circle specific so nothing of value is lost if everyone in a terrorist group would be prosecuted together, though I imagine that could hamper network growth.
But fundamentally, I think the model has to be that all clients are also servers. That's the best way to decentralize a social media.
This is cool but P2P doesn't work. Iroh also relies on "relays" in a sense. Nostr makes that explicit and gives relays identities so they can freely enact policies instead of having to hack that in weird ways.
* relays can just go away - you don't have your data then
* there is both user-friendly and secure way of managing your private keys; additionally, once your keys are gone, your identity is gone - there is no "I forgot my password" procedure
Glad to see Nostr on top of HN. It is in its infancy, but Nostr allows for "zapps" (basically sending instant micropayments via bitcoin-lightning) - so instead of using ads and dubious algorithms, you can show your appreciation to content creators by small payments. This is a model for an ad-free, decentralized social media system.
I almost want to sign up now because I read comments like this and it sounds abhorrent and stupid, but then I go click explore on the actual page, and the first page of stuff I see is people actually making and selling real stuff. Sure, they take payment in Bitcoin, but they're selling ghee and cacao and there's a community of people interested in alternative schooling. It's not "I'll show you my diary and you pay me for it" that you're describing here. Real goods and services, not "content."
And extremely centralized in the so-called Lightning version. Due to ridiculously absurd requirements of the Lightning layer (bidirectional channels on L1, locking funds in advance, solving NP-hard problem thousand times per second a scale etc.) everyone basically resorts to using very few centralized entities as a pseudo-bank, who issues virtual paper, IOUs, which which wallets trade on L2. Basically all negatives of the banks and all negatives of crypto-tokens combined, with no positive sides at all.
Only for tax purposes in the US. If you're worried that your speech will be censored by the government (importantly: corporate social media can censor you on their platforms but can't censor your BTC usage in most developed countries), then declaring BTC for tax purposes is probably the least of your worries in most places.
As far as I understand as a non-US citizen, the recent presidential bills anchor your (US citizen-) right to deal in bitcoin between private entities. So the "good" kind of regulation.
Even if you don't use Nostr as a microblogging social network, it can provide a useful layer. For example Trystero https://oxism.com/trystero (MIT licensed) can use it to establish P2P WebRTC connections without requiring a central server.
Thats cool I have been thinking of using nostr , Bittorrent DHT and Mastadon as a cencership resistant multi channel redundant broadcast beakon. All methods must go down before your nodes can't find each other anymore.
This is very interesting. In a similar vein, I was wondering a while ago if either Nostr or ATProto could potentially work as part of a peer-to-peer instant messaging system, specifically as a way to have persistent storage and offline messaging. (But using it to establish connections is pretty clever, too.)
wow this is amazing. was thinking about whipping something similar for my own project but glad that someone had same problem before. saved me some time.
Readit News
https://eprint.iacr.org/2025/1459.pdf
The vulnerabilities here are pretty :yikes:
* The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.
* Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.
* DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.
* The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).
* There's no key separation in the system, so you can trick users into running a subprotocol other than the messaging system, then establishing a session key, which will then be used for messaging.
These are really basic errors; this is mid-aughts-level cryptographic engineering. There are probably a variety of other reasons to use Nostr, but end-to-end security does not appear to be one of them.
I haven't read that entire paper. Mainly, I skipped to the section you mention here:
> The event protocol that drives the system doesn't authenticate public keys, so asymmetric signatures are performative: attackers that can intercept messages (Nostr servers, the presumed adversary of an E2EE messaging system) can just swap out keys and re-sign.
I think you and the authors perhaps misunderstand the Nostr protocol. Nostr is, effectively, an identity system tied to a public key. The cryptography is sound. Your identity is your public key. When you request a user's profile, or their events, you request it specifically by their public key. That is unforgeable (assuming no bugs in the implementation, like what the authors found in Damus).
This does present UX issues that can manifest as security issues, such as "how can you verify that a user with a certain public is who they say they are instead of an impostor". That is a separate issue from whether the cryptography itself is sound.
This sounds awfully much like a cryptography problem to me!
Dead Comment
The fact is that clients do verify signatures from events received from servers, that is in the protocol specification and should be obvious to anyone mildly honest.
The entire assumption of the paper is that clients don't do that and it is void. Yes, they did find a couple of clients 2 years ago that didn't verify signatures -- so much for a vulnerability in the protocol. I guess they wanted Nostr to have a code police arresting client developers who didn't finish their implementation?
Aside from that the attacks they demonstrated depend on a bunch of other absurd circumstances (like you have to manually and voluntarily type the URL of the attacker server in order to be attacked) but it's not even worth talking about them since the basic assumption is so completely false already.
The encrypted messages stuff is not even a core part of Nostr anyway, Nostr is a broadcasting protocol for public or semi-public content. Encryption can be added on top and there are multiple ways and proposals for how to do it, including an implementation of MLS and other methods and I personally mostly do not care about any.
I wish the paper authors were more honest and republished their work with the title: "the dangers of trusting a cryptographic signature without verifying it", but I imagine that it would have been too obvious and worthless if it was phrased like that.
This is completely nonsense, most clients do in fact check signatures. All relays do as well.
> Two major clients, the mobile phone Damus app and the web Iris app, don't even verify signatures to begin with.
Author of Damus here. this is an analysis of an old version. This has since been fixed. In the early days we connected to a fixed relay list of trusted relays. These relays verified signatures. This was just a pragmatic tradeoff thing until we had an optimized work queue for verifying notes (this lead to nostrdb, a custom embedded nostr database built on lmdb. it's a sqlite but for nostr https://github.com/damus-io/nostrdb)
> DMs in this system are unauthenticated CBC, so attackers can simply bitflip messages and events to say what they want.
not really true since the whole note is covered by a secp256k1 signature.
> The apps do automatic link-preview, so they've managed to reconstitute the EFAIL attack: attackers can locate links within messages (they'll be revealed by SNI and DNS anyways) and then bitflip them to point to attacker-controlled servers, exposing both the URLs (which will often contain tokens) and, with a bit of extra work, the message itself (by tacking `?foo=` onto a URL).
you can turn off these, you can turn off images as well. people should run a VPN of course if they are worried about these things.
https://hellonostr.dev/en/introduction/
The encoding seems to have an unmentioned/unaddressed version number included, both in the nostr doc and the bitcoin docs.
npub1abcxyz... is npub (header) 1 (version) abcxyz... (key)
Now take a look at the doc (linked above.)
The end result is a bad experience for both user and developer. Using a single relay is centralised and defeats the point. Using multiple relays is slow and cumbersome and requires the user to know/care which relays they are connecting to.
When I played with Nostr a couple years ago the "NIPs" were already a complete mess. Later NIPs supersede earlier NIPs changing how clients are supposed to interpret messages. At least some are flagged as "unrecommended: deprecated" now.
I'm running an indexer (a relay) which federates with other relay indexers. Similar how activitypub relays work. Any client can connect to indexer to help bootstrapping and find metadata around events. There are many ways to discover stuff from clients even without being connected to the same relay.
Some apps indeed use this method of selecting a static set of relays, and if that was the protocol you would be correct about centralization or bloat, but this is legacy from a naïve unfinished early implementation, most apps do the correct thing now and the rest is transitioning.
That said, many of the "larger" relays do store events from other relays (federation if you prefer). Primal does, TheForrest does, nostr.land and so on. Nostr.land specifically has a purpose of aggregating notes from many other public relays, with spam filtering. It's a paid relay built for that purpose. Don't want that, use someone else.
Most users get to see 99% of notes from the current relay federation now, but it's also impossible to check those metrics.
Certain clients and signers store notes privately so if a relay ever decides to censor your notes you just publish to a different relay if they don't have your notes already.
Chances are if you use ANY of the popular paid relay providers, your going to get warnings on 3/4 write events that the other relays _already_ have the note published to the first. It's usually that quick...
Finally, relays "federate" by acting as clients themselves. Most relay software available already offers this as an option, may use it as a local cache for when on mobile and network/wifi is slow. Their local relay slowly pulls notes from other relays (or outbox) and caches those notes for when they load their client up. It's cache and the client dev didn't even have to write that functionality, it was transparent.
Finally, other's mentioned outbox, which has it's own set of issues as well, but it doesn't matter because a client developer can choose to give the user the option if they want. Going from federated, to peer-to-peer which was the intention.
Most NIP are fine and continuously improved.
This is trivial to solve when there is there a periodic release of the NIP as done in other specs. So far there hasn't been much need for that formality, most developers understand quickly how to create tools on top of it.
Deleted Comment
The protocol's real value lies in other use cases.
The big issue is the lack of content, but that's a social problem, not a UX problem.
At first glance I don't understand what this is. Is it a social network? A protocol? "Pro-censorship? I need to read some blog article...
It's been like this with scuttlebutt/gossip, and rest of the alternative internet/fediverse with mastodont and activitypub and diaspora. Instead of asking questions like "How is this different than email? How does it compare to twitter?", I have to start with "What am I looking at? A technical implementation or a product? Is it a website or an app? What am I supposed to do with this?
There's also Urbit, which I'm sure not a single one of you can explain exactly what it is.
It's not as bad as "Web3", I'll give it that.
Bluesky got it right. So did gemini to some extent.
The effect is that users have "credible exit" (among other things), which has been discussed for years. This doesn't really create any new "use cases", which is why the use case is often described as "whatever, it's the new internet".
What it does do is introduce a very different set of trade-offs which favor user control over platform control (with the attendant UX trade-offs (or at least a different set of UX idioms)).
The reason the focus is on social is because that represents the majority of applications that do exist, the original motivation for building the protocol, and a value proposition (censorship resistance) that lots of people can relate to.
Did/does Nostr have some cryptocurrency connection or am I thinking of something else?
https://how-nostr-works.pages.dev/
I find that example pretty humorous... Damn, what kind of controversy is Pamela spreading?
I like it but feel nervous that there is synergy with the bitcoin space. Hype and validation is thick in that space
Not only classical P2P software did exactly this, it worked/works beautifully. The only reason classical P2P software did not work and did not replace WWW as application was because of piracy prosecutions that makes users responsible for hosting data with unknown content that would be later revealed to users to have been pirated content that the user would be criminally responsible a la illegal substances through airport checkpoints.
That's bad - both the fact that users' passive actions are incriminating, and substances too. So the next-gen P2P would have to have plausible logging content filters such as AI-based CP and Hollywood detectors that would stop relaying of such content so that users can defend themselves in criminal courts. Or the systems could also be in-circle specific so nothing of value is lost if everyone in a terrorist group would be prosecuted together, though I imagine that could hamper network growth.
But fundamentally, I think the model has to be that all clients are also servers. That's the best way to decentralize a social media.
https://www.iroh.computer/docs/concepts/relay
https://asknostr.site/
I hope this demonstrates how a distributed social protocol can solve many use cases and the advantage to the end-user:
- do not get rugpulled by (VC backed) companies that own your data
- receive zaps/money by contributing
- data is truely available to everyone (but signed by author)
* relays can just go away - you don't have your data then
* there is both user-friendly and secure way of managing your private keys; additionally, once your keys are gone, your identity is gone - there is no "I forgot my password" procedure
Nostr has existed for at least 5 years. I remember people migrate there and promote it on Twitter during pandemic. Infancy?
We've been hosting some bounties like this one here: https://app.lightningbounties.com/issue/615dc5f7-ed91-4ecd-8...
Can this forgo needing the STUN/TURN server? If this is the case then it is huge!