Partnered With:

Read nostr: A decentralized social protocol that scares Elon Musk

Read this article in 16 Minutes

With current CEO Elon Musk's controversial ban policy and former CEO Jack Dorsey funding it out of 14 BTC's own pocket, what's the magic of nostr?

原文标题：《一文了解 nostr ：一个让 Elon Musk 感到害怕的去中心化社交协议》

Original article by git-sgmoore and fiatjaf (nostr)

The DeFi way

Note: Recently, a decentralized social protocol called nostr gained traction with the Bitcoin community, prompting Twitter CEO Elon Musk's controversial blocking policy, And with former Twitter CEO Jack Dorsey funding it out of 14 BTC's pocket, what's the magic of nostr?

Twitter's latest ban policy

According to the presentation, nostr is a minimalist protocol that creates a censor-resistant global "social" network once and for all.

nostr does not rely on any trusted central server, is based on cryptographic keys and signatures, and does not rely on P2P technology, nor does it issue tokens.

So how does it work? Simply put: everyone runs a client, which 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 Repeaters (servers hosted by someone else or yourself). To get updates from other people, you can ask multiple Repeaters if they know about these other people. Anyone can run the repeater, which is very simple and does nothing but accept posts from certain people and forward them to others. We also don't need to trust the repeater, the signature is verified on the client side.

1. How do I start using Nostr

2. Comparison of Nostr client functions

3. List of items based on Nostr

First, problems existing in other solutions

1. The Twitter problem

Twitter has ads;

Twitter uses strange tricks to get you hooked;

Twitter doesn't show the real history of the people you follow;

Twitter bans certain people's accounts;

Twitter uses the Shadowbans.

Twitter has a lot of spam;

2. Mastodon and similar applications

The user identity is attached to the domain name controlled by a third party;

The server owner can block you like Twitter, and the server owner can block other servers;

Migration between servers is an afterthought and can only be done if the servers collaborate. It doesn't work in adversarial environments (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 name. Users are then subject to the tyranny of one man, often worse than a big company like Twitter, and cannot migrate out;

Because servers tend to be amateurs, they are often abandoned after a while - effectively the same as banning everyone;

If every server update had to be painfully pushed (and saved!) To a lot of other servers, there's no point in having a lot of servers; This is exacerbated by the large number of servers, so more data must be delivered to more places more often;

For the specific example of video sharing, ActivityPub enthusiasts realize that it is completely impossible to transfer video between servers like text annotations;

3. Secure Scuttlebutt (SSB) problems

It doesn't have too many problems, which I think is great. In fact, I'm going to base it on that, but the protocol is too complicated because it's not considered an open protocol at all. Written only in JavaScript, it may be a quick way to solve a particular problem, so it has strange and unnecessary quirks, such as signing a JSON string that must strictly follow the rules of ECMA-262 Version 6;

It insists on getting a series of updates from a single user, which to me is unnecessary and adds to the bloat and rigidity of content - each server/user needs to store all chains of posts to ensure that new posts are valid. Why would you do that? (Maybe they have a good reason);

It is not as simple as Nostr because it is designed primarily for P2P synchronization;

However, it may be worth considering using SSBS instead of this custom protocol and adapting it only to the client-side relay server model, as it is always better to reuse standards than to try to get people to use new standards.

4. Other problems requiring the running of the server solution

They require everyone to run their own servers;

Sometimes people are still censored in these areas because domain names can be censored;

Two, the operation principle of Nostr

Nostr has two components: a client and a repeater. Each user runs one client, and anyone can run the repeater.

Each user is identified by a public key, each post has a signature, and each client verifies these signatures.

Clients get data from the repeater of their choice and publish it to the other repeater of their choice. The repeater does not communicate with another repeater, only directly with the user.

For example, to "follow" someone, a user simply instructs their client to query the repeater it knows about for posts from that public key.

At startup, the client queries data from all the Repeaters it knows about for all the users it cares about (for example, all updates from the most recent day), and then displays that data to the user in chronological order.

"Posts" can contain any type of structured data, but the most commonly used data will go into the standard so that all clients and Repeaters can process them seamlessly.

Iii. How does Nostr solve problems that other solutions cannot? Fault 1: The user is banned and the server is shut down

The repeater can prevent users from Posting anything to it, but this makes no difference to users, as they can still post content to other Repeaters. Since users are identified by their public keys, they do not lose their identity as well as their fan base when they are banned.

Instead of requiring the user to manually enter a new repeater address (although this should also be supported), whenever someone you follow posts a server recommendation, the client should automatically add it to the list of Repeaters it will query.

If someone is using one repeater to publish their data, but wants to migrate to another repeater, they can publish a server recommendation to the previous repeater and leave;

If someone is banned by so many Repeaters that they are unable to broadcast their server recommendations, they can still let some close friends know which repeater they are now Posting to in other ways. Those close friends can then post server recommendations to the new server, and slowly, the banned user's old fan base will start finding their posts again from the new repeater.

All of the above are also valid when the mediator stops working.

Problem 2: Resistance to censorship

Each user can publish their content updates to any number of Repeaters.

Repeaters can charge users a fee (currently negotiated for a fee that is not covered by the agreement) to publish there, ensuring censorship resistance.

Problem 3: Spam

If spam is a concern for a repeater, it can require payment for publication or some other form of authentication (such as an email address or phone), associate these internally with a public key, and then publish it to that repeater or use other anti-spam techniques (such as hashcash or captcha). If a repeater is being used as a spam carrier, it can easily be canceled by clients, who can continue to get updates from other Repeaters.

Problem 4: Data storage

Hundreds of active Repeaters are not needed to keep the network healthy. In fact, it only needs a handful to work well, because in the event that existing Repeaters start to go wrong, new ones can be easily created and propagated across the network. As a result, the amount of data storage required is generally less than that of Mastodon or similar software.

Or consider a different outcome: there are hundreds of niche Repeaters run by amateurs, each responsible for updating the relay for a small group of users. This architecture can also be extended: data is sent from the user to a single server, and from that server directly to the user who will use the data. It doesn't have to be stored by anyone else. In this case, it is not too much of a burden for any single server to handle updates from other servers, nor is it a problem to have amateur servers.

Problem 5: Heavy content such as video

Repeaters can easily reject big data content or charge for accepting and hosting big data content. When the message and incentives are clear, it is easy for market forces to solve the problem.

Problem 6: Display mode

Each client can decide how best to display posts to users, from using artificial intelligence to determine the order in which you'll see updates, to just reading them in chronological order.

Iv. FAQ

1. It's simple, so why hasn't it been done before?

A: I don't know, but I guess it has something to do with the fact that the people who build social networks are either companies looking to make money or P2P activists who want to make things without servers at all, neither of whom see the particular combination of two worlds that Nostr uses.

2. How do I find people to follow?

A: First, you have to know them and get their public key in some way, whether it's by asking or seeing it somewhere. Once you're on Nostr's social network, you can see how they interact with other people, and then you can start following them and interacting with them.

3. How do I find the repeater? What happens if I'm not connected to the same repeater as someone else?

A. You won't be able to communicate with that person. But you can use event hints so that your client software (or you manually) knows how to connect to someone else's repeater and interact with them. There are other ideas to address this in the future, but we can never guarantee perfect accessibility, not by any agreement.

4. Can I know how many people are following me?

A: No, but you can get some estimates if the Repeaters cooperate in an additional protocol way.

5. What motivates people to run Repeaters?

A: This question is misleading because it assumes that Repeaters are free and people can move data through them. Yes, in this case, the incentives don't exist. This actually applies to all the other DHT nodes in the p2p network stack: what incentive do people have to run DHTS?

6. What difference does it make if the repeater is only on AWS or Azure?

A: Today, there are thousands of VPS providers around the world, not just AWS or Azure. AWS or Azure are exactly the providers used by a single centralized service provider on a large scale, and for smaller relay servers, any VPS can do the job well.

Protocol specification

Please refer to the NIP ‌, especially the NIP - 01, in order to obtain the detailed explanation of proper protocol specification (hint: it's very short).