Partnered With:

The New Year of Social Media: Nostr Principles and Key Management Issues.

Read this article in 24 Minutes

The technical principles of Nostr, key management issues to be addressed, and how to incentivize relays to continue operating.

Original Title: "DAOrayaki | The New Social Media Year: Nostr Principle and Key Management Issues"

Original Author: DAOctor @DAOrayaki

The new social media design under the Fifth Estate has been explored for years, but there is no sign of widespread adoption. In the past year, with the continuous development of encryption technology and concerns about Musk's acquisition of Twitter, decentralized social networks have ushered in new opportunities.

These social networks attempt to address issues such as strengthening the censorship system, making content review more flexible, and weakening the power of large social media companies to shape and track online discussions.

With the emergence and growth of new platforms, the choice of alternative social networks often carries political considerations.

Sites like Getr, Parler, Gab, and Truth Social cater to the right-wing by promoting themselves as alternatives to Twitter for free speech.

We are going to discuss today about a recently popular and innovative new social media protocol called Nostr-Damus. This includes the technical principles of Nostr, key management issues to be solved, and how to incentivize relays to continue running.

1 Background: Nostr

Nostr was launched in 2020 as a decentralized protocol that allows users to have their own identity and verify posts using public-private key encrypted digital signatures. These posts are then propagated to an interconnected server network. The protocol does not use blockchain as it was found to be too slow for social networks in early experiments. However, there are similarities in structure, and Nostr has found an early niche market among the crypto community with its liberal and open-source spirit.

2 Mastodon VS Nostr

Nostr protocol and the first relay server were created by developer fiatjaf at the end of 2020. Before gaining widespread attention, Nostr was just a quiet niche protocol dedicated to being a lightweight solution for Twitter and Mastodon issues.

Mastodon, an open-source network founded in 2016, allows anyone to set up a server. The design is often described as "federated" and may or may not fall within the vague boundaries of "Web3," depending on how it is defined. Mastodon allows users to join curated communities with custom content moderation rules. Currently, there are over 2 million registered users, making it a haven for liberals, journalists, and scholars.

In the Twitter and Mastodon systems, the identity/username is controlled by the person running the server.

The core difference of Nostr is that each user uses a public key/private key pair to process the function, instead of using the username owned by the server operator, making Nostr resistant to censorship. This is one of the core building blocks for building the entire Nostr protocol.

"Event": This is the basic object/data type used by the relay server that connects clients for sending and retrieving messages. The overall idea of this protocol is that clients send events to the relay server, which then stores and indexes them. Other clients can communicate with the relay server to request events that they have received and stored. In the initial NIP 01, three different types of events were defined.

0: Send metadata about the user, such as username, profile picture, bio, etc.

1: Sending text messages and basic content.

2: Recommended relay servers for people who create events to connect to.

All events are constructed in a specific defined way. This includes the creator's public key, creation timestamp, type (or category in the specification), content payload, and the event creator's signature. Additionally, there can be tags referencing other events or users, and there is an ID value which is the hash of all content except for the creator's signature (similar to the TXID of a Bitcoin transaction).

This allows users to verify that the information was indeed created by the owner of the public key (and anyone who possesses the key, if it has not been compromised), and to ensure that the information has not been modified after it was signed by them.

Just as one cannot change a Bitcoin transaction after it has been signed without rendering it invalid, users also cannot change a Nostr event after its creator has signed it without making it an obvious fraud.

The event type system has been greatly expanded from its initial NIP. There is an event type used for directly encrypted information, which establishes a shared key by combining the sender's private key and the receiver's public key, resulting in the same key you would get by combining the sender's public key and the receiver's private key (this is how BIP 47 and silent payments work). There are also types for replaceable events and transient events. In the case of replaceable events (obviously), they are designed so that the original creator of the event can sign a new event to replace the old one. Relay servers that follow this specification will automatically remove the old event from their storage and begin providing clients with the newer version upon receipt. The design of transient events is such that when they are sent to a relay station, they will be broadcast to anyone subscribing to their creator, but the relay server should not store them. This creates the possibility that only online people can see the message during its broadcast. There is even an event type used to represent reactions to other people's events (such as likes or emojis).

Speaking of the last question, events can also include tags. Currently, there are tag types for events (referencing a specific Nostr event), public keys (marking or referencing other users), and subjects (imitating functionality such as email subjects). All of these can include pointers to specific relay servers where data can be retrieved, allowing users to interact on different servers in a seamless manner. This means that a user can publish their content on one relay server and interact and reference content published by another user on a different relay server, allowing any user to smoothly follow the entire interaction thread in the appropriate order without having to perform complex operations to find relevant data.

In the original NIP, specifications were given on how clients can interact with relay servers through subscribing to messages/data structures, which includes filters on which events the client is interested in receiving. These filters can be specified based on the user's public key, exact event, event type, and even a specific time range as specified by previous standards. Users can even submit a prefix of a public key or event ID, such as "1xjisj...", and receive any one or more events from public keys that start with that short string (which is useful for hiding the actual content that the user wants to view from the relay server).

Overall, the protocol is a very simple and universal solution for messaging between users, covering important things such as ensuring message integrity and identifying the sender using public key identities. It also facilitates backend infrastructure where relay servers can be highly centralized or allow users to run their own personal relay servers, seamlessly interacting with each other and avoiding massive disruptions in case a user is banned from using a relay server. They can move to another server or run their own server, and they do not lose their digital identity or followers from the previous server because they still maintain control over their private keys, and users can authenticate their identity when they find them elsewhere.

A relay server can also run as desired: free operation, charging a small fee to publish or download messages, and even requiring a NIP hashcash-style proof of work to submit messages. They can be a single relay server, hosting posts and only providing them to other users, or a large-scale server like Twitter or Reddit (clients can display and organize information as needed, allowing simulation of any social media). All of these can interoperate seamlessly and not exclude users.

3 Nostr Unresolved Key Management Issues

User public/private keys are an indispensable part of the Nostr protocol's operation. They play a role in how actual users are identified and bound tightly with each other, preventing any relay server from breaking this bond by providing someone's identifier to another user. This also solves one of the biggest problems with the platform: the lack of control over a user's own identity.

However, this also introduces new problems: the key may be lost or damaged, and if such events occur, users will be unable to seek help.

This will inevitably require a solution that allows users to transition from one key pair to another in a verifiable and discoverable manner, and enables them to interact with other users through the protocol. The entire protocol is based on proving an event came from a specific user (identity key), so once someone's key is compromised, all of these guarantees are thrown out the window.

Nostr needs a practical password scheme that links the rotation of one key to another. Developer fiatjaf proposed a basic plan that may solve this problem. The basic idea is to use a long string of addresses derived from a single master seed, and create a set of "adjusted" keys, similar to how the Taproot tree submits to Bitcoin keys. Taproot obtains the Merkle tree root of the Taproot tree and "adds" it to the public key to create a new public key. This can be replicated by adding the Merkle tree root to the private key to obtain a private key that matches the new public key. Fiatjaf's idea is to link the commitment from the end to the beginning, so that each adjusted key actually contains the next adjusted key used to create its proof.

So, imagine starting from key Z, the last one in the chain. You can tweak it with something and then go back and use the adjusted key Z (Z' + Y = Y') to create an adjusted version of key Y. From here, you can get Y' and use it to adjust X (Y' + X = X'). You will keep doing this until you get to key A, getting A' and starting to use that key from there. When it is compromised, the user can broadcast an event containing the unadjusted key A and the adjusted key B'. This will include all the data needed to show how B' was used to generate A', and the user can immediately stop using A' and switch to B'. They will know explicitly that B' is their next key and switch to following that key.

However, there are still some issues with this proposal. Firstly, all the keys to be used must be generated in advance and cannot be rotated to a completely new set of keys. This can be resolved by submitting a master key that can certify this rotation in the scheme, or simply by generating a very large set of keys from the beginning. Either path is feasible, but ultimately the root key or key material must be kept secure and only a single hotkey should be made public to the Nostr client.

However, this solution will not protect users or provide mechanisms for identity recovery in the event of loss or damage to root key material.

In order to discuss potential solutions here, let's think about adjusting a key to a master cold key, which must also be used to sign the event rotation from one key to another. You have key A', which is derived by adding A and M (master key), and the rotation event will be A, M, and B' (generated by adding B and M) and the signature of M. M can be a multi-signature threshold key - two-thirds, three-fifths, etc. This may increase redundancy to prevent loss and provide a secure mechanism for key rotation. It also opens the door to using services to help recover or distribute some of these keys to trusted friends. It provides the same flexibility as multi-signature with Bitcoin itself.

NIP26 is also a proposal that may be very useful for addressing this issue. It specifies a protocol extension for events that allows a signature from one key to authorize another key to represent it in publishing events. Then, the signature proof of the "token" or delegation will be included in all events published by the second public key representing the first public key. It can even be time-limited, so delegated tokens will automatically expire and must be updated.

Key management and security issues are a very big problem, with a very large design space, full of trade-offs and pain points. However, Nostrum cannot be widely adopted if it cannot protect and maintain the integrity of these identities for users, based entirely on protocols using public/private key pairs as identities.

4 Nostr Expansion

The entire Nostr protocol relies on someone running a relay server. There is no "Nostr network," only relays and clients connected to those relays. Incentivizing people to run relays will be a crucial part of how far the relay network can ultimately expand in the long term. Unless Nostr relays can be profitable, or at least generate enough funds to cover their operational costs, there will never be relays on the same scale as Twitter servers.

Considering the way Nostr protocol works, completely blocking ads would be insignificant and impractical as a solution. Relay servers can attempt to use ads as a revenue model, which is the primary revenue model for almost all online free services. However, the problem is that users essentially have to opt-in. Relays can easily inject ads into the events they send to clients, but if the ad events are not created by public keys they intentionally subscribed to, clients can also easily filter them out of the user interface.

Small Payments

Micro payments are another obvious solution, especially considering the current attempts to integrate the Lightning Network more closely into Nostr applications. This model provides great flexibility in terms of how to charge. Relays can charge only for events published there, or for events downloaded and read, or a combination of both, and adjust the price of each based on how much resources they consume. However, it is doubtful whether this model can scale to the size of Twitter.

Small-scale payments have demonstrated their feasibility in many niche products based on the Lightning Network, but there are two fundamental problems to be addressed before they can be scaled globally.

First of all, there are not enough bitcoins in circulation to support large-scale bitcoin adoption. Even if everyone magically accepted to pay for every small service interaction on Nostr with bitcoin, there are not enough people holding bitcoins to support large-scale platforms like Twitter. Relays can charge subscription fees in fiat currency, but these payment methods do not support paying a small fee for every event published or downloaded. Secondly, people are already accustomed to these free services. This is what people expect. I don't think relying on small payments can truly support large-scale relays.

There is a way to make small payments "stickier" or more sustainable without imposing them on every type of user using relays. There have been many discussions about building various applications on top of Nostr, except for Twitter clones. GitHub, Wikipedia, and even Uber.

The last one is crucial: economic expectations. People are very accustomed to paying fees when posting job advertisements somewhere or ordering things online from market operators, but they won't pay for services they think should be free - like Google and Twitter. This can provide a way for relays to create a reliable revenue stream from their users without causing a lot of friction or breaking the expectations of potential users in general.

If small payments also become a factor, then relay operators will have to run a lightning node to receive funds from users first. If any small payment model implemented with the relay is properly coordinated, this could increase revenue. The larger the income of the relay server, the greater the liquidity it needs on the lightning network to facilitate this. If operators plan correctly how to deploy or allocate liquidity in the network, then the behavior of simply running a routing node itself may become a significant source of income, in addition to any fees charged for accepting or transmitting data through the relay.

5 Conclusion

Web3 social projects, in addition to Nostr and Mastodon mentioned above, also include projects such as Farcaster and Lens. However, they will not quickly replace existing social media platforms. According to statistics, Twitter has hundreds of millions of active users, and Facebook has billions, but Mastodon has only 2.5 million users and Nostr has only about 220,000 unique user identities. Many Web3 social projects face usability barriers, which will slow down the pace of large-scale adoption.

The media and politics are inseparable. With the surge of Web3 social projects and the division of public discourse across different applications and protocols, political consequences may arise. Even though Mastodon has long advocated for decentralized social media, there are still concerns that decentralization will further exacerbate public discourse marked by mutual hostility and misunderstanding in recent years.