You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: DIDS-DRIVES-ROUTING.md
+25-11Lines changed: 25 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ Atomic Data is moving away from a fixed "main drive" at the root `/` of a server
6
6
## Core Concepts
7
7
8
8
### 1. Identity vs. Alias
9
-
-**Identity (Immutable)**: A Drive is identified by its DID: `did:ad:{genesis}?drive={hash}`.
9
+
-**Identity (Immutable)**: A Drive is identified by its DID: `did:ad:{genesis}`.
10
10
-**Alias (Mutable)**: A Domain or Subdomain (e.g., `joep.atomicdata.dev`, `localhost:9883`) is an alias that routes to a specific Drive DID.
11
11
12
12
### 2. Agent-First Onboarding
@@ -21,30 +21,44 @@ The server uses the HTTP `Host` header to determine which Drive to serve:
21
21
-`jane.atomicdata.dev` -> Serves Jane's Drive.
22
22
-`localhost:9883` -> Serves the developer's default Drive.
23
23
24
+
### 4. Custom Path Routing
25
+
Human-readable access to resources within a Drive is handled via two strategies:
26
+
-**Flat Slugs**: If a resource has a `https://atomicdata.dev/properties/path` property (e.g., `path: "/my-blog-post"`), it is served directly at that URL relative to the Drive's domain.
27
+
-**Hierarchical Fallback**: If no explicit `path` is found, the server traverses the hierarchy using `PARENT` and `shortname` properties (e.g., `/folders/2026/note`).
28
+
24
29
---
25
30
26
31
## Implementation Phases
27
32
28
33
### Phase 1: Backend Routing & Mapping
29
-
-[]**Mapping Store**: Implement a mechanism in `atomic-server` to store and query `Host -> Drive DID` mappings.
30
-
-[]**Host-Based Resolution**: Update the HTTP request handler to check the `Host` header.
31
-
-[]**Relative Pathing**: Ensure that paths like `/classes` are correctly resolved relative to the Drive DID mapped to the current Host.
34
+
-[x]**Mapping Store**: Sled `drive_mapping` tree in `lib/src/db.rs` — `add_drive_mapping` / `get_drive_did`.
35
+
-[x]**Host-Based Resolution**: `appstate.rs::get_drive_did_for_host` — checks explicit mapping, falls back to subdomain query.
36
+
-[x]**Relative Pathing**: `db.rs::get_resource_at_path` — traverses hierarchy relative to a Drive DID; supports both flat `path` lookups and hierarchical fallback.
32
37
33
38
### Phase 2: Drive Lifecycle & Population
34
-
-[]**Standard Initialization**: Refactor `atomic_lib::populate` so it can be applied to any Drive DID (creating `/classes`, `/tags`, etc. within that drive).
35
-
-[]**Drive Resource**: Ensure the Drive resource itself contains the necessary metadata (Drive Public Key, Hash, Owner).
39
+
-[x]**Standard Initialization**: `atomic_lib::populate::bootstrap` is drive-agnostic and reusable.
40
+
-[x]**Drive Resource metadata**: `OnboardingPage.tsx` creates the genesis drive with `write` and `read` set to the agent's DID.
36
41
37
42
### Phase 3: Server Setup & Onboarding UI
38
-
-[ ]**Node Setup State**: Detect when a server has no mappings and enter "Setup Mode".
39
-
-[ ]**Setup UI**: A dedicated frontend flow for creating an Agent and the first Drive.
40
-
-[ ]**Alias Registration**: A secure way for the first Agent to "claim" the server's primary domain.
-[x]**Setup UI**: `OnboardingPage.tsx` — generate agent keypair → genesis drive commit → set `INITIAL_DRIVE` on root → show secret.
45
+
-[x]**Alias Registration**: `handlers/commit.rs` — after commit, if new resource has `INITIAL_DRIVE` set, calls `store.add_drive_mapping(host, drive_did)` using the `Host` header.
46
+
-[x]**Authorization during onboarding**: `handlers/commit.rs` allows unauthenticated writes to `INITIAL_DRIVE` only when the specific host is uninitialized.
41
47
42
48
### Phase 4: Decentralized Discovery
43
-
-[ ]**JSON-AD Headers**: Include the true `did:ad` identity in HTTP responses so clients can switch to P2P resolution.
44
-
-[ ]**DHT/Reticulum Announces**: Servers announce the Drive hashes they host to the P2P networks.
49
+
-[x]**JSON-AD Headers**: Added `Link: <did:ad:...>; rel="canonical"` response header in `handlers/get_resource.rs` for DID subjects.
50
+
-[x]**DHT/Reticulum Announces**: `dht.rs` — periodic `announce_peer(SHA1(drive_did))` every 15 min; DHT fallback resolution in `get_resource.rs`.
51
+
-[x]**Explicit Subdomains**: `Subject::Internal` explicitly stores subdomains for reliable multi-tenant routing.
45
52
46
53
---
47
54
55
+
## What to work on next (priority order)
56
+
57
+
1.**Path Uniqueness Validation** — ensure that two resources in the same Drive cannot share the same `path` property during `commit` validation.
58
+
2.**Drive-Scoped Search** — update the search endpoint to respect the resolved Drive DID so results are filtered by the current "Tenant".
59
+
3.**End-to-end test** — write a server integration test that exercises the full onboarding flow: fresh DB → `isUninitialized` → genesis drive commit → `INITIAL_DRIVE` commit → drive mapping → resource resolution.
60
+
4.**Reticulum Pathfinding** — implement the binary announce/resolution logic for `did:ad` over the Reticulum mesh.
61
+
48
62
## Success Criteria
49
63
1. Running `atomic-server` for the first time leads to an Agent/Drive creation flow.
50
64
2. Multiple drives can be accessed via subdomains on the same server instance.
0 commit comments