Nostr: открытый протокол децентрализованной коммуникации без контроля корпораций

Nostr is an inclusive communication commons. A simple standard that defines a scalable architecture of clients and servers that can be used to spread information freely. Not controlled by any corporation or government, anyone can build on Nostr and anyone can use it. Nostr embraces the chaos of the early internet—multiple kinds of data, diverse forms of user interaction and different clients providing their own perspectives over the same underlying information. The client is the app that is running on your computer or phone, the server is whatever is running on a cloud somewhere with a domain name. In centralized platforms and other protocols, one client talks to a single server. In Nostr clients connect to many. Nostr's single unit of information is a cryptographically signed note, these are created by users in their client software and published to one or more relays. Clients are smart and act as agents for the users who install them. They decide which relays to connect to and when and what data to request according to the circumstance and user preferences. These are the servers that notes are published to and read from. They cannot change the contents of notes (that would invalidate the signature), but they can decide what to store and for how long. In Nostr, every user is represented by a secret number called a "key" and every message carries a digital "signature" that proves its authorship authorship and authenticity without the need for any authority to say so. This foundation of trust enables the decentralized broadcasting of information. Nostr doesn't subscribe to political ideals of "free speech" — it simply recognizes that different people have different morals and preferences and each server, being privately owned, can follow their own criteria for rejecting content as they please and users are free to choose what to read and from where. When the network effect is not tied to a single organization a group of users cannot harm others. Watch › If you are a programmer or know how to run servers it is trivial to run your own relay with your own rules. Write code › Besides being a natural medium for a Twitter-like microblogging social network, Nostr can also be used for other purposes. And not only similar things like sharing videos, longform articles, pictures or voice notes. There are initiatives on Nostr for the development of sub-protocols that power closed groups, decentralized wikipedia, couchsurfing, marketplaces or web annotations; as well as protocols that don't use Nostr for the core data but as a coordination and discovery mechanism, such as decentralized code collaboration using git, file hosting, torrent sharing and video livestreaming. Browse the NIPs Nostr is an idea with a lot of open-source software around it and a large userbase, but not a finished, polished product that you can buy without stress. We're still pretty much in the phase where new programmers and early adopters are needed to help us refine the protocol flows and the user experience. The so-called "outbox model" is the canonical way of implementing a censorship-resistant client, but its parameters are fluid. Learn about it › NIP-29 describes a way to do closed groups for forums or chat that can be very efficient by relying on a relay but are still censorship-resistant. Read the guide › Nostr enables true freedom by allowing users to stay connected to their audience even in adverse scenarios. Patricia publishes a special event announcing which servers she will use as her "outbox relay" for publishing notes. She then starts sending all her posts to these chosen relays, creating a predictable place where others can find her content. When Florian wants to read Patricia's posts, his client looks up her announcement and connects directly to her announced outbox relays. This targeted approach is simple and efficient. If Patricia's current relay bans her or shuts down, she can easily switch to different relays — perhaps some run by friends, a paid service, or her own server. She simply publishes a new announcement and continues to post without losing her audience. Florian's client continuously monitors for updates to Patricia's relay list. When she switches relays, his client eventually starts querying her new locations, ensuring he never misses her posts even as the network topology changes. From the publisher side to the follower side clients behave smartly, keeping a local state and reacting to new information in order to ensure that the flow of information continues. After all, these notes are important, it would be sad to miss too many of them. It may sound like Nostr is very good, but what about these hard issues? A protocol is like a common language that multiple different software can use to talk to each other, it's like e-mail, HTML or HTTP. When we say "protocol" we mean that there is no need to use a specific app in order to be in Nostr: there are many apps that talk the same language and can be used (mostly) interchangeably — and each has its own take on how to do and display things. In the default feed you never see any spam, because clients will only fetch information from people that you follow. In that sense no one can "push" spam into you. It's trickier when you want to see, for example, replies to your posts, in that case a client might be programmed to fetch anything that claims to be a reply from anyone, which might include spam. The way we can deal with it on Nostr is by restricting our area of contact with the spam: for example, some clients may easily decide to only display replies that come from people followed by people you follow. More refined strategies involve announcing and then only reading notes from relays known to be "safe" according to your criteria (could be relays that require payment, relays that do screening for humans, relays that only accept members of certain communities or political affiliations etc). There are no perfect solutions. But these do not exist anywhere, centralized platforms are also full of spam. Nostr at least isn't naïve and tries to build resiliency from the start. Yes, Nostr is just a basic client-server architecture. And the fact that users can naturally spread among hundreds of different relays while clients can query dozens of relays that they're interested in at the same time means the network has a natural load balancer (which doesn't prevent a single relay from having its own internal load balancer either). Another (almost the opposite) concern that may be raised is with problems arising from clients having to connect to too many relays if the profiles being followed for whatever reason decide to spread way too much, but this shouldn't be a problem either because people tend to follow many accounts with similar content and these will tend to share relays. Still, if it happens, it's cheap for native apps to open many hundreds of WebSocket connections simultaneously (as they will be getting very few data in each of those). For web apps that isn't so hard, but we can still go up to a few hundreds without big problems. Regardless of any of that, in any complete enough app that wants to display a "following feed" it's already necessary to store events in a local database, and that will make all these issues easy to deal with as you can do the event requests in batches instead of all at once. Harassment is similar to spam in the sense that anyone can still create the undesired content and publish to the relays that accept them. All the techniques mentioned in avoiding spam can also be applied in this case, but if we're talking about specific individuals with a permanent identity and not only an army of bots in this case the problem becomes easier, as those individuals can just be blocked by their target and their content will vanish. Presumably friends of such target will also block, and creative solutions involving shared blocklists can be created such that some people don't even have to click the block button directly. Other approaches involving, for example, relays with restricted read (that can emulate "protected account"/"only friends" features seen in centralized platforms) can further improve this. There are many problems with Mastodon, mostly due to the fact that it doesn't rely on any cryptography. Because it cannot do the multi-master approach of Nostr due to lack of cryptography, identities are assumed to be "owned" by the server, which is fully trusted by its tenants. Mastodon server owners can do all the harm centralized platforms can do to their underlings, which are completely helpless in case of misbehavior or even in the normal case where a server owner loses their server or decides to shut down for whatever reason. Worse than that, for many of its purported features, such as blocking or direct messages, users have to also trust owners of the other servers. There are also problems with reliance on the DNS system, but we don't have to talk about those. The most interesting feature of Mastodon is that by its nature it creates communities with shared values that grow in each of its servers. Or, should I say, that should be a feature if it actually worked like that. In fact these are not really communities, but a mashup of users that may share some interests among each other, but also have other interests and those other interests end up polluting the supposed "community" with things that do not interest the other users. Nostr, on the other hand, can create real communities around relays, specifically because users don't have to fully belong to those relays, but can go to them only for some of their needs and go to other relays for other needs. Bluesky has many problems, the two most pronounced are: Relay-AppView-Client flow assumes only one canonical source of data at each step (unlike Nostr multi-master architecture) that source is always a server that has power to censor, shadowban, reorder data and so on. Clients are assumed to be dumb and trust the AppView, and here you have room for all sorts of undesired shenanigans. Then AppViews also assume to source their data from a single Relay, and here you have room for the same effect. You could argue that Bluesky Clients could become smart and start sourcing data from multiple AppViews, or from multiple Relays, or that the AppViews could rely on multiple Relays, or that the Clients could talk directly to the PDSes — and all of that is possible and would indeed bring solutions, but notice that if those things started happening Bluesky would end up becoming Nostr, except with more steps. Yes, this clip answers it well. But basically the answer is the same as the question about scale: if users can go to whatever relay they want we'll see relays ran by all sorts of people and entities. Running servers is very cheap, and a relay can run on a $5/mo server and house at least a few thousand users. It's not hard to imagine relays ran by communities, individuals who just want to be useful to others, big organizations wanting to gain good will with some parts of the public, but also companies, client makers, and, of course, dedicated entities who sell relay hosting for very cheap. It's not a feature of the world at large to be able to see or hear everything that is happening everywhere at all times. Nostr inherits that property from the world, making it so that you can only see what you focus your attention on (and you're allowed to see by the relay that hosts that information). It's only possible to search on what you have seen, so search engines will always have to crawl some parts of the network they chose to and index those to enable public search. The word "chose" is employed because, as we know, there can't be a "global" view of the network (and no one would want such a thing anyway as it would be full of spam), so indexers have to choose. This is not different from Google deciding what websites to index. On the other hand, it's surprisingly doable for clients to store all the posts from people you follow, or all the posts you have seen or interacted with over time (since it's just text, a huge amount of notes can fit in the same space that would otherwise be required to store a single photo, for example) then provide local search over that. That kind of search will be sufficient for most of the cases you would reach out for a search bar in a centralized platform (which is to search for things that you have seen before), and perhaps even more useful since it would naturally filter out all the unrelated garbage. Last, niche or community-oriented relays can also provide very useful search capabilities by just indexing the notes they have stored locally, already filtered and scoped to that relay's topic or cohort (imagine searching over a Discord, Slack or Telegram group, for example). The most basic way to do that is by following the natural habits used by most centralized social platforms users since a long time ago: by looking at the people you follow and whom they're interacting with. But also it's not true that Nostr doesn't have algorithms. Nostr can have algorithms of all kinds: manual, automatic, AI-powered or rule-based. Some of these algorithms can be run entirely locally on clients (for example, surfacing posts from the times when you were not online, or from people that make fewer posts), while other algorithms can be provided by all sorts of relays, either by naturally surfacing posts from a community of people you don't follow or by dedicated relays that have the stated purpose of curating content desirable for a target audience or even by targeting specific users. Nostr uses the same cryptographic principles of Bitcoin and was kickstarted mostly by a community of Bitcoiners, so it has disproportionately attracted the attention of Bitcoiners at the start, but aside from that it doesn't have any relationship with Bitcoin. It doesn't depend on Bitcoin for anything and you don't have to know or have or care about any Bitcoin in order to use Nostr. What about "zaps"? Zaps are a standard for tipping Nostr content using Bitcoin that is implemented by some Nostr clients, but it's fully and completely optional and if you don't care about Bitcoin you don't have to bother about it. Quotes from those who know better and decided to like Nostr. No one owns Nostr, no one can own Nostr, it's an open-source protocol. No one can build a fence to stop the flow of information. Nostr is an open protocol. If a platform is a silo, a protocol is a river: no one owns it, and everyone is free to swim. I want to claim that Nostr has discovered a new fundamental architecture for distributed protocols. Not federated, not P2P.