Written by: git-sgmoore and fiatjaf (nostr)
Compilation: The Way of DeFi
Note: Recently, a decentralized social protocol called nostr has been favored by the Bitcoin community, which has attracted a controversial ban from Elon Musk, the current CEO of Twitter, and also made Jack Dorsey, the former CEO of Twitter, pay 14 BTC out of his own pocket to fund it. So what is the magic of nostr?
Twitter's latest ban policy
According to the introduction, nostr is a minimalist protocol that can create a censorship-resistant global "social" network once and for all.
nostr does not rely on any trusted central server. It is based on cryptographic keys and signatures and does not rely on P2P technology. It does not issue tokens.
So how does it work? In short: everyone runs a client, this can be a native client, a web client, etc. To publish something (like a post), you sign it with your key and send it to multiple relays (servers hosted by other people or yourself). To get updates from other people, you ask multiple relays if they know about these other people. Anyone can run a relay, it's very simple, it doesn't do anything except accept posts from certain people and forward them to others. We don't need to trust the relays either, the signatures are verified on the client side.
2. Nostr Client Function Comparison
3. List of projects based on Nostr
1. Problems with other solutions
1. Twitter’s Problem
- Twitter has ads;
- Twitter uses strange tricks to keep you addicted;
- Twitter doesn’t show you the actual history of people you follow;
- Twitter bans some people’s accounts;
- Twitter uses shadowbans .
- Twitter has a lot of spam;
2. Problems with Mastodon and Similar Apps
- User identities are attached to domain names controlled by third parties;
- Server owners can ban you just like Twitter, server owners can also block other servers;
- Migration between servers is an afterthought and can only be done with server cooperation. It does not work in an adversarial environment (all followers are lost);
- There is no clear incentive to run servers, so they tend to be run by hobbyists and people who want to attach their name to a cool domain. Users are then subject to the tyranny of one person, which is often worse than a large company like Twitter, and they can't migrate away;
- Since servers tend to be amateur, they are often abandoned after a while - which is effectively the equivalent of banning everyone;
- There is no point in having a large number of servers if updates to each server must be painfully pushed (and saved!) to a large number of other servers; this is exacerbated by the large number of servers, so more data must be delivered to more places more frequently;
- For the specific example of video sharing, ActivityPub enthusiasts realized that it was simply impossible to transfer videos between servers like text annotations;
3. The problem of SSB (Secure Scuttlebutt)
- There aren't too many problems with it, which I think is great. In fact, I was going to build on it, but its protocol is too complicated because it wasn't conceived as an open protocol at all. It's just written in JavaScript, probably as a quick way to solve a specific problem, so it has weird and unnecessary quirks, like signing a JSON string, which must strictly follow ECMA-262 6th edition rules;
- It insists on a chain of updates from a single user, which seems unnecessary to me and adds bloat and inflexibility to the content - each server/user needs to store all the post chains to ensure new posts are valid. Why do they do this? (Maybe they have a good reason);
- It is not as simple as Nostr, as it is designed primarily for P2P synchronization;
- Still, it might be worth considering using SSB instead of this custom protocol and just adapting it to the client-relay-server model, since it's always better to reuse a standard than to try to get people to use a new one.
4. Other issues that require running server solutions
- They require everyone to run their own server;
- Sometimes people still get censored in these areas because domain names can get censored;
2. How Nostr works
- Nostr has two components: clients and relayers. Each user runs a client, and anyone can run a relayer.
- Each user is identified by a public key, each post is signed, and each client verifies these signatures.
- Clients get data from relayers of their choice and publish data to other relayers of their choice. Relays do not communicate with one another, only directly with users.
- For example, to "follow" someone, a user simply instructs their client to query the relayers it knows about for posts from that public key.
- On startup, the client queries all the relayers it knows about for data about all the users it follows (e.g., all updates from the last day), and then displays that data to the user in chronological order.
- A "post" can contain any kind of structured data, but the most commonly used ones will go into the standard so that all clients and repeaters can handle them seamlessly.
3. How does Nostr solve problems that other solutions cannot solve?
Problem 1: User banned, server shut down
A relayer can block a user from posting anything on it, but this has no effect on the user as they can still post content to other relayers. Since users are identified by public keys, they do not lose their identity and fan base when they are banned.
Rather than requiring the user to manually enter new relayer addresses (although this should also be supported), every time someone you follow posts a server recommendation, the client should automatically add it to the list of relayers it will query.
If someone is using one relay to publish their data, but wants to migrate to another relay, they can post a server recommendation to the previous relay and then leave;
If someone is banned from so many repeaters that they can't broadcast their server recommendations, they can still let a few close friends know which repeater they are now posting to through other means. These close friends can then post server recommendations to the new server, and slowly the banned user's old fan base will start to find their posts from the new repeater again.
All of the above provisions are also valid when the repeater stops working.
Problem 2: Censorship Resistance
Each user can publish their content updates to any number of relays.
Relayers can charge users a fee (negotiation of fees is currently outside the protocol) to post there, which ensures censorship resistance.
Problem 3: Spam
If spam is a concern for a relay, it can require payment or other forms of authentication for posting (such as an email address or phone number) and associate these internally with the public key before posting to that relay or use other anti-spam techniques (such as hashcash or captchas). If a relay is used as a spam carrier, it can easily be delisted by clients, who can continue to get updates from other relays.
Problem 4: Data Storage
In order for the network to remain healthy, it does not need hundreds of active relayers. In fact, it only needs a handful to work well, because in the event that existing relayers start to fail, new relayers can be easily created and propagated through the network. Therefore, the amount of data storage required is generally less than Mastodon or similar software.
Or consider a different outcome: one in which there are hundreds of niche relayers run by amateurs, each responsible for relaying updates for a small group of users. This architecture can scale, too: data is sent from users to a single server, and from that server it is sent directly to the users who will use it. It doesn't have to be stored by anyone else. In this case, it's not a big burden for any single server to handle updates from other servers, and having amateur servers isn't a problem.
Problem 5: Heavy content such as videos
It is easy for relayers to reject the content of big data or charge for accepting and hosting big data content. When the information and incentives are clear, market forces can easily solve this problem.
Question 6: Display method
Each client can decide how to best display posts to the user, from using artificial intelligence to decide the order in which updates you'll see to just reading them chronologically.
4. FAQ
1. This is simple, so why hasn’t anyone done this before?
A: I don't know, but I guess it has to do with the fact that the people who create social networks are either companies who want to make money, or P2P activists who want to do things completely without servers, and neither of them sees the particular combination of both worlds that Nostr uses.
2. How do I find people to follow?
A: First you have to know them and get their public key somehow, either by asking or seeing it somewhere. Once you are in the Nostr social network you can see their interactions with other people and then you can start following these people and interact with them as well.
3. How do I find the repeater? What happens if I am not connected to the same repeater as others?
A: You will not be able to communicate with that person. However, event notifications can be used so that your client software (or you manually) knows how to connect to other people's relays and interact with them. There are other ideas to solve this problem in the future, but we can never guarantee perfect reachability, no protocol can.
4. Can I know how many people are following me?
A: No, but if the repeaters cooperate in an additional protocol way you can get some estimates.
5. What are people’s motivations for running repeaters?
A: This question is misleading, it assumes that relayers are free and people can move data through them. Yes, in this case the incentives don't exist. This actually applies to DHT nodes in all other p2p network stacks as well: what incentive do people have to run DHT nodes?
6. If the repeater is only on AWS or Azure, what difference does it make?
A: Today, there are thousands of VPS providers around the world, not just AWS or Azure. AWS or Azure are exactly the providers that large-scale single centralized service providers use, but for smaller relay servers, any VPS will do the job just fine.
Protocol Specification
See the NIPs , especially NIP-01, for a reasonably detailed explanation of the protocol specification (hint: it's very short).
