Nostr has gained a lot of attention and steam behind it since it was added to the list of alternative social platforms that are banned from promoting on Twitter. And it also gained traction because it was clear that the purchase of Twitter by Elon Musk did not change anything in terms of freedom of expression on the platform – users are still banned for inconsistent and arbitrary reasons, and people are looking for a decentralized alternative that is not like Mastodon , where the server operator still has the ability to control your identity.
Despite the recent attention, the Nostr protocol and the first relay server implementation were actually created at the end of 2020 by fiatjaf developers. Before the explosion of attention, it was just a quiet niche protocol trying to be a lightweight solution to the problems of Twitter and Mastodon. In both systems, your identity/username is the only thing controlled by whoever is running the server. Mastodon is a federated system with many different servers all talking to each other doesn’t change that fact. Whichever server you use to host your account has total control over whether you can use it or not. Even open the server itself, other server operators can black- or whitelist which server will be allowed to talk with that. This has caused a lot of separation in the “Fediverse” from different Mastodon servers and makes the idea just pointless. You can still end up being censored by other server operators, preventing users from seeing your content in their feed.
The core difference between Nostr and the likes of Mastodon is that, instead of using a username owned by the server operator, each user uses a public/private key pair to handle the functionality. It’s something that the server operator can’t just take from you or lock you out of. This is one of the core building blocks on top of which the overall Nostr protocol is built.
Next is the “event”. This is the basic object/data type used by the client and the relay server that the client connects to to send and receive messages. The general idea of the protocol is that clients send events to a relay server, which then stores and indexes them, and other clients can communicate with the relay server to request events that have been received and stored. In the original NIP 01, three different types of events were defined:
- 0: Send metadata about the user, such as username, picture, bio, etc.
- 1: Send text messages and basic content
- 2: Recommend a relay server for people who follow the event creator to connect
All events are arranged in a specially defined manner. This includes the public key of the creator, the timestamp when it was created, the type (or types in the specification), the content payload and the signature of the event creator. They can also have tags that refer to other events or users, and have an ID value that is a hash of everything except the creator’s signature (similar to the TXID for Bitcoin transactions). This allows you to guarantee that the message was actually created by the owner of the public key inside by verifying the signature (and the person who has the key if it is not compromised), and ensures that the message is not modified after they are signed. Just like you can’t modify a Bitcoin transaction after logging in without canceling it, you can’t modify Nostr events after the creator has logged in without obvious fraud.
The event type system has been expanded quite a bit from the original NIP. There is a type of event for encrypted direct messages, creating a shared key by combining the sender’s private key with the receiver’s public key, which produces the same key that you will get by combining the sender’s public key with the receiver’s private key (this is how BIP 47 and Silent Payment ). There are also mutable event types and ephemeral events. In the case of mutable events (obviously), it is designed so that the original creator of the event can enter a new event to replace the old one. A relay server according to this specification will drop old events from storage and start sending new versions to clients when they are received. Ephemeral events are designed to be broadcast to anyone who subscribes to the creator when they are sent to the relay, but the relay server does not necessarily store them. This makes it possible for messages to be seen only by people who are online during the broadcast. There are even event types to mark reactions (such as likes or emojis) to other people’s events.
Speaking of the latter, events can also contain tags. There are currently tag types for events (for proper Nostr event references), public keys (for tagging or other user references) and subjects (for imitating functions, such as email subjects). All this can include pointers to specific relay servers from where the data can be retrieved so that users can interact between servers, that is, users sending content to relay servers can interact and reference content created by other users. different relay servers in a way that allows the user to get all the interactions in the right order and without the great complexity of finding out where to find the relevant data.
In the original NIP, a specification was given on how the client could interact with the relay server through a subscription message/data structure that included filters for what events the client wanted. The filter can specify the user’s public key, the exact event, the type of event and also the specific time frame that is desired based on the previous criteria. You may also send a public key prefix or event ID, such as “1xjisj….” and receive any event or events from the public key starting with that short string (can be useful to hide from the relay server what you want to see).
Overall, the protocol is a general scheme for sending messages between users that includes important things, such as ensuring the integrity of the message and the sender using a public key identity, and also facilitates the infrastructure in the backend for server relays that can be very rare. centralized or allow users to run their own private relay servers, all while seamlessly interacting with each other and not causing massive chaos in the event of a banned user from one relay server. They can move to another or open themselves and de-platforming from the previous server will not lose their digital identity or followers because they still control the private key and users can authenticate when they find it elsewhere.
A relay server can be used but it is also desired. They can operate for free, can charge micropayments to send or download messages, and even have a NIP to require hashcash proof of work to send messages. It can be a single relay server for hosting and only serving your posts to other users, or it can be a server that runs on a large scale such as Twitter or Reddit (clients can display and manage any information they want, which allows replicating all social. media platforms that there now). All of these can interoperate seamlessly and without disabling the user. You can prevent them from sending content to a relay server, but ultimately you can’t prevent them from viewing content hosted on a relay server or prevent other users from finding that content on other servers.
It is a very simplistic protocol with a large, open design space for people to build, ensuring that users can always communicate with each other regardless of whether the individual relay server operator chooses to host or not host. This is his greatest strength and his greatest weakness. While it guarantees the freedom for developers to build without strict constraints by complex protocols, there are also many issues that will be addressed that are not addressed by these protocols.
In the next part of my writing, I will go to some of the problems I see happening and potential solutions, but for now, I will only say that in terms of clarity of design and the possibilities open to people. build, Nostr has done a very good job, considering it is the brainchild of one person and only a few people have really contributed to the specification of the protocol itself so far.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.