Notes and Other Stuff Transmitted by Relays

An open social protocol with a chance of working 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. All Kinds of Stuff Like the internet itself: open and chaotic 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. rebase Many clients, many servers 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. Learn how Nostr is different › signature A new paradigm for communication 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. Watch a human-friendly explanation › shield Pro-censorship The protocol is ownerless, relays are not 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. handshake Freedom of association When the network effect is not tied to a single organization a group of users cannot harm others. Watch › landscape_2 Your own piece of Nostr 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 › lightbulb_2 New Ideas Exploring the commons 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 grass Ecosystem Still under construction 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. comment Microblogging The so-called "outbox model" is the canonical way of implementing a censorship-resistant client, but its parameters are fluid. Learn about it › hub Relay-based groups 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 › account_circle Following How Nostr works Nostr enables true freedom by allowing users to stay connected to their audience even in adverse scenarios. contact_support FAQ I've got some questions! It may sound like Nostr is very good, but what about these hard issues? What is a "protocol"? 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. How does Nostr handle spam and unwanted content? 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. Will Nostr scale effectively with massive user adoption? 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. What protections does Nostr offer against online harassment? 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. Why not just use Mastodon/Fediverse? 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. Why not just use Bluesky/ATProto? Bluesky has many problems, the two most pronounced are: Identity centralization: all accounts belong to PLC, a database ran by a central entity that can censor at will — or, alternatively, they can belong to a DNS domain, which is cumbersome, also censorable, risky and is not expected to be used by many anyway; Data centralization: because the 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