Nostr basics

Why a construction project cares

Coordination today lives inside a platform. When the contract ends, the subscription lapses or the vendor pivots, the record of who delivered which model and who approved which issue is trapped or gone. A building lasts fifty years; the platform does not. Nostr decouples the record from the application: the signed event is portable, independently verifiable, and survives any single tool or host. That is the one missing layer openBIM never standardised — and all BIM-CVP adds.

The keypair

The cryptography is Schnorr signatures over secp256k1, a widely used public-key signature scheme. That causes a recurring misunderstanding: Nostr is not a blockchain, not a token, not a payment. It borrows one well-audited signature scheme and nothing else. The npub/nsec strings are just the raw keys in a human-checkable encoding (bech32, NIP-19).

The event

Every Nostr message has the same shape:

{
  "id":      "<sha256 of the serialised event>",
  "pubkey":  "<author public key, hex>",
  "created_at": 1747000000,
  "kind":    1063,                 // what type of thing this is
  "tags":    [ ["x","<sha256>"], ["m","application/x-step"] ],
  "content": "<free text or JSON payload>",
  "sig":     "<Schnorr signature over id>"
}

• kind — an integer that decides how the event is interpreted. Ranges matter: 1 is a note, 1063 is file metadata (NIP-94), 30000–39999 are addressable events (replaceable by a d tag — how a "current version" works).
• tags — structured indexable fields. This is where standard data is carried (file hash, schema, project reference, ISO 19650 state).
• id + sig — tamper-evidence. Change one byte and the id no longer matches; forge nothing without the private key.

Relays

A relay is a small server that accepts signed events and serves them over a websocket on request. Relays do not own identity and do not authenticate accounts — they store and filter. You publish the same event to several relays; readers subscribe to whichever they trust. If one relay disappears, the record still exists on the others (the "outbox" pattern). BIM-CVP can use project relays plus public fallbacks.

Signing — and why we never touch your nsec

Signing must happen where the private key lives, never in our page. A NIP-07 browser signer (a wallet extension) exposes only two calls to a web app:

window.nostr.getPublicKey()        // returns your npub-derived pubkey
window.nostr.signEvent(event)      // returns the event with a valid sig

The site builds the unsigned event, hands it to the signer, gets back a signed event, and publishes it. The nsec never enters the page, the network, or server logs. Key backup belongs to the signer or the project key policy, not to a web page that happens to create an event.

The NIPs BIM-CVP relies on

How a BCF issue becomes an event

A BCF topic, comment and viewpoint map onto signed addressable events; the snapshot and any attached file ride along as NIP-94 file events referenced by hash. The full field-by-field mapping has its own page — the point here is only that nothing in BCF or IFC is reinvented; it is carried, signed, and made portable.

In BIM-CVP, this same mechanism signs project setup, file references, BCF topics, comments, validation results and approvals. The event stays small; the IFC, BCFZIP, IDS report or snapshot stays a normal file referenced by hash.

Practical pitfalls

• nsec in a text box. Never. If a site asks you to paste an nsec, it is wrong. Use a NIP-07 signer.
• One relay only. Single point of failure. Always publish to several.
• Losing the key. Key backup and recovery must be explicit project policy, not an afterthought.
• Confusing Nostr with crypto-currency. Shared signature math, nothing else. No chain, no token required to use BIM-CVP.

Sources

• Nostr Implementation Possibilities (NIPs)
• NIP-01 — basic protocol
• NIP-07 — browser signing
• NIP-94 — file metadata