From 5eea31a25d5f8d6c134b1b83f8d870d915785c11 Mon Sep 17 00:00:00 2001 From: Continuist Date: Wed, 15 Oct 2025 00:17:12 -0400 Subject: [PATCH] change spec to use human readable DID for univ_id --- sharenet_spec.md | 87 +++++++++++++++++++++++++----------------------- 1 file changed, 46 insertions(+), 41 deletions(-) diff --git a/sharenet_spec.md b/sharenet_spec.md index 07de6ae..0f65349 100644 --- a/sharenet_spec.md +++ b/sharenet_spec.md @@ -8,7 +8,7 @@ This protocol assumes three fundamental building blocks in addition to Cards: - **Passports**: User-held identifiers derived from cryptographic seeds. - **Hubs**: Servers that maintain membership, relay Cards, and enforce network policies. -- **Universes**: Collections of hubs and users defined by a shared Genesis Document. +- **Universes**: Collections of hubs and users defined by a shared self-describing universe identifier. ## 2. Terminology @@ -24,8 +24,8 @@ This protocol assumes three fundamental building blocks in addition to Cards: - **Permanent public Card**: A Card with no encryption and no revocation path. Immutable. - **Passport**: A user-held self-sovereign identifier derived from a mnemonic seed. - **Hub**: A server implementing this protocol and providing membership and relay functions. -- **Universe**: A collection of hubs and users sharing a Genesis Document. -- **Genesis Document**: Immutable initial configuration defining a universe. +- **Universe**: A collection of hubs and users sharing a self-describing universe identifier. +- **Universe Identifier (univ_id)**: A human-readable DID that encodes both a human-readable name and unique identifier in the format `u::`. ## 3. Cards @@ -194,17 +194,31 @@ Hubs MAY maintain federations to decide forwarding scopes. ## 13. Universes -### 13.1 Genesis Document -Each universe begins with a **Genesis Document** that defines: +### 13.1 Universe Identifier (univ_id) +Each universe is identified by a **human-readable DID** that encodes both a human-readable name and a unique identifier. -- `univ_id`: Unique universe identifier. -- `genesis_ts`: Timestamp of creation. -- `founders`: (Optional) Initial hub and user DIDs. -- `bootstrap_caps`: Minimal capability set expected for participation. May be overcome by events. -- `initial_policies`: Distribution and trust defaults. +**Format:** +``` +u:: +``` -The Genesis Document is signed by the founders and distributed to all participants. -It MUST be immutable. Any update creates a **new universe**. +**Components:** +- `u:` - Prefix identifying this as a universe identifier +- `` - UTF-8 encoded universe name (any length) +- `` - UUIDv7 identifier (RFC 4122 format) + +**Constraints:** +- The name MUST be a valid UTF-8 string +- Special characters in the name SHOULD be URL-encoded if they conflict with the format +- The UUIDv7 MUST be generated according to RFC 4122 +- The entire string MUST be treated as case-sensitive + +**Example:** +``` +u:Test Universe:018f1234-5678-90ab-cdef-123456789abc +``` + +The `univ_id` is used directly for passport creation and universe identification. No separate Genesis Document is required. ### 13.2 Participation - Users MAY join multiple universes. @@ -464,7 +478,7 @@ Roles MAY be declared in Hub metadata and MAY guide peer selection. ### 24.2 Federations - A federation is a locally defined list of hubs considered trustworthy by a given hub. - Federations MAY be defined by DID, fingerprint, or signed config. -- Federations MUST be rotatable without changing the Genesis Document. +- Federations MUST be rotatable without changing the universe identifier. - Distribution rules (e.g. “federation”) are enforced using federations. ### 24.3 Rotation @@ -504,34 +518,25 @@ A membership Verifiable Credential (VC) MUST contain: - Check the VC’s signature, validity window, and status list entry. - Historical Cards MUST remain valid if the VC was active at the time of creation. -## 26. Universe Genesis, Publication, and Forks +## 26. Universe Creation and Identification -### 26.1 Canonical Genesis -- The Genesis Document MUST be encoded in canonical CBOR. -- The `univ_id` is computed as `SHA-256` of the canonical bytes. -- Genesis MUST include: - - `univ_id`, `genesis_ts`, founders (hub/user DIDs), bootstrap capabilities, and policies. -- Genesis is immutable. Any change results in a new `univ_id` and thus a new universe. +### 26.1 Universe Identifier Generation +- A universe is created by generating a **human-readable DID** +- The format MUST be: `u::` +- The name MUST be a valid UTF-8 string (any length) +- The UUIDv7 MUST be generated according to RFC 4122 +- Special characters in the name SHOULD be URL-encoded -### 26.2 Multi-Signature Policy -- Genesis SHOULD be co-signed by multiple founders. -- Minimum signature threshold MUST be specified (e.g., 2-of-3). -- Verifiers MUST reject Genesis docs without sufficient signatures. +### 26.2 Name Extraction +- Given any valid `univ_id`, the human-readable name MUST be extractable +- Implementations MUST parse the format to retrieve the name for display +- The name is permanently embedded and cannot be changed +- URL-encoded characters MUST be decoded when extracting the name -### 26.3 Publication Channels -- Genesis MAY be published via: - - Static files. - - Peer-to-peer distribution. - - Content-addressed storage (IPFS, Git, etc.). - -### 26.4 No-Tombstone Rule -- Once published, a Genesis Document MUST NOT be deleted. -- Universes have permanence; dissolution only occurs if all peers stop participating. - -### 26.5 Fork Handling -- If conflicting successor Genesis docs appear, each creates a distinct new `univ_id`. -- Participants MAY choose which fork to join. -- Forks MUST NOT silently overwrite each other. +### 26.3 Uniqueness and Independence +- Each `univ_id` is globally unique due to the UUIDv7 component +- There is no concept of "forks" since each universe is independent +- Participants MAY join any universe by its `univ_id` --- @@ -789,7 +794,7 @@ Implementations MUST validate against these vectors to ensure interoperability. ``` ### 35.3 Issuers -- Bulletins MAY be issued by capability authors, universe founders, or hub operators. +- Bulletins MAY be issued by capability authors or hub operators. - Clients MUST verify the issuer’s signature against a trusted keyring. ### 35.4 Client Behavior @@ -837,7 +842,7 @@ Implementations MUST validate against these vectors to ensure interoperability. { "ver": 1, "type": "card", - "univ": "univ:prod:z9…", + "univ": "u:Production Universe:018f1234-5678-90ab-cdef-123456789abc", "rid": "0x12b…", "ts": 1738123456, "reqs": ["cap:card/v1@…"], @@ -858,7 +863,7 @@ Implementations MUST validate against these vectors to ensure interoperability. { "ver": 1, "type": "card", - "univ": "univ:prod:z9…", + "univ": "u:Production Universe:018f1234-5678-90ab-cdef-123456789abc", "rid": "0x44a…", "ts": 1738126789, "reqs": ["cap:card/v2@…","cap:hpke-x25519-xc20p@…"],