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 to dApp. It 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 relays to store social data (such as posts) and transmit it to users. The software run by users is called a client.
On March 9th of this year, at the first Bitcoin Singapore conference co-organized by Nervos Foundation and ABCDE, Retric gave a keynote speech on "The Current Status and Problems of Nostr Ecosystem Development" 👇
The following is a summary of Retric’s sharing, which can help you better understand the Nostr protocol:
The Nostr protocol should be the simplest thing in today's conference. Compared with some technologies or protocols that others have talked about, it is the easiest to understand because it is also very simple. At the beginning, Nostr actually 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, it wants to make such a software, and for this purpose, it proposed a decentralized protocol on the social network, called Nostr. Then, as it has developed to the present, everyone has begun to realize that these things are not just for making a Twitter, but more like a better Internet structure, on which we can make various applications.
I will first briefly introduce the Nostr protocol. It can actually be described in one sentence: This is a piece of data, signed by a private key, which is propagated on different relays or repeaters and then sent to the client. In essence, I sign a piece of data in a fixed format, send it to some repeaters after signing, and then let other users pull the data from these repeaters through the client for reading.
The core of Nostr is a Jason structure, which has different fields, each representing a meaning. For example, pubkey is the public key that I use to sign the data I send. For example, it has a content column, which represents the content of the data I sign. It can be any string, a tweet I sent, 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. After this data is sent to the Internet, the Nostr network structure is also very simple, with only two structures, one called Relay and the other called Client.
Relay is a server that anyone can set up. The function of this relay is to keep running on the Internet, listening to who has sent me the data I just mentioned, and then receiving and storing it. If a client asks me for some data, I will give it to him.
The second part is how to spread the data, that is, a specification for the spread. There are actually a lot of details in this. For example, if I pass the data to Relay, can Relay communicate with each other? Or after I pass it to Relay, will Relay help me save the 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 in the real world or on the Internet, sometimes it hurts something because of too much care, so I think it's actually very interesting.
For example, let me give you 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. There is also a kind of hobbyist who just wants to build a very small node and only accept data from those users I like. There are also some who are willing to accept your data, but I may not want it after 30 minutes after receiving it, and I want to delete you 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 people really want to run it as a business, then I will be a professional service node, and try to provide everyone with relatively stable and long-term services. There are also some enthusiasts who can run things like LAN, 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 modes in our real human society. In real social modes, for example, I am chatting with you here today. When I speak, you can hear me, you know what I am saying, and then leave the venue. After two days, some people have poor memory and can no longer remember what I said, but some people buy a recorder at this venue and write down every word you say. This means that your message will be kept forever.
This is actually very similar to what is happening in reality. This can happen because Nostr does not regulate many details or many other things, including whether Relays need to communicate with each other, whether they need to synchronize messages with each other. It does not regulate 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 you may find it very simple and meaningless when you look at the protocol. But if you think about the time behind it and the meaning of its appearance, it will be more interesting.
Another point is that because of its structure, a lot of verification actually happens on the client side. There is actually only one thing to verify here: whether the data you publish is really issued by the public-private key pair you declared. This is the only verification. Why do we need to do this verification? For example, if I send a tweet saying something I shouldn’t say, this tweet will be sent to Relay. Relay is responsible for sending it to others. If Relay doesn’t verify it, 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 indeed a perfect match with what he said, so Relay can’t deceive others.
So one of its verifications is to verify the signature. 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 data and all 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 impersonating me or saying something wrong.
So 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 and how many people have run this node may be more than 2,000. But how many nodes are actually online? It may be less than 200. This is probably the case, so there are still relatively few users.
For comparison, you can see a comparison between it and the BlueSky protocol. BlueSky said at the end of last year that they had reached 2 million users. 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 rough picture of its development. 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 submitting 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. These are some of the things that everyone uses Nostr to do. It’s not just that I really make a Twitter, but also many music applications, YouTube-type applications, and blog applications.
So to summarize, we think that most of the users are 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 make something, so I will work on your protocol. There may be fewer ordinary users.
Why is Nostr so simple, and 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 details, such as the client and some things about the product experience. But it is actually difficult to explain this kind of thing clearly, so I cited three points that I think are more important.
The first big problem is how to find the content sent by a certain user in the Nostr network, because as we said before, the operation of the entire Nostr protocol is that I sign something locally, and then I can send it to countless Relays. Other users can grab the data I sent from these Relays to read it, such a model. But there is a problem with this model, that is, 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 called NIP-65, which roughly means that I will put my data on the relays. Then I will spread this information to all relays as much as possible. In this way, my friend will first ask the relay where my friend usually posts 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, Inbox 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 send this message to this Inbox Relay. The other is Outbox Relay, which specifies 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 messages I often publish on Relay.
But this raises a technical problem, which is how do I know where the message is. So this problem actually exists, and there are some solutions that use some algorithms to download as much information as possible from the entire network. Then, from some evidence hidden in the Relays mentioned in some messages sent by other people, try to calculate the probability that a person's published data will appear on which Relays. Through this probability calculation, try to find some Relays to get data, and then satisfy others to find your data when they want to read your data. There are also some solutions 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 quite serious, called Content Governance. Whether it is content products or social networks, a large part of the energy needs to be put into how you maintain the content on the social network. For example, you certainly don’t need to see a video of someone being beheaded when you are browsing Twitter, right? This is a very bad experience. These companies will do a lot of operations behind the scenes, and they need a lot of people to filter these contents, or use algorithms to do some content matching. In this part, the market is relatively blank. There are several reasons for this. One reason is that everyone is very resistant to algorithms on this platform. Because it seems that whether it is TikTok or Youtube, algorithms are used to control 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 algorithm of Youtube or TikTok to push ads. I hope that I have many algorithms and can switch at any time. If I don’t like this algorithm, I have the option to quit. This view and its design are also slowly being accepted. It’s just that now, whether it’s 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 composed of all people, and it needs a mechanism to decide which content is good, which content is bad, which content you will be 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 I have listed, such as the first labeling data. There is a special data on Nostr that allows users to label certain data by themselves, such as what type 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 hard work. The early Internet society had this spirit of construction. Now, in fact, people are more likely to use it as consumers. Of course, some people have also proposed that I can make APIs. I run some services specifically, collect data from some companies on the entire network, and then I filter or classify them to get more likely to send good news to users. This solution is very easy to do, but it has a huge problem, that is, we go back to doing it this way. It will become that I don’t ask for data from the Nostr protocol, but I specifically look for an API that works particularly well and ask for data from the server of this API. Then the protocol becomes this API, and then there is another Twitter or another WeChat, so this solution is very good. The problem is that no one likes 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 interfaces specified in the protocol. It roughly means that you give me some Lightning Network Satoshis, and then I will return the data you want to you, and you specify the data format, but this also has some problems.
Another one is Noscript. It is another idea. We put the filtering algorithms or some technologies needed for classification directly as content on Nostr and let Relay store them. Then the client will directly pull down these codes and do some filtering or recommendations locally. Of course, this will develop even worse, because now there are only some ideas and some people are discussing.
The third more serious problem is actually a startup problem, PMF. Now a lot of Nostr's 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 Web3 blockchain. They don't issue tokens or do anything, so they actually lack some business models and also face the problem of network effect, because the fewer people migrate here, the fewer people will continue to migrate here. So PMF is a big problem.
The largest client of Nostr 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 might be the last year of Damus. Because he is running out of money to continue, if he still can’t make money by 2024. So this is also a question of finding a direction for the sustainable development of public goods in social networks.
In fact, I think all the problems here are also opportunities. For example, as for the PMF, I think if we can combine more with blockchain and have more feasible business models, and combine 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. There is not only this, there may be a middle ground called Nostr, which is not based on blockchain, but it is not a proprietary software either. Thank you.
