Nostr Ecosystem Development Status and Problems

Last week, CKB community member Retric proposed the Nostr Binding Protocol.

The Nostr Binding Protocol is used to create a one-to-one mapping relationship between Nostr Event and CKB Cell. Ordinary users can create and distribute native assets in the Nostr social network based on this protocol. Through RGB++, these assets on Nostr can also be controlled by Bitcoin addresses. Client developers can build products on it. Unlike ETH dApp, which is divided into two systems (one is the off-chain server and the other is the on-chain smart contract), the Nostr Binding Protocol brings a new development paradigm for dApp, which uses a consistent system with different data levels to build dApp. It is reported that the Nostr Binding Protocol can be seamlessly integrated into the CKB Lightning Network in the future to solve the problem of native payment in social networks.

Nostr is a minimalist information transmission protocol based on public and private keys, dedicated to creating a censorship-resistant global social network. Nostr uses Relay to store social data (such as posts) and transmit it to users. The software run by users is called Client.

On March 9 this year, at the first Bitcoin Singapore conference co-organized by Nervos Foundation and ABCDE, Retric gave a keynote speech on "Nostr Ecosystem Development Status and Problems"?

The following is a summary of Retric's sharing, which can help everyone better understand the  Nostr protocol:

This Nostr protocol should be the simplest thing in today's conference. Compared to some technologies or protocols that others have talked about, it is the easiest to understand because it is also very simple. Nostr originally wanted to make a "Twitter", but this Twitter is not controlled by Elon Musk, but a more decentralized Twitter. It will not do bad things, will not block others, and has some freedom of speech. It wants to do this for a more realistic starting point, that is, to make such a software, and for this purpose proposed a decentralized protocol on social networks, called Nostr. Then, as it has developed to the present, everyone has begun to realize that these things can not only make a Twitter, but more like a better Internet structure, on which we can make various applications.

I will first briefly introduce the Nostr protocol, which can actually be described in one sentence: This is a piece of data, signed by a private key, and this data is transmitted on different relays or repeaters, and then sent to the client. Essentially, I sign a fixed format of data, send it to some repeaters after signing, and then I let other users pull down the data from these repeaters through the client for reading.

The core of Nostr is a Jason structure, which has different fields, and each field represents a meaning. For example, pubkey is which public key I use to sign the data I send. For example, it has a content column, which represents what the content of the data I sign is. It can be any string, it can be a tweet I sent, or it can be a number or an encrypted thing. There is no restriction in the protocol. There will also be a signature here, which means that I have made a guarantee for the data I sent, to ensure that the data was indeed sent from me.

So the core of Nostr is so simple. It actually just means that I use a private key locally to sign a piece of data I wrote myself. After this data is sent to the Internet, the Nostr network structure is also very simple, with two structures, one called Relay and the other called Client.

Relay is a server that everyone can set up. The function of this Relay is that it keeps running on the Internet to monitor who has sent me the data I just mentioned, and then receives it and saves it. If a client asks me for some data, I will give it to him.

The second part is how to spread this data, that is, a specification for dissemination, which actually contains a lot of details. For example, if I send this data to Relay, can Relay communicate with Relay? Or after I send it to Relay, will Relay help me save this data completely, and then give it to me whenever I ask for it? In fact, there are such details. Nostr's answer is "I don't care, you think about it yourself." It's actually a bit strange to not care, but sometimes I think it's a smarter strategy. Sometimes it seems that not caring about things in the real world or on the Internet, sometimes it hurts things because of too much care, so I think it's actually very interesting. For example, let me give a simple example. When we use traditional centralized social networks, the centralized server will save all your data by default. Then when you ask me for it, I can give it to you at any time, but because Nostr doesn't care, what will happen here? Some Relay operators want to become bigger and stronger, and they want to save all messages. This is one type. Another type is that I am a hobbyist, I just want to build a very small node, and I only accept data from those users I like. There are also some cases where I am willing to accept your data, but I may not want it after 30 minutes, and I want to delete it, because the disk on my server may be limited, and I don’t want to save it for that long.

So it will actually evolve into many different roles, and these different roles may have different divisions of labor. For example, if some really want to run it as a business, then I will be a professional service node, and try to provide you with relatively stable and long-term services. There are also some enthusiasts who can run things like LANs, so it will evolve into different divisions of labor.

A common phenomenon is that most Relay nodes are willing to receive some of your messages, but they cannot guarantee that they will be saved for a long time. This structure actually seems to be more suitable for some social models in our real human society. Real social models, for example, I am chatting with you here today, as soon as I speak, you can hear me, you also know, and then leave the venue. After two days, some people with poor memory will not remember what I said, but some people will buy a recorder at the conference and write down every word you said. This means that your message will be preserved forever. This is actually very similar to what is happening in our reality. This can happen because Nostr does not make regulations on many details or many other things, and does not care, including whether Relays need to communicate with each other, whether they need to synchronize the messages they have with each other. It does not stipulate the need, but it does not say that you cannot. Therefore, many Relays will pretend to be a Client, and they will also ask other Relays for their data and synchronize all the data. However, it does not make mandatory requirements, saying that you must communicate. One of its reasons is that if I make this requirement, you must communicate, then each Relay must save the data of every user in the entire network, which will be a very big test for operating Relays. Maybe only those professional service providers can operate it, and individual enthusiasts may not run it. So these are some of the considerations behind it making this simple protocol.

To sum up, I think the Nostr protocol is very simple. Another interesting thing about it is that at this point in time, after we have Bitcoin and blockchain, we want to reach a consensus, just like we all sit down and say that today we use a unified format and a unified protocol to make some social networks or Internet products. It actually appears at a very interesting point. But now I think there is such a direction that we want to work hard on at this point, which is to use a very simple data structure and a very simple exchange protocol to do what WeChat, Twitter, etc. are doing. So I think it may seem very simple and meaningless when you take a look at the protocol. But if you think about the time and meaning behind it, you will find it more interesting.

Another point is that because of its structure, a lot of verification actually occurs on the client. There is actually only one thing to verify, whether the data you publish is really issued by the public and private key pair you declared, and only this verification is done. Why do we need to do this verification? For example, if I send a tweet and say something I shouldn't say, this tweet will be sent to Relay. Relay is responsible for sending it to others. If Relay doesn't do verification, Relay can say that I forged a weird thing you said and sent it to other users. Because I signed the data when I sent it, the client that gets the data can do a verification and say that the signature he signed is exactly the same as what he said, so Relay can't deceive others.

So one of its verifications is to do the signature verification. This signature verification is actually the centralized Internet in the past, such as WeChat. The server on WeChat is controlled by itself. It can write anything on the server. You have no way to determine whether it has deceived you, because all the data and all the rights are on the server. But as long as there is a simple verification, we can actually strip the rights from the server and give them to the user who owns the account.As long as you have a public and private key, you can ask your friends to verify and make sure that no one else is trying to impersonate me or say something wrong.

How is Nostr developing? Here are some data I found in March. Because it is a distributed network, its data is not easy to count. This is the data I got from the nostr.band website. Nostr may have a total of 370,000 users, and the daily active users may be 12,000. The total number of Relays that have appeared, how many people have run this node, may be 2,000+. But how many nodes are actually online all the time? It may be less than 200. This is roughly the situation, so there are still relatively few users.

For comparison, you can see a comparison between it and the BlueSky protocol. Bluesky said that they had reached 2 million users at the end of last year. The data on the right is where those users who left Twitter went. You can also see that Mastodon is ranked first. Mastodon is a relatively old protocol. Then some people went to ost news and some went to BlueSky. Nostr actually belongs to the fifth echelon, which is a relatively small part.

This is a general development of it. Of course, there are many things behind Nostr that cannot be seen in this data, such as some proposals submitted to the protocol, and developers submitted some PRs to it. These development activities or some discussions may not be counted in these data, but if you click on these links, you can actually see that there are still many things happening, and a large number of people want to contribute to this protocol. This is what everyone has done with Nostr. It's not just me making a Twitter app, there are also many music apps, YouTube apps, and blog apps.

So to summarize, we think that most of the users are actually developers or makers. They are interested in the protocol itself and want to develop things on it, or I am a person who wants to do something, I will use your protocol, and there may be fewer ordinary users.

Why is Nostr so simple, the vision looks good, but the development is not very satisfactory? I think it is because of three problems. When I was writing this PPT, I found that there were actually many small problems with details, such as the client and some things in the product experience. But this kind of thing is actually difficult to explain clearly, so I cited three points that I think are more important.

The first big problem is how do you find where a user's content is in the Nostr network? Because we said earlier that the operation of the entire Nostr protocol is that I sign something locally and then send it to countless Relays. Other users can grab the data I sent from these Relays to read it. This is a model. But there is a problem with this model. After I send this data to the Relay, when my friend wants to read this message, how does he know which Relay my message is placed on? He has to know which Relay has my data before he can read it. So now a big user experience problem is that many people will ask their friends when using Nostr: "Hey, which Relays are you using? I want to set up the same Relay as you so that we can exchange this data together." This is a very stupid method.

Of course, many developers have proposed some detailed solutions. For example, there is a proposal for NIP-65, which roughly means that I will put my data on which Relays and I will also put this information on the Relay. Then I will spread this information to all Relays as much as possible. In this way, my friend will first go to the Relay to ask a question, where does my friend usually post his messages. After getting this information, he will go to the Relays where I often post and ask them for this data. This is one method.

It is divided into two more detailed modes, one is called Inbox and the other is called Outbox. For example, like Inbox, it allows users to define which Relays I will read some messages about me from. If you want to @ me on Twitter or want to do other things, you can post this message in this Inbox Relay. Another one is Outbox Relay, which indicates that I will send some of my messages to several Relays A, B, C, and D. It roughly means that I will first send some of the Relay information that I often publish on Relay.

However, this has a technical problem, that is, how do I know where this message is. So this actually also has this problem. There are some solutions that say that I use some algorithms to download as much information as possible from the entire network. Then, from some evidence hidden in some messages sent by other people, try to calculate the probability that a person's published data appears on which Relays. Through this probability calculation, try to find some Relays to get data, so that others can find your data when they want to read your data. There are also some that allow users to define some Relays that they will use, make some groups, and let other users find you through these groups. These are some existing improvement solutions.

The second problem is also more serious, called Content Governance. Whether it is content products or social networks, a large part of the energy needs to be put into how to maintain the content on the social network. For example, you definitely don't need to see a video of someone beheading when you are browsing Twitter, right? This is a very bad experience. These companies will do a lot of operations behind the scenes. It needs a lot of people to filter these contents, or use algorithms to match some content. In this part, the market is relatively blank. There are several reasons for this. One reason is that people are very resistant to algorithms on this platform. Because it seems that whether it is TikTok or Youtube, algorithms are controlling us, but in fact we do need algorithms, but what we need is that I can switch algorithms.

I don't want to say that I can only accept the mandatory algorithms that Youtube or TikTok gives me to push advertisements. I hope that I have many algorithms that I can switch at any time. If I don't like this algorithm, there is an option for me to quit. This view and its design are also slowly being accepted. It's just that at present, whether it is manual or some operations on content, or some things done in algorithm technology, these are still relatively lacking. So the main problem in this part is that our network is made up of everyone. It needs a mechanism to decide which content is good, which content is bad, which content you are interested in, and which content you may not be interested in. This is actually a problem of content governance.

Here are some existing improvement plans that I have listed below, such as the first labeling data. There is a special data on Nostr that allows users to mark what type of data it belongs to, or what its attributes are. This labeling is used to label a piece of data, but this application is not widespread because it is very simple and no one is willing to do this. No one is willing to act as your social member to help you do some of this hard work. The early Internet society had this spirit of construction. Now, in fact, everyone is more likely to use it as a consumer. Of course, some people have also proposed that I can do API. I run some services specifically, I collect data from some companies on the entire network, and then I filter or classify it to get some more likely good news to send to users. This solution is very easy to do, but it has a huge problem, that is, we go back to doing it. It will become that I don't ask for data from the Nostr protocol, but I will specifically look for an API that works particularly well, and ask for data from the server of this API. Then the protocol will become another Twitter or another WeChat behind this API, so this solution is very good. The problem is that everyone doesn't like it. If you do this, everyone will criticize you.

There is another solution called DVM, which wants to use the Nostr protocol to do some data classification or algorithm using the interface specified by the protocol. It roughly means that you give me some lightning network satoshis, and then I will return you the data you want, and you specify the data format, but this also has some problems.

Another is Noscript, which is another idea. We directly put these filtering algorithms or some technologies needed for classification as content on Nostr and let Relay store them. Then the client directly pulls these codes down and does some local filtering or recommendations locally. Of course, this will not develop well, because there are only some ideas and some people are discussing it.

The third more serious problem is actually a startup problem, PMF. Now a large number of Nostr products or developers cannot find PMF, because they need to face a lot of competition. On the one hand, there are those centralized traditional products, and on the other hand, there may be those from the Web3 blockchain. They don't issue tokens or do anything, so it actually lacks some business models and also faces the problem of network effect, because the fewer people migrate here, it means that fewer people will continue to migrate here. So PMF is a big problem.

Nostr's largest client is called Damus. I don't know if you have used it. Its developer sent a tweet at the end of last year, saying that 2024 may be the last year of Damus. Because he is running out of money to continue, if he still can't do it in 2024 and still can't make money. So this is also a problem of finding a direction for sustainable development of public goods in social networks.

In fact, I think all the problems here are also opportunities. For example, as for the last PMF, I think if we can have more places that are combined with blockchain and have more feasible business models, and combine them with blockchain funds, we may be able to solve the financing problem of this kind of public goods.

Finally, I think Nostr is a new solution for developing alternative applications. If you want to make some alternative products, there may not be only two extremes, one extreme is called blockchain, and the other extreme is called Twitter. It is not just this kind. There may be a middle ground called Nostr, which is not based on blockchain, but it is not a proprietary software either. Thank you.