archy/docs/adr/011-dwn-deprioritization.md

# ADR-011: DWN Deprioritization

## Status

Accepted

## Context

TBD/Block shut down in November 2024, donating Web5 code to the Decentralized Identity Foundation (DIF). The DWN (Decentralized Web Node) specification was heavily backed by TBD — without their engineering team, the spec has lost momentum:

- No maintained Rust DWN SDK exists (the `dwn` crate by unavi-xyz is v0.4.0 with 323 downloads)
- TBD's reference implementation was TypeScript-only
- DIF has not allocated resources to continue DWN development
- The spec itself is complex (personal data stores with protocol-based access control)

Meanwhile, Archipelago's federation over Tor + Nostr relays already serves the core peer data sync use case that DWN was intended for.

## Decision

1. **Keep existing DWN store code** in `core/archipelago/src/network/dwn_store.rs` — it works for peer file catalogs and federation state
2. **Stop calling it "Web5 DWN"** in user-facing text — it's our custom implementation, not a full DWN spec implementation
3. **Do not invest in DWN spec compliance** — the spec is stalled and may not stabilize
4. **Prioritize Nostr + federation** for peer discovery and data exchange
5. **Re-evaluate if DIF produces a viable Rust SDK** or the spec gains new maintainers

## Consequences

- DWN functionality remains available but is not actively developed
- Peer sync uses federation + Nostr instead of DWN protocols
- Reduces maintenance burden — no need to track a stalled spec
- If DWN resurfaces with strong tooling, we can adopt it later
release(v1.7.41-alpha): post-OTA auto-rollback so a bad release cannot strand the fleet Closes failure mode FM5 from docs/bulletproof-containers.md: the v1.7.38 + v1.7.39 rollouts left every affected node on an unreachable UI (nginx 500) with no recovery path short of SSH. This release adds a self-check guardrail to the update flow. What changed: - apply_update() writes a pending-verify marker with old+new version and a 150s deadline immediately before scheduling the service restart. - verify_pending_update() runs from main.rs startup. If the marker is present and within its freshness window, the new binary waits 15s for nginx + backend to settle, then probes https://127.0.0.1/ every 5s for up to 90s (self-signed certs accepted). - On any probe success within the window, the marker is cleared and nothing else happens. - On window-exhaust, the new binary: 1. Moves the broken /opt/archipelago/web-ui to web-ui.failed.<ts> (quarantined, not deleted, so we can post-mortem). 2. Restores web-ui.bak on top of web-ui. 3. Calls rollback_update() to restore the previous binary. 4. Updates state.current_version to reflect the rollback. 5. systemctl --no-block restart archipelago so the OLD binary boots. - Markers older than 10 minutes are treated as stale and cleared without probing, so a crashed-during-startup marker from weeks ago cannot spontaneously roll back a healthy node on a later reboot. - rollback_update() binary copy now goes through host_sudo instead of tokio::fs::copy, so it escapes the service's ProtectSystem=strict mount namespace. Without this, the rollback silently failed with EROFS on /usr/local/bin and orphaned the rollback - the exact opposite of what auto-rollback is for. Tests: 4 new unit tests in update::tests covering marker round-trip, absent-marker noop, no-panic on verify_pending_update with nothing to verify, and an invariant assert that the 90s probe window stays below the 600s stale threshold. All passing. Side fix: scripts/create-release-manifest.sh was dying with exit 141 (SIGPIPE from tar tvzf pipe head pipe awk) under set -euo pipefail. Replaced with a single awk NR==1 that doesn't short-circuit the upstream pipe, so the release-build flow is idempotent again. 2026-04-22 16:14:35 -04:00			`# ADR-011: DWN Deprioritization`

			`## Status`

			`Accepted`

			`## Context`

			`TBD/Block shut down in November 2024, donating Web5 code to the Decentralized Identity Foundation (DIF). The DWN (Decentralized Web Node) specification was heavily backed by TBD — without their engineering team, the spec has lost momentum:`

			- No maintained Rust DWN SDK exists (the `dwn` crate by unavi-xyz is v0.4.0 with 323 downloads)
			`- TBD's reference implementation was TypeScript-only`
			`- DIF has not allocated resources to continue DWN development`
			`- The spec itself is complex (personal data stores with protocol-based access control)`

			`Meanwhile, Archipelago's federation over Tor + Nostr relays already serves the core peer data sync use case that DWN was intended for.`

			`## Decision`

			1. Keep existing DWN store code in `core/archipelago/src/network/dwn_store.rs` — it works for peer file catalogs and federation state
			`2. Stop calling it "Web5 DWN" in user-facing text — it's our custom implementation, not a full DWN spec implementation`
			`3. Do not invest in DWN spec compliance — the spec is stalled and may not stabilize`
			`4. Prioritize Nostr + federation for peer discovery and data exchange`
			`5. Re-evaluate if DIF produces a viable Rust SDK or the spec gains new maintainers`

			`## Consequences`

			`- DWN functionality remains available but is not actively developed`
			`- Peer sync uses federation + Nostr instead of DWN protocols`
			`- Reduces maintenance burden — no need to track a stalled spec`
			`- If DWN resurfaces with strong tooling, we can adopt it later`