docs: did:dht integration architecture and DWN protocol schemas
- DHT-01: docs/did-dht-integration.md — did:dht spec analysis, DNS packet encoding, mainline crate, publication/resolution flows, security notes - SCHEMA-01: docs/dwn-protocols.md — 4 DWN protocol definitions with JSON schemas: node-identity, file-catalog, federation, app-deploy Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -257,7 +257,7 @@ Every test must pass **10 consecutive times** from BOTH .228→.198 AND .198→.
|
||||
|
||||
### Sprint 9: did:dht Implementation
|
||||
|
||||
- [ ] **DHT-01** — Research and document did:dht integration approach. Study the did:dht spec (uses BitTorrent DHT — Mainline DHT). Document: how to publish DIDs to the DHT, how to resolve them, what library/crate to use (or implement), how it fits alongside existing did:key. Write to `docs/did-dht-integration.md`. **Acceptance**: Architecture document with specific implementation plan.
|
||||
- [x] **DHT-01** — Created `docs/did-dht-integration.md`. Covers: did:dht spec (BEP-44 mutable DHT items), DNS packet encoding, z-base-32 identifiers, publication/resolution flows, `mainline` crate for Rust DHT access, security considerations (no Tor addresses in public DHT), comparison with did:key, new RPC endpoints, background refresh every 2h, integration points with federation/VCs/Web5 UI.
|
||||
|
||||
- [ ] **DHT-02** — Implement did:dht creation in identity_manager.rs. Add `create_dht_did()` method that: (1) generates Ed25519 keypair, (2) creates a DNS packet encoding per did:dht spec, (3) publishes to Mainline DHT using a Rust BitTorrent DHT library (e.g., `mainline` crate). The node should have BOTH did:key (local, offline) and did:dht (discoverable, no server needed). Add `identity.create-dht-did` RPC endpoint. **Acceptance**: Can create a did:dht and resolve it from another machine using the DHT.
|
||||
|
||||
@@ -267,7 +267,7 @@ Every test must pass **10 consecutive times** from BOTH .228→.198 AND .198→.
|
||||
|
||||
### Sprint 10: DWN Protocol Definitions for Interoperable Schemas
|
||||
|
||||
- [ ] **SCHEMA-01** — Define Archipelago DWN protocol schemas. Create protocol definitions for the data types Archipelago shares between nodes: (1) Node identity announcements, (2) File sharing catalogs, (3) Federation state, (4) App deployment requests. Use the DWN protocol definition format so other apps implementing DWN could read Archipelago data. Document in `docs/dwn-protocols.md`. **Acceptance**: 4 protocol definitions documented with JSON schemas.
|
||||
- [x] **SCHEMA-01** — Created `docs/dwn-protocols.md` with 4 protocol definitions: (1) Node Identity Announcements (node-identity/v1) — public, node DID/version/apps/capabilities. (2) File Sharing Catalog (file-catalog/v1) — public, file entries with access levels/pricing. (3) Federation State (federation/v1) — private, membership + peer status with trust levels. (4) App Deployment Requests (app-deploy/v1) — private, request/response for remote app install. All with JSON schemas, DWN protocol definition format, and interoperability notes.
|
||||
|
||||
- [ ] **SCHEMA-02** — Register Archipelago protocols in DWN on both nodes. On startup, the backend should auto-register all 4 Archipelago protocols via `dwn.register-protocol`. Verify protocols are registered on both .228 and .198. **Acceptance**: `dwn.list-protocols` on both nodes shows all 4 Archipelago protocols.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user