• A Nostr Manifesto
  • The internet should be replaceable
  • 1. Identity should belong to people
  • 2. Applications should be replaceable
  • 3. Servers should be infrastructure, not authorities
  • 4. Publishing should not require permission
  • 5. Interoperability should be ordinary
  • 6. Preserve the exit
  • 7. Leave room for the unexpected
  • 8. Nostr is not a social network
  • 9. Machines can participate too
  • 10. Complexity is an engineering problem
  • 11. Convenience and control can coexist
  • 12. Do not rebuild what we escaped
• Keep the network

§A Nostr Manifesto

§The internet should be replaceable

The internet was not supposed to require permission.

You could run a server, build a website, write a client, publish something and link to someone else. No single organisation needed to know who you were before you could participate.

Over time, we built something different on top of it. Our identities became accounts, our relationships became databases, our conversations became content and our communities became platforms.

Leaving one of those platforms increasingly meant leaving part of our digital lives behind.

Nostr offers another direction. Not because decentralisation is automatically better, or because everyone should run a server at home. Companies, hosted services and large infrastructure can all be useful.

They just shouldn’t be indispensable.

We should be able to change the pieces without losing ourselves.

That is the idea at the heart of Nostr.

§1. Identity should belong to people

An account is something a service gives you. An identity should be something you bring with you.

When identity belongs to a platform, that platform sits between you and everyone you interact with. It can suspend your account, change the rules, close the service, sell the business or simply disappear. Your existence within that network depends on its continued permission.

Nostr starts somewhere else: with keys and signatures.

Your keys let you sign information. Applications and services can verify those signatures without consulting some organisation that originally issued your account, because there doesn’t need to be one.

That changes the relationship between people and software. An application can recognise you without owning your identity.

It can serve you without defining you.

§2. Applications should be replaceable

Imagine discovering a better social client tomorrow.

Normally, changing platforms means rebuilding everything. Create another account. Find people again. Convince friends to move. Recreate your profile. Leave years of activity behind.

The cost of changing software has very little to do with the software itself.

Protocols can change that.

A new Nostr application does not necessarily begin with an empty network. It can recognise existing identities and understand events created elsewhere. A developer can build a different interface to an existing ecosystem rather than first having to create another enclosed one.

That means applications can compete more directly on what they are supposed to be good at: software.

If someone builds something better, people should be able to use it.

§3. Servers should be infrastructure, not authorities

There is nothing wrong with large infrastructure.

A professionally operated relay serving millions of people may be considerably more useful than thousands of unreliable ones. Decentralisation should not become an excuse for making things slower, harder or less dependable.

What matters is what happens when that relay disappears, changes its policies or stops serving your needs.

If another can take its place without taking your identity with it, its size was never the problem.

Different relays can serve different purposes, communities and policies. One may be public, another private. Some may charge. Some may specialise. Some will disappear.

None needs to become the source of a person’s identity.

Centralisation can be useful. Dependency is the greater danger.

§4. Publishing should not require permission

Much of today’s internet begins with the same instruction: create an account.

Before publishing, participating or sometimes even reading, we establish a relationship with a database controlled by somebody else.

Nostr offers a different primitive. Create an event, sign it and publish it. Other participants decide whether they want to store it, display it, respond to it or ignore it.

This does not eliminate rules, nor should it.

Relays can establish policies. Communities can moderate themselves. Clients can filter aggressively. People can block others. Services can charge money. Private systems can remain private.

Permissionless does not mean ruleless.

It means those rules do not have to come from one universal authority.

§5. Interoperability should be ordinary

We have become accustomed to celebrating when an application lets us export our own data.

That is useful, but it reveals something strange about the architecture we have accepted. The application possesses the information first and grants us a mechanism to retrieve it afterwards.

Open APIs improve things, but APIs still tend to define a relationship between a provider and everyone who wants access to that provider.

Protocols create a different relationship.

Two applications that understand the same conventions can interact with the same information without one application needing to grant the other privileged access.

They do not need to agree about everything. They do not need identical interfaces, business models or communities. Nostr itself benefits from experimentation precisely because different applications can interpret and present the network differently.

Interoperability should not be remarkable.

It should be ordinary.

§6. Preserve the exit

“Decentralised” has become an imprecise word. A system can contain thousands of servers and still leave people dependent on a handful of organisations.

There is a simpler test:

Can I leave?

Can I change applications without becoming someone new? Can I use another relay? Can I republish information elsewhere? Can I run infrastructure myself if I want to? Can another implementation understand what I created? Can someone build an alternative without asking an incumbent for permission?

No system will make every form of migration effortless. Data can disappear. Applications can use different conventions. Networks develop dependencies of their own.

The objective is not magical portability.

It is to avoid designing captivity into the architecture.

A healthy system provides more than an entrance. It preserves the possibility of exit.

§7. Leave room for the unexpected

There is a temptation, when designing protocols, to design the future at the same time.

Nostr began with relatively few concepts: keys, events, signatures and relays. What could be built from those concepts turned out to be considerably broader than a single social application.

Messaging appeared. Long-form publishing appeared. Payments, communities, remote signing and other uses followed. More will be tried, and many will fail.

That is healthy.

Some conventions will disappear. Some NIPs will become widely adopted. Others will remain experiments or be replaced by something better.

Protocols should provide enough structure for people to understand one another without attempting to prescribe every application that may someday exist.

The unexpected uses are part of the point.

§8. Nostr is not a social network

Social networking was an obvious place to start, but it should not define the boundary of our imagination.

At its core, Nostr provides a way to exchange signed information through infrastructure that does not have to own the identity of the sender.

A signed event can be a social post, but there is nothing inherently social about it. It might represent an article, message, payment request, software release, authorisation, website, membership, configuration or approval.

Or something we have not thought of yet.

This distinction matters.

If we think of Nostr primarily as a social network, we judge it against social platforms and ask whether it can reproduce their features.

If we think of it as a protocol for signed information, the question becomes much larger:

What no longer needs a platform in the middle?

§9. Machines can participate too

The internet is increasingly populated by software acting on behalf of people. Agents perform tasks, applications request actions, devices communicate and servers make decisions automatically.

We currently handle much of this through a growing collection of service accounts, API keys, OAuth tokens, access credentials and proprietary authentication systems.

Signed events suggest another useful model.

A person can have keys. So can a service, device or agent. Each can make statements or requests whose origin can be independently verified.

That does not mean every participant receives the same authority. Quite the opposite.

An agent might be allowed to request an action while a person must approve it. A device might be trusted to report its state but not change another system. A service might receive authority for one narrow purpose.

Identity, authority and capability are different things.

As software becomes more autonomous, maintaining that distinction will become more important, not less.

§10. Complexity is an engineering problem

For decades, one answer to dissatisfaction with centralised services has been to run the alternative yourself.

For most people, that has been terrible advice.

Running a service could mean installing Linux, configuring a web server, managing certificates, opening ports, maintaining databases, configuring backups, monitoring security and eventually reading logs to discover why something broke at 2 am.

People chose hosted services for good reasons.

But the complexity of self-hosting is not a law of nature.

Deployment can be automated. Certificates can renew themselves. Backups can be checked. Systems can update themselves. Interfaces can explain what is happening, and increasingly capable software can diagnose and resolve problems on a person’s behalf.

The goal should not be to turn everyone into a system administrator.

It should be to make controlling your own infrastructure an ordinary option.

Complexity is not an argument for centralisation. It is an engineering problem.

§11. Convenience and control can coexist

An open network does not require everyone to operate everything themselves.

People should be able to pay someone else to operate a relay, signer, website, storage service or application. Professional infrastructure can be faster, safer and more reliable than something running under a desk.

The distinction is not self-hosted versus hosted.

It is whether choosing convenience also creates dependency.

A good hosted service should win because it provides a good service, not because leaving it would destroy your identity or disconnect you from everyone you know.

Use the convenient service today.

Run your own tomorrow.

Move to a competitor next year.

The architecture should not care.

§12. Do not rebuild what we escaped

Every successful ecosystem develops centres of gravity.

A relay may become dominant. A client may become the default. An index may become enormously influential. A hosting provider may serve most users. A particular implementation may become infrastructure that everyone assumes will always exist.

That is not necessarily a failure of decentralisation. Popular things are often popular because they work.

The more important question is what happens when they stop working.

Can another relay take over?

Can another client interpret the network?

Can another implementation be built?

Can people move?

If the answer remains yes, concentration does not have to mean capture.

If the answer becomes no, we have started rebuilding the systems we intended to escape.

Nostr does not need perfect decentralisation.

It needs credible alternatives.

§Keep the network

Nostr will change.

Applications will come and go. Relays will disappear. Today’s conventions will evolve. Projects that seem important now may be forgotten, and things nobody has built yet may become essential.

That is not failure.

An open system should be able to lose individual pieces without losing itself.

Identity should survive applications. Communities should be able to choose their own rules. Developers should be able to build without asking incumbents for permission. Convenient services should be usable without becoming permanent dependencies.

And leaving should not mean starting again.

The measure of an open system is not how many servers it has or how often it calls itself decentralised.

It is how much permission is required to participate, build, move and leave.

Own your identity. Choose your infrastructure. Change your software. Keep your network.

The internet should not have owners.

It should have participants.