change spec to use human readable DID for univ_id

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:<name>:<uuidv7>`.  
 
 ## 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:<name>:<uuidv7>
+```
 
-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
+- `<name>` - UTF-8 encoded universe name (any length)
+- `<uuidv7>` - 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:<name>:<uuidv7>`
+- 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@…"],