Curve spaces and addresses

A curve is an authority-relative projection of a world. It answers: from this relationship, horizon, locality, and set of accepted roots, which part of the shared system is currently visible or actionable?

The same underlying objects may appear differently from two curves because each observer has different authority, proximity, costs, interests, and trust roots.

What you are looking at

In the cockpit, a curve should read like a projection bus, not a network cable:

world / history / mailbox / pointers
            │
            ▼
      [ CURVE PROJECTOR ]
            │
     projection/v1
            │
            ▼
    relative visible world

Inspect LOCAL CURVE

The curve wire carries projection semantics such as scope, relative path, participant fingerprints when explicitly supplied, view constraints, and the current horizon. It does not imply that a transport session exists.

Address versus identity

An ECC key identifies a participant or lineage. A curve address locates a projection or meeting scope. They are related but never interchangeable:

keys answer:  who signed or may act?
curves answer: from which relative projection are we resolving?

Sharing a curve does not prove identity. Connectivity does not prove membership. Admission evidence must remain explicit.

Curve forms

Local curve

curve:local:<deployment>:<random-local-id>

Created in one browser and admitted only to that browser/origin. It is noncanonical and does not join a default public network.

Relative curve

<current-curve>/<relationship>

A child view such as mailbox-history, project-atlas, or body-nearby. It inherits the current admission boundary unless explicitly bridged.

Meeting curve

curve:meeting:<ordered-participant-fingerprints>:<invitation-nonce>

A deliberately shared projection. Participant fingerprints define intended cryptographic identities; invitation material and capabilities govern admission. Rendezvous machinery may help bodies find each other but cannot become their identity root.

The message on a curve wire

A representative projection/v1 message may expose:

curve id
parent / relative path
scope
participants[]
view constraints
horizon
observation status

This makes the projection itself inspectable. The message is descriptive context, not ambient authority.

Beautiful projection, precise semantics

The cockpit may draw curves as stable circuitry between history, pointers, mailboxes, bodies, and locality territories. The geometry is explanatory rather than a claim of metric distance.

Glowing traffic proves only the observed fact attached to that edge. A curve edge should remain visually distinct from WebRTC/TCP/HTTP carrier edges and from capability/grant wires.

Useful controls include:

• move to a relative child curve;
• create a fresh local curve;
• present an invitation for a meeting curve;
• compare two projections without merging them;
• fork at a chosen cursor horizon;
• export an encrypted bundle reference with attenuated read authority.

What a curve can prove

A curve can establish the projection parameters the cockpit is using. If it carries verified participant fingerprints or invitation evidence, those facts can be shown explicitly.

A curve does not automatically prove:

• that a visible transport peer is one of those participants;
• that a mailbox may be read or written;
• that a referenced cursor may be continued;
• that two projections should be merged.

Fork links and trust

A shared fork link is never presented as the canonical clean cockpit. Before booting, the receiver sees the claimed issuer, release, curve, horizon, and whether private data is embedded or merely referenced.

The current preview creates provenance-only fork links. It does not embed private bytes, private keys, or bearer authority. A future private fork must encrypt bodies, use attenuated capabilities, and preserve the same trust gate.

Continue with Cryptopointers, Mailboxes and Traffic, and Capabilities.