Nostr: Decentralised by Design

The problem with platforms

• Accounts, contacts and message history are locked inside one provider’s platform.
• A single outage, policy change or block can silence an organisation’s communication.
• Users must trust the server not to read, alter or fabricate messages.
• Integrating partners means building one-off connections to each of their systems.
• Signatures and approvals depend on proprietary services that are hard to verify independently.

Keys are identity

A Nostr identity is a key pair on the secp256k1 elliptic curve, the same cryptography that secures Bitcoin. The public key, usually shown in the npub format, is your identity: anyone can see it and use it to verify what you sign. The private key, the nsec, proves that you are you, and is the only thing that must be protected.

Because identity is a key, not an account, it works in every Nostr application and cannot be suspended by a server. Keys can be linked to a readable address on your own domain, such as finance@company.om, so partners can see that a key really belongs to your organisation. In the enterprise, private keys live in a secure signer or hardware module rather than on employees’ devices.

Signed events

Everything in Nostr is an event: a small JSON object with the author’s public key, a timestamp, a kind that says what the event is, tags that link it to other events, people or references, and the content itself. The event’s id is the SHA-256 hash of all of these fields, and the author signs that id with a Schnorr signature.

The result is a self-verifying record. Any client can recalculate the id and check the signature using only the public key, without asking a server. Change a single character and both the id and the signature break. The demonstration below generates a real key pair and signs a real event in your browser.

{
  "content": "Press “Sign event”…"
}

Relays

Relays are the servers of Nostr, and they are deliberately simple. A client connects over a WebSocket, sends events to publish them, and sends subscriptions, filters such as “events of these kinds by these authors since yesterday”, to receive matching events as they arrive. Relays do not talk to each other and do not need to agree on anything.

Clients usually publish to several relays and read from several. Each user announces their preferred relays in a public list, so others know where to find them. If a relay is slow, full or offline, the same signed events are available elsewhere. Relays can also set their own policies: who may write, who may read, how long data is kept and what it costs, which is what makes private enterprise relays possible.

The protocol, in NIPs

Nostr is specified in Nostr Implementation Possibilities, or NIPs: short, public documents that each define one feature. Clients and relays implement the NIPs they need, and announce which ones they support. These are the ones that matter most for organisations.

Delivery roadmap

1. Discovery

   2 weeks

   Identify the conversations, approvals and partner exchanges where independence and verifiability matter most.

2. Foundation

   3–4 weeks

   Deploy private relays, the remote signer and organisation identities, and connect them to SBC ERP.

3. First product

   4–8 weeks

   Roll out secure messaging or signed approvals to a pilot group and their partners.

4. Scale

   Ongoing

   Add partners, groups and use cases on the same infrastructure, with 24/7 operation and support.

Business outcomes

• Communication that keeps working when any single server or provider fails.
• Identities and history owned by the organisation, portable across applications.
• Approvals and signatures that anyone can verify, years later, without a central service.
• Partners connected through one open protocol instead of many custom integrations.
• Lower cost and no lock-in, on infrastructure you can run yourself.