Introduction
Introduction
Today we will discuss a topic that has attracted much attention: Nostr’s Spam (spam) problem. As a decentralized protocol, the Nostr protocol has realized the decentralization, autonomy and anti-censorship characteristics of social media on a global scale. At the same time, this protocol also has some challenges, among which the Spam problem is the most prominent one. Our discussion today will not be limited to the Spam problem, but will also focus on its impact on the future of social media, the progress of decentralized technology and For this reason, the DAOrayaki community is honored to invite Mr. Sherry, a data scientist from the Nostr CN community, to start today’s topic with us from the perspective of a professional researcher: How far is Nostr’s road to “de-Spam”? ?
Guest: Sherry (Data Scientist)
text
text
Q: Before starting the official topic, everyone should be curious about your background. Why are you interested in Nostr? Is it related to the field you are studying or exploring?
In fact, the correlation is not great. At first, about three or four months ago, a friend introduced Nostr to me. He is a Bitcoin Core (Bitcoin Core) developer with many years of experience. Later, he gradually transferred to the development of Nostr. . When I first tried to understand Nostr, I didn't realize how fascinating Nostr was, I only knew it as "another agreement on social media."
In fact, ever since Twitter became popular, people have been proposing that APP (application program) should not be the carrier of social media, but should be turned into a protocol. Some people are constantly trying, but none of them have been widely used. So after two or three months, I decided to Get hands dirty (personal practice) and really participate in the development of some Nostr directions.
Q: After several months of contact, what do you think of the current development of Nostr? We know that the initial "explosion" phase.
In fact, from the perspective of developers, it is not so popular. I think social media such as Twitter and Instagram follow a rule: users enter in wave after wave. Some users feel that this thing is usable, solve their problems, and they will stay, but most people will not stay until the next wave comes.
What we have to do is to prepare between the two waves, build the infrastructure, optimize the user experience, and wait for the next wave of users to arrive. In addition, I track the statistics on Nostr every week. Personally, I feel that people are still joining, but the number of people fluctuates. So far, the number of accounts on Nostr is close to 1 million, although at this stage there are many Spam accounts among them.
I think this number of user groups means that no matter what experiment you want to do, we have a large enough user group to ensure the validity of the scheme verification.
Q: I just mentioned that between each "wave", there will be some problems that need to be solved urgently. At this stage, in the Nostr ecology, besides the Spam problem we will talk about later, what other problems need to be solved urgently?
There are only two roles in Nostr, one is called Client (client) and the other is called Relay (relay). Relay and server are very similar concepts, and Client is responsible for fetching information from many Relays. As a simple analogy, we can regard Twitter as a structure with only one Relay, and the client only grabs information from this Relay, which is equivalent to "entrusting" all your user behaviors to this single and unique Relay , if it prohibits you from posting messages or downtime, your user behavior will also be forcibly interrupted, and you have no second choice in this ecology.
But there are so many Relays on Nostr, anyone can even run a Relay of their own, and the Client can also choose to capture only a part of the Relay's information, or not at all, but you can send your own information to all Relays superior.
At the same time, in Nostr's authentication system, it abandons the traditional concept of user name and password, but uses the concept of key pair. You hold your private key in your hand, and every time you publish a message, you attach the public key At the same time, use your private key to sign the entire message, proving that this message was sent by you "personally".
When it comes to key pairs, there is an unavoidable problem: key management.
Yes, when I use Damus, it automatically generates a key pair, but next time I need to log in to it, I have to use a function like "ledger", otherwise I can't remember the public key and private key , there must be a copy-paste action.
That's right, such a copy-and-paste process actually has a great risk of leaking. So I feel that anyone who has lost a password will be sensitive to how to manage one or more pairs of keys and how to make up for the loss. So for new users, how to introduce the concept of public key and private key to them through a perfect UI (user interface) or UX (user experience), and guide them to create their own accounts and manage their own accounts is a must. necessary.
But in fact, I am not particularly worried about this, because I feel that it is this feature that makes Nostr a bridge to Bitcoin. Because on Nostr, the worst thing is that the user loses the Post or loses the Follower, but in fact, you can get the Follower back through some means, and there will be no economic loss.
Q: So the custody and storage of keys is indeed a problem, but it is not as serious and urgent as imagined. And on the other hand, it actually helps Nostr break the circle quickly, because the Web 3 wallet actually still has a "barrier" that also blocks many Web 2 users.
In addition to this problem, what are the more urgent problems that are placed on the "table"?
Furthermore, with the influx of users, the traffic of the entire network will become very large. At this time, imagine an extreme situation. If everyone sends all the information to each Relay in order to save all their historical messages, when this situation becomes common, most of the Relays will store a large amount of duplicate information, and the Client is capturing When retrieving information, the Relay containing repeated information will also be scanned from beginning to end. This solution is relatively inefficient.
When the first wave of users grew rapidly earlier, many developers would have a very "crash" mood. They would feel that many solutions did not work. What should I do if so many people come in and the network will be paralyzed? So I think these are indeed issues that need to be resolved as much as possible before the next wave of user growth. If it is not resolved, it will bring users a lot of bad user experience, such as information cannot be loaded, client rendering and loading are slow, and it will be difficult to retain more users.
Q: Yes, just imagine if I am a content producer and publish content on Nostr’s Relay, if the time cost allows, if the operation is not complicated, I may also choose to send through multiple Relays, so it will indeed exist Situations where duplication of information results in slower overall performance and loading.
There are currently two mainstream solutions to this problem. One is to add a Layer on Nostr, which is equivalent to adding a layer of Layer 2 to the entire Nostr protocol. Only a limited number of nodes are running on it, and the number is smaller than the number of the entire Relay. Each The node caches the relay data it chooses, and the client only communicates with the cache node, which will improve the user experience. At present, there is a client that implements this function, and the above information loading is also very smooth, but this method has been opposed by many people. The reason is that we finally made a decentralized protocol, but finally returned to the client and only communicated with a few or Single node communication returns to the centralized route.
There is also a Gossip model, because the client that originally implemented this model is called Gossip. Its operation mode is that the user publishes a message, and the message will clearly state which relay the user reads the message from and which relay the user writes the message to. In this way, when the client captures all the information, it will only go to the associated node to capture the read and write information of the requesting user, which will reduce the situation of repeated Posts.
Q: Earlier we talked about the privacy and security of public keys, the pros and cons of Relay settings, and concerns about derivative issues.
Next, let's talk about the issue of Spam, which may be a hot topic at present. Why do you think the issue of Spam is so prominent in Nostr?
First of all, because Nostr is very new, there are some anti-spam methods, but the core of most of the measures is keyword filtering. I think that for English-speaking users, this may be the most complicated situation they have ever encountered, but It may not be the same for us, if I send a Martian text, the keyword filtering will not work at all.
Another thing is that most of the Relays are currently free. In the early stage, you may think that it doesn't matter. You can use my Relay for free without setting any rules. Everyone can read and write, but this also leads to Spam. any cost. The generation of accounts is also very easy. Traditional accounts may need to be bound to email addresses and mobile phone numbers, but in Nostr, as long as you click Generate Key (generate key), you can immediately obtain a new identity, so it is completely feasible to generate Spam accounts in batches Yes, and very simple, also approximately equal to 0 cost.
Q: Actually, what I don't understand is why they generate a large number of Spam accounts? Because there is also no token incentive or economic incentive in this system, what is the purpose of doing this? Just to send spam ads, phishing ads?
The main purpose is to attract traffic, and it’s not just about Spam, there will also be some sensitive information.
Q: Although the Spam problem has appeared in Nostr at this stage, it is actually an old problem in other fields. So in mature ecology or fields, what methods are there to solve the Spam problem?
One is to use deep learning technology through text or image recognition. The other is to analyze user behavior. In a centralized system, the behavior of a Spam account must be different from the behavior of ordinary users. For example, its sending frequency may change suddenly, and an account has not done anything for half a year. , but it suddenly became very active. Through the analysis of such user behaviors, a more precise spam prevention function can be achieved.
Q: We just talked about that all Relay nodes are free now, so if charging is an effective method?
Not all relays are free, but most of them, there are paid relays now, and paid relays do not have the Spam problem. Because before the emergence of a large number of Spam, relatively few people used the paid relay. It was not until suddenly a lot of IPs from mainland China and Hong Kong entered (because many Spam servers were set up in Hong Kong), that everyone thought of looking for a paid relay. , so during that period of time there was a significant increase in the number of user subscriptions paid for Relay.
Q: That is to say, the current solution to Spam, charging as a small-scale attempt, has played a certain role. Speaking of the solution, the next step is to talk about NIP (Nostr Implementation Possibilities, Nostr function implementation feasibility). At present, there are still many NIPs on Nostr, and they are constantly being updated. You are also a related Chinese compiler. I have two A question: First, what is the current status of the overall NIP proposal and how is it progressing? Second, do you find any interesting measures that can address the Spam problem?
At the beginning, the standard of NIP was relatively low. As long as 1 or 2 Clients implemented the protocol, they would be merged (merged). Now the requirements will be higher, because users are constantly increasing, and 3 to 5 clients may be needed. Client, or more than 5 implementations of a certain NIP, it will be merged to the main branch.
Previously, there were two agreements that had some relationship with Spam, one was active and the other was passive. What is active is that there is a sensitive content warning (sensitive information warning). If a user publishes content that is not suitable for minors, the Warning will be marked, which is also a relatively benign Spam. The other is a protocol called Report, which means that a user can be reported. I remember an incident happened on Nostr last month. A girl posted a selfie, and someone insulted her in the comment area, and many people clicked to report the comment.
And the next topic that cannot be avoided is whether depriving others of their right to speak by means of reporting is contrary to Nostr's so-called freedom? Auditing will definitely exist, but who will audit it, whether we can distinguish it through Relay, etc. are all problems. Of course, many people think that there may be a special Spam Relay, such as a Relay full of dark web black market information, a Relay full of pornographic information, etc., because the core of Nostr is that it will not stop you from doing anything.
The NIP of Report is actually very interesting. It first appeared because of the creator of Damus, based on the requirements of the Apple Store, that is, a Report function must be added before it is put on the shelves, until it finally evolved into a NIP.
Q: Yes, Damus was quite bumpy when it was launched in the Apple App Store. Maybe it was because of this relationship, so some underlying mechanisms needed to be added to it.
Yes, I encountered a lot of resistance because many things that are very simple to implement in Web 2 will become more complicated when transferred to Nostr's architecture.
Q: In fact, I think the topic of censorship and reporting is quite interesting, that is, should there be a boundary in decentralization? Is there a so-called "bottom line"? What do you think about this matter?
I think this may be a question of who will do the "screening", that is, who should grant the power of review, to whom, how to grant, and why.
Q: But the premise is that there must be "screening"?
Yes, I think "screening" is necessary. Especially considering that the people who have access to the Internet include minors, this is the main reason why I support screening.
Q: In the same way, this matter is also the same in Relay. If some Relays work very well through certain mechanisms or methods and provide a lot of high-quality content, then this (some) Relays will become It's bigger, more centralized, and other Relays are not used? Will it be like this?
From the perspective of user experience, Relay is almost an invisible existence, that is, it is difficult for users to intuitively realize that a certain Relay is obviously better than another Relay. In addition, the main target group currently using Nostr are people who are more concerned about the content they produce. They want to regain control of their own content. In fact, a basic principle of the operation of the entire Nostr protocol is that the client will definitely send messages It is impossible to send to multiple Relays, and it is impossible to send to only one Relay. Sending to one Relay will change the mode of "returning" to Twitter. There are currently many Relays, and there is almost no obvious difference in advantages and disadvantages among them, which can cause users to keep some of them.
Q: To be honest, I don’t think there is any obvious difference at this stage because everyone is similar and there is no content. At the beginning, we may not have a distinguishing standard for relays, and we may randomly enter a certain relay and be overwhelmed by a lot of messy messages, but if we now know that some relays may have a lot of Spam, then this type of relay may No need, maybe this is also the process of the environment "educating" users. Although the Relays at this stage are not uneven and do not give users a strong perception to drive people to choose certain Relays, the reason may be that everyone is similar and not very good, I think so.
But in this case, what you want to do is the client? Does this client only communicate with one relay?
Q: It’s just a metaphor or an analogy. We just hope that through certain methods, whether at the protocol layer or on the client side, we can present more high-quality content in Nostr’s overall ecosystem. But at least from the beginning of Jack's call list to the widespread popularity, it has not been seen that it can have a particularly prominent advantage in a certain track or in a certain field. Of course, I think this is also related to time, and we must give time to develop.
In terms of Nostr design, I think it can be simplified as "Start Client dumb Relay". That is to say, Relay actually has no function. Its only function is storage. In addition, when the Client requests information, it will perform a filter itself. For example, if there is a client, its Global (global) information does not display unfiltered relay information, but displays information sent by contacts in the three-tier social network, so in fact there are very few spams.
Q: From this perspective, I think this is also the cleverness of Nostr's minimalist design. Sometimes the more minimalist, the more design space there will be. Talking about this topic, we know that Nostr supports the Lightning Network (Lightning Network), and incentives and payments on Nostr are also inevitable topics for future development. Does it currently only support Bitcoin payments?
Yes, it currently only supports Lightning Network.
Q: It seems to me that this will limit users instead? Because the number of people who use Bitcoin as a means of payment is always limited?
This may be related to Nostr’s development history. Most of Nostr’s early developers were developers of the Lightning Network, and many of them have worked on the Lightning Network protocol, including wallet-related development. In addition, I don't think Nostr will be restricted by the Lightning Network. Nostr is something broader than the Lightning Network. Users can choose to only use its social functions and not use the payment function. In the final analysis, the core group it attracts is still the group who want to control the content they produce.
Q: How do you see the future development of Nostr?
In fact, many people have asked me a question: "How should I invest in Nostr?" To be honest, I really don't know how to answer this question specifically. I think it's good to just build something. I don't think Nostr is actually It does not belong to the category of Web 3, it is just a decentralized protocol.
For example, there is a protocol called Badge on Nostr, which means that users can sign an image and send it to other users, so that the badge will be displayed under the avatar on the client, but many people use it as an NFT. Of course, I wouldn't be surprised if one day you have to charge to get a Badge, there may be some similarities between them, but there are still big differences. In addition, I think that any company that wants to do information exchange business in the future, if it does not integrate into Nostr, the result of waiting for this company may be to gradually disappear.
Q: Information exchange? I think this is a good direction to think about.
I think anyone who has experienced Nostr's features will agree with this sentiment. One account and one key pair of the user can pass through all APPs, so there is no need to be restricted by any platform. Your fans on one platform can take it to another platform at any time, and the competition dimension will become more fair. All users compete on the same dimension, all clients compete on the same level, and all Relays compete on the same level. Compete on the same level. And there will be no situation where a low-level content producer will gain a lot of traffic just because the platform it relies on is very strong.
In this case, if you are a content producer, all your user audiences scattered on all platforms can see the content you produce. This is the most important point in my opinion, and it is also to ensure that Nostr will continue to grow a little.
In addition, Nostr can also do other things besides Social Media. For example, there is a project called Nostrocket. This project is a Nostr-based consensus layer. In other words, we can use it to form a DAO on Nostr, and realize some functions that are not completely similar to smart contracts. It will also be more efficient than smart contracts. flexible.
Q: Okay, thank you Teacher Sherry for sharing. Do you have anything else to add to today’s topic?
Welcome everyone to the Meetup in Hong Kong hahaha, welcome everyone.
Q: That’s right hahaha, we are going to jointly hold an offline Meetup in Hong Kong on April 14th. This may also be the first relatively large-scale Nostr offline meeting in the Chinese community. Of course, the overall background is that we will launch the global Nostr Hackathon in the near future. We also welcome Builders like Sherry to participate in the project competition. The prize money of the competition is still very generous. Enthusiasts, developers, project parties, protocol researchers, and people with various proposals are welcome to participate.
In addition, many things in Nostr at this stage are not perfect, so there are many Ideas that have not had a chance to be realized for the time being. If there are Nostr developers listening to this podcast, they can try it.
First, for content producers, I personally feel that a project must generate profits before it can continue to operate. If it does not have any profits for the people involved, the final result may not be good. I once had an idea about music creators. Suppose I want to release a piece of music in three days, and if some users want to listen to it in advance, then we can use the Pay to listen (pay to listen in advance) model, because we already have payment tools (Lightning Network) support, and Nostr, in such a user scenario, its biggest problem is that after the user pays, he may leak the content, so that the potential paying crowd will decrease. Then you can Encode (encode) the relevant information of the payer who purchased the music, that is, add a layer of frequency that is barely audible to the human ear on the music, and then Decode (decode) the user's public key and private key at the Client level. In this way, once someone buys and leaks it, it can be traced back to him through Decode, which can cause psychological pressure similar to "social death".
Another one is that there is no function similar to Zhihu or Quora (a question-and-answer website similar to Zhihu) at the Nostr level. Because Nostr lacks a better content recommendation mechanism, it is difficult for users to find interesting content, and the traditional mechanism has certain limitations, because in the Nostr scenario, account generation does not cost any, which is equivalent to unlimited Like .
There is also the so-called encrypted group chat, which is also in great demand. Today's chat software, such as Telegram, is called group chat, but after creating a Channel (similar to a chat group), everyone can see what the people in it talk about, and everyone can enter and exit at will, which is equivalent to "Running naked in the square", I think the real group chat is similar to "running naked in the bathhouse".
Q: Yes, it has a distinction between a large environment and a small environment.
