Original title: "One article to understand nostr: a decentralized social protocol that scares Elon Musk"
Compilation of the original text: The Way of DeFi
Compilation of the original text: The Way of DeFi
image description
Twitter's updated prohibition policy
According to the introduction, nostr is a minimal 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, nor does it issue tokens.
So how does it work? In simple terms: everyone runs a client, this could 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 relayers (servers hosted by other people or yourself). To get updates from other people, you can ask multiple repeaters if they know about those other people. Anyone can run a repeater, it's very simple, it does nothing but accept some people's posts and forward them to others. We also don't need to trust the relayer, the signature is verified on the client side.
1. How to start using Nostr
2. Nostr client function comparison
first level title
secondary title
secondary title
Twitter has ads;
Twitter uses weird tricks to get you hooked;
Twitter does not show the real history of the people you follow;
Twitter will ban certain people's accounts;
Twitter uses Shadowbans.
Twitter has a lot of spam;
Server owners can ban you like Twitter, server owners can also block other servers;
User identities are attached to domain names controlled by third parties;
Server owners can ban you like Twitter, server owners can also block other servers;
Migration between servers is an afterthought and can only be done with the cooperation of the servers. It doesn't work in adversarial environments (all followers are lost);
There is no clear motivation for running servers, so they tend to be run by hobbyists and people who want to attach their name to a cool domain name. Then users are subject to the tyranny of one person, which is often worse than a large company like Twitter, and they cannot migrate out;
Since servers tend to be amateurish, they are often abandoned after a while - which effectively amounts to banning everyone;
There's no point in having a large number of servers if each server's updates have to be painfully pushed (and saved!) to a large number of other servers; this is exacerbated by the sheer number of servers, so more data must be delivered to more places;
secondary title
3. Problems with SSB (Secure Scuttlebutt)
It doesn't have too many issues, which I think is great. In fact, I was going to build on it, but its protocol is too complicated because it is not considered an open protocol at all. It's just written in JavaScript, probably as a quick fix for a specific problem, so it has weird and unnecessary quirks like signing a JSON string which must strictly follow the ECMA-262 6th edition rules;
It insists on getting a chain of updates from a single user, which to me is unnecessary and adds to the bloat and rigidity of the content - every server/user needs to store all the post chains to ensure new posts It is effective. Why do they do this? (maybe they have good reasons);
It's not as simple as Nostr because it's mainly designed for P2P synchronization;
secondary title
4. Other issues that require running server solutions
They require everyone to run their own server;
first level title
2. The operating principle of Nostr
Nostr has two components: clients and relayers. Each user runs a client, and anyone can run a repeater.
Every user is identified by a public key, every post is signed, and every client verifies those signatures.
Clients fetch data from a relayer of their choice and publish data to other relayers of their choice. A repeater does not communicate with another repeater, only directly with users.
For example, to "follow" someone, a user simply instructs their client to query the relayers it knows for posts from that public key.
On startup, the client queries all repeaters it knows about for data on all users it follows (eg, all updates from the most recent day), and then displays that data to users in chronological order.
first level title
secondary title
Problem 1: User Banned, Server Down
A repeater can prevent users from posting anything on it, but this has no effect on users as they can still post content to other repeaters. Since users are identified by public key, they don't lose their identity and fan base when they get 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 relayer to publish their data, but wants to migrate to another relayer, they can post a server recommendation to the previous relayer, and leave;
If someone gets banned from so many repeaters that they can't broadcast their server recommendations, they can still let some close friends know which repeater they're posting to right now by other means. These close friends can then post server recommendations to the new server, and slowly, the banned user's old fanbase will start finding their posts again from the new repeater.
secondary title
Problem 2: Censorship Resistance
Each user can publish their content updates to any number of relayers.
secondary title
Problem 3: Spam
secondary title
Problem 4: Data Storage
In order for the network to remain healthy, hundreds of active repeaters are not required. In fact, it works well with only a handful of them, since new ones can be easily created and propagated through the network in the event existing ones start to fail. Therefore, the amount of data storage required is generally less than that of Mastodon or similar software.
secondary title
Question 5: Video and other heavy content
secondary title
Question 6: How to display
first level title
4. FAQ
answer:
answer:I don't know, but I guess it has something to do with the fact that the people who created the social network were either companies trying to make money, or P2P activists who wanted to do stuff without servers at all, and neither of them saw what Nostr used A specific combination of both worlds.
answer:
answer:First, you have to know about them and somehow get their public key, either by asking or seeing it somewhere. Once you're in the Nostr social network, you can see their interactions with other people, and you can start following and interacting with them too.
answer:
answer:You will not be able to communicate with that person. But it is possible to use event hints so that your client software (or you manually) know how to connect to and interact with other people's repeaters. There are other ideas to solve this problem in the future, but we can never guarantee perfect reachability, neither can any protocol.
answer:
answer:No, but you can get some estimates if the repeaters cooperate in an additional protocol way.
answer:
answer:This question is misleading, 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 DHT nodes in all other p2p network stacks as well: what incentive do people have to run DHT nodes?
answer:
answer:Today, there are thousands of VPS providers around the world, not just AWS or Azure. AWS or Azure are exactly what large scale single centralized service providers use, and for smaller relay servers any VPS will do the job well.
protocol specification
Original link
