The New Year Of Social Media: Nostr Principles And Key Management Issues

New social media designs under the Fifth Right have been explored for years, with no sign of mass adoption. In the past year, with the continuous development of encryption technology and concerns about Musk’s acquisition of Twitter, the decentralized social network has ushered in new opportunities.

The problems these social networks are trying to solve: could include strengthening censorship, making content moderation more flexible and reducing the power of big social media companies to shape and track what people talk about online, among other things.

As new platforms emerge and grow, the choice of alternative social networks often comes with political considerations. Sites like Getr, Parler, Gab, and Truth Social all cater to the right by promoting themselves as free speech alternatives to Twitter.

What we are going to discuss today is Nostr-Damus, a new social media protocol that has received a lot of attention recently and is somewhat innovative. These include Nostr’s technical principles, key management issues to be resolved, and how to incentivize the relay to continue to operate.

Overview of Nostr

Launched in 2020, Nostr is a decentralized protocol that allows users to own their identities and verify posts using digital signatures using public-private key encryption. These posts are then propagated to an interconnected network of servers. The protocol does not use a blockchain, which was found in early experiments to be too slow for social networks. But there are structural similarities, and Nostr found an early niche in the crypto crowd with its libertarian and open-source ethos.

Mastodon vs. Nostr

The Nostr protocol and the first relay server were created by developer fiatjaf in late 2020. Before gaining widespread attention, Nostr was a quiet niche protocol aiming to be a lightweight solution to the problems of Twitter and Mastodon.

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 blurred line of “Web3,” depending on how that is defined. Mastodon allows users to join curated communities with custom content moderation rules. At present, the number of registered users has reached 200w+, and it has become a safe haven for liberals, journalists, and scholars.

In Twitter and Mastodon systems, identities/usernames are controlled by whoever runs the server.

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

Event: This is the basic object/data type used by clients and the relay servers they connect to in order to send and retrieve 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 they have received and stored. In the original NIP 01, three different event types were defined:

• Send metadata about the user, such as username, picture, bio, etc.
• Send SMS and basic content
• Recommend the relay server for people who follow the event creator to connect

All events are structured in a specifically defined way. Includes the creator’s public key, creation timestamp, type (or kind in spec), content payload, and event creator’s signature. Alternatively, there can be 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 a Bitcoin transaction’s TXID).

This lets users verify the signature (and who owns the key, if it hasn’t been compromised) to guarantee that the message was indeed created by the owner of the public key in it and that the message hasn’t been altered since they signed it.

Just as a Bitcoin transaction cannot be changed after it has been signed without invalidating it, a user cannot change it after the creator of the Nostr event has signed it without making it an obvious fraud.

The event-type system has been expanded considerably from the original NIP. There is an event type for direct encrypted messages that build a shared secret by combining the sender’s private key with the receiver’s public key, the result of which is the same as what you get by combining the sender’s public key with the receiver’s private key the keys are the same (this is how BIP 47 and silent payments work).

There are also replaceable event and ephemeral event types. 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 following this specification will automatically delete old events from their storage and start serving newer versions to clients upon receipt.

Ephemeral events are designed in such a way that when sent to a relay, they will be broadcast to anyone subscribing to their creator, but the relay server should not store them. This creates the possibility that only those who are online will see the message during its broadcast. There’s even an event type for representing reactions to other people’s events (such as likes or emojis).

Speaking of the last question, events can also contain tags. Currently, there are tag types for the Event (referring to an exact Nostr event), PublicKey (to tag or refer to another user), and Subject (to mimic functionality, like an email subject).

All of these can include pointers to specific relay servers from which data is fetched so that users can actually interact on different servers, i.e., a user publishes their content on a relay server content that can be interacted with and referenced by another user on a different relay server so that any user can coherently get the entire thread of interaction in the proper order without having to find out where the relevant data is a large number of complex operations.

In the original NIP, a specification was given of how a client interacts with a relay server by subscribing to a message/data structure that includes filters for which events the client is interested in receiving. These filters can specify the user’s public key, the exact event, the type of event, or even a specific timeframe they want to be based on previous criteria.

Users can even submit public keys or prefixes of event IDs, such as “1xjisj…” and receive any one or more events from a public key starting with that short string (this is useful for hiding from relay servers what you actually want to see).

Overall, the protocol is a very simple general scheme for passing messages between users, covering important things such as guaranteeing the integrity of messages and using public key identities for sending messages while also facilitating end infrastructure relay servers can be highly centralized or allow users to run their own personal relay servers while seamlessly interacting with each other and without causing massive chaos in the event users are banned from using one relay server.

They can move to another server or run their own, and they won’t lose their digital identities or followers by breaking off the platform from their previous server, as they still maintain control of their private keys, and users can use it elsewhere to authenticate them when they find them.

Relay servers can also run whatever they want: free to operate, charge a small fee to publish or download messages, and even have a NIP that requires hash cash-style proof-of-work to submit messages.

They can be a single relay server that hosts posts and makes them available only to other users or a server that operates at scale, such as Twitter or Reddit (clients can display and organize information as desired, which allows simulating any social media). All of these interoperate seamlessly without locking users out.

Key management issues to be addressed by Nostr

User public/private keys are an integral part of how Nostr works as a protocol. This acts as a tight tie between the actual user and how others identify them, preventing any relay server from untying those two things, i.e., giving someone’s identifier to another user. It also solves one of the biggest problems with the platform: the lack of control over the user’s own identity.

But this also introduces new problems: the key can be lost, the key can be compromised, and if such an event occurs, the user will not be able to call for help.

This will inevitably require a scheme for users to switch from one key pair to another in a verifiable and discoverable way and for them to interact with other users through the protocol. The whole protocol is based on proving that an event came from a specific user (identity key), so once someone’s key is compromised, all those guarantees are thrown into the air.

Nostr requires an actual cryptographic scheme that ties the rotation of one key to another. Developer fiatjaf has proposed a basic solution that might solve this problem. The basic idea is to take a long list of addresses derived from a single master seed and create a set of “adjusted” keys, similar to how Taproot trees are committed to Bitcoin keys.

Taproot takes the Merkle root of the Taproot tree and “adds” it to the public key to create a new public key. This can be replicated by adding that Merkle root to the private key to obtain a private key that matches the new public key. Fiatjaf’s idea is to chain commitments backward from end to beginning so that each adjusted key actually contains proof that the next adjusted key was used to create it.

So, imagine starting with key Z, the last in the chain. You can tweak it with something, then go back and create an adjusted version of key Y using the adjusted key Z (Z’ + Y = Y’). From here, you can take Y’ and use it to adjust X (Y’ + X = X’). You’d do this all the way back to key A, get A’, and use that key from there. When it is broken, the user can broadcast an event containing the unadjusted key A and the adjusted key B’.

This will contain all the data needed to show that B’ was used to generate A,’ and the user can immediately stop following A’ and follow B’ instead. They would know unambiguously that B’ is the next key for that user and follow that key instead.

However, there are still some problems with this proposal. First, all keys that will be used must be generated ahead of time, and there is no way to rotate to an entirely new set of keys. This can be solved by committing a master key in this scheme that can notarize this rotation or by simply generating a very large set of keys from the start.

Either path is feasible but ultimately requires keeping the root key or keying material secure and only exposing individual hotkeys (Hotkeys) to Nostr clients.

However, this scheme does not protect users or provide mechanisms for identity recovery in the event that root-keying material is lost or compromised.

For some discussion of potential solutions here, another way to think about it is to adjust a key to a master cold key which must also be used to sign events from one key to another rotation. You have key A’, which is derived by adding A and M (master key); the rotation event will be A, M, and B’ (generated by adding B and M) and M’s signature. M can be a multi-signature threshold key – two-thirds, three-fifths, etc.

This may add redundancy against loss and provide a secure mechanism for key rotation. This also opens the door to using services to help with recovery or to spread some of these keys to trusted friends. It offers the same flexibility as multisig in Bitcoin itself.

NIP26 is also a proposal that might be very useful in dealing with this problem. This specifies a protocol extension for events that allows a signature from one key to authorize another key to publish events on its behalf. The “token” or delegated proof of signature will then be included in all events published by the second public key on behalf of the first. It can even be time-limited, so delegation tokens automatically expire and must be renewed.

The question of key management and security is a very large problem with a very large design space full of trade-offs and pain points. However, if Nostr cannot protect and maintain the integrity of these identities for users, a protocol based entirely on public/private key pairs used as identities will not be adopted on a large scale.

Expansion facing Nostr

The whole Nostr protocol relies on someone somewhere running a relay server. There is no “Nostr network”, just relays and clients connected to the relays. People need to be incentivized to run relayers, and this will ultimately be a big part of how far relayers can scale in the long run. Unless a Nostr relay can be profitable or at least bring in enough money to cover its own operating costs, there will never be a relay of the same size as the Twitter server.

Advertise

Given the way Nostr works as a protocol, blocking ads entirely would be trivial, making it an unfeasible solution. Relay servers can try to use advertising as a revenue model, which is apparently the main revenue model for nearly every free service online, but the problem is that users basically have to opt in. Relays can easily inject advertisements into the events they send to clients, but clients can also easily filter advertisement events from their UI if they were not created by the public key they intended to subscribe to.

Micropayment

Micropayments are another obvious solution, especially given the ongoing attempts to integrate the Lightning Network more tightly into the Nostr app. This model offers a lot of flexibility in how you charge. Relays can charge only for posting events there, for downloading event reading, or a combination of the two, adjusting the price of each based on how many resources they consume. However, it is doubtful that this model can be scaled up to the scale of Twitter.

Content micropayments have shown their viability in many niche products based on the Lightning Network, but there are two fundamental problems with truly scaling to a global scale.

First, there isn’t enough Bitcoin adoption yet. Even if everyone magically accepted to pay for every small service interaction on Nostr, there wouldn’t be enough people holding bitcoins to support something as massive as Twitter. Relays can charge subscription fees in fiat currency, but these payment methods will not support paying a small fee for each event published or downloaded.

Second, people are actually used to this kind of free service. This is exactly what one would expect. I don’t think micropayments can really support large-scale relaying.

There is a way to make micropayments “stickier” or more sustainable without forcing them on every class of users who use the relay. There has been a lot of talk about building various applications on top of Nostr, except for the Twitter clone. GitHub, Wikipedia, and even Uber.

The last one is key: economic expectations. People are very used to paying a fee when a job is advertised somewhere or paying a marketplace operator a fee when they order something online but don’t serve things that they think should be free – Google, Twitter. This could provide a way for relayers to create a solid income pillar from their users without creating a lot of friction or breaking the expectations of the average potential user.

If micropayments are also going to be a factor, relay operators will have to run a Lightning node in order to receive funds from users first. This could potentially increase revenue if properly synergized with any micropayment model implemented by the relay.

The more revenue a relay server earns, the more liquidity it needs on the Lightning Network to facilitate this. If operators plan correctly how they deploy or distribute liquidity in the network, the mere act of running a routing node could become a significant revenue generator in itself, on top of any fees charged for receiving or transmitting data through relays.

Conclusion

Web3 social projects, in addition to the aforementioned Nostr and Mastodon, also include projects such as Farcaster and Lens, which will not quickly replace existing social media platforms. According to statistics, Twitter has hundreds of millions of active users, 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 hurdles that slow down mass adoption.

Media and politics are inseparable. As Web3 social projects proliferate and the public conversation fragments across different applications and protocols, there may be political outcomes. Even Messina, who has long advocated for decentralized social media, fears that decentralization will further fuel a public discourse that has been marked by mutual hostility and misunderstanding in recent years.

DISCLAIMER: The Information on this website is provided as general market commentary and does not constitute investment advice. We encourage you to do your own research before investing.

Join us to keep track of news: https://linktr.ee/coincu

Harold

Coincu News