Nostr is a simple, low-level building block for decentralised social media or other messaging interactions.
- Nostr Clients run as a library in third-party apps (either on the frontend or backend), and connect to one or more Nostr Relays to send and receive data from it.
- Nostr Relays accept connections and messages from Nostr Clients, and may (or may not) broadcast the received Client data to all the other connected Clients.
- There are around 1000 existing listed Relays, and anyone can run their own Relay.
- On Nostr, each user is represented by a raw public key, and each message (called “events”) is signed.
- There is no protocol requirement on data persistence over time by Nostr Relays.
- Data may or may not be persisted by the apps that control the Nostr Clients, or by the user’s own Nostr Relay.
- Nostr also supports messaging channels and Bitcoin tips between Nostr users called “Zaps”, via the Lightning Network.
Advantages
- Simple building block that is un-opinionated and versatile enough to be used in a wide variety of products and for many different use-cases, that may or may not be related to social networks. Unlike most of the other contenders presented in this state-of-the-art, Nostr can be regarded as an independent low-level infrastructure building block, the same way as IPFS or even libp2p would be.
- Interactions between Nostr Relays and Nostr Clients are done via simple client-server interactions, and because of this, it faces different scaling/tooling/performance challenges than server-server federation or p2p network face. It is therefore an interesting alternative to these techniques when designing a product/protocol architecture, depending on the requirements.
- In particular, unlike peer-to-peer solutions such as BitTorrent or those implemented with libp2p, Nostr relies on a client-server infrastructure and as such its transport-level privacy can be protected by mixnets such as Tor.
Limitations
- Nostr is pushed by Twitter co-founder Jack Dorsey, who identifies himself as a Bitcoin maximalist, and the Nostr community is mainly made of a subset of the Bitcoin community, incidentally inheriting its structural cult-like toxicity (see “cryptocurrencies” section). As a result, Nostr as a social network struggles to scale outside of this niche community.
- Nostr is presented by its creators as a complete solution for a decentralised social network, and many products (Damus, Plebster, Yana…etc) build social networks directly on it, including on its raw identity system. According to the Nostr landing page, other decentralised social networks such as Mastodon would be unnecessarily complicated and Nostr simplicity would be sufficient. However, in reality, the Nostr identity system “as is” isn’t fit for a full-fledged social network. To be supported, each of the following lacking features would need to be manually implemented on top of Nostr. Doing so individually would not be interoperable between apps because it would not be baked-in the protocol, besides being extremely complex to implement:
- Key Rotation is not supported: user A follows user B using user B’s public key, hence user B cannot rotate its asymmetric key pair without user A losing its connection to user B. Key rotation is often required for security reasons, especially for keys that are meant to be used frequently, like it is the case for a social network built directly on the Nostr identity system: every interaction a user does must be signed.
- Account Recovery is not supported: if a user loses its private key, the user loses access to its account forever. That would encourage wallets to become particularly secure, which would in exchange make signing every transaction particularly painful in terms of user experience.
- Portability between devices is not supported: since the user identity is related to its single key pair, and for security reasons, a key pair should be generated on one device to never leave it, cross-platform account login and synchronisation are particularly cumbersome, involving third-party wallets.
- Nostr’s architecture makes it difficult:
- To obtain data history at all, as Nostr Relays are not required to persist data over time and are not synced between each other (federation).
- To get linear messages history (problem similar to what we see in p2p networks), both:
- In terms of time history, because users have to be trusted to write the right timestamp in the “created_at” field, and the OpenTimestamp attestation tag for Events is optional.
- In terms of data consistency, because some messages may have been lost or sent to an inaccessible Relay.
- Nostr does not solve sybil attacks: one “user” equals one key pair, but anybody and any machine can create an infinite amount of key pairs.
- Nostr uses the Bitcoin standard “secp256k1” for identifying users via their asymmetric key pair. While this standard makes perfect sense from a security perspective (after all it has protected billions of funds from the whole world for more than a decade), it makes Nostr less usable, as this standard is supported neither by mobile secure storage nor by the standard WebCrypto API, so users must rely on external hardware wallets if they want the best protection for their keys. Nostr could benefit from an account abstraction layer, and more crypto agility.
- Nostr protocol, used directly as a full-fledged social network, incurs a lot of unnecessary requests, which impacts performance. Nostr’s architecture encourages every Nostr Client to try to connect to as many Nostr Relays as possible in order to get the most up-to-date data possible. If an app wants to fetch the posts of the user named “Foo” identified by its certain pub key, the app will ask as many Relays as possible to get Foo’s data if they have some. As a result, Nostr Relays are flooded with requests that they may not be able to respond to, and Nostr Clients maintain an increasing amount of connections to an increasing number of Nostr Relays.
Could it be useful for our requirements?
- Using Nostr as a decentralised social media protocol over which we directly develop our social app would bring almost only anti-features, except from a Censorship-Resistance perspective.
- However, Nostr used as a pure infrastructure building block can be a powerful way to implement Censorship-Resistance only (either Decentralised Moderation or Verifiable Moderation), without importing the other anti-features. Unopinionated and flexible, Nostr could allow our users to broadcast the verifiable data that our privacy-preserving protocol could generate, without compromising on the user's privacy.