refactor: update dependencies and remove unused code

- Added new dependencies: `adler2`, `crc32fast`, `flate2`, `miniz_oxide`, and `libredox`.
- Updated existing dependencies: `tokio-rustls` to version 0.26.4 and `filetime` to version 0.2.27.
- Removed the `backup.rs` file as it is no longer needed.
- Introduced tests for configuration and credential management.
- Enhanced the `identity` module to generate W3C compliant DID documents.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/adr/001-podman-over-docker.md

@@ -0,0 +1,32 @@
+# ADR-001: Podman Over Docker
+
+**Status**: Accepted
+**Date**: 2026-03
+
+## Context
+
+Archipelago needs a container runtime for running applications. Docker and Podman are the two main options.
+
+## Decision
+
+Use Podman as the container runtime instead of Docker.
+
+## Consequences
+
+### Positive
+- **Rootless by default**: Containers run without root privileges, reducing attack surface
+- **Daemonless**: No persistent daemon process; containers are managed as individual processes under systemd
+- **Docker-compatible**: Supports Docker images and most Docker CLI commands
+- **Systemd integration**: Podman containers can be managed as systemd services natively
+- **No vendor lock-in**: OCI-compliant, works with any container registry
+
+### Negative
+- **Smaller ecosystem**: Some Docker-specific tools and compose features require adaptation
+- **Docker Compose differences**: Podman Compose exists but has occasional compatibility gaps
+- **Documentation**: Most container documentation assumes Docker; developers need to translate
+- **Networking**: Podman networking (CNI/netavark) differs from Docker's bridge networking
+
+### Mitigation
+- Use `podman` CLI wrapper that provides Docker-compatible interface
+- Document Podman-specific commands in developer guide
+- Use `archy-net` custom network for inter-container DNS

docs/adr/002-did-key-method.md

@@ -0,0 +1,31 @@
+# ADR-002: DID Key Method for Node Identity
+
+**Status**: Accepted
+**Date**: 2026-03
+
+## Context
+
+Each Archipelago node needs a cryptographic identity for peer authentication, federation, and verifiable credentials. Multiple DID methods exist (did:web, did:ion, did:key, did:peer).
+
+## Decision
+
+Use `did:key` as the primary DID method.
+
+## Consequences
+
+### Positive
+- **Self-contained**: The DID document is derived entirely from the public key — no external resolution needed
+- **Offline-capable**: Works without internet, aligning with sovereignty principles
+- **Simple**: No registration, no blockchain, no web server required
+- **Fast**: DID resolution is a local computation, not a network request
+- **Ed25519**: Uses Ed25519 keys which are fast, compact, and well-supported
+
+### Negative
+- **No key rotation**: The DID is bound to a single key; rotating requires a new DID
+- **No service endpoints in DID**: Cannot embed service URLs in the DID document itself
+- **No revocation**: Cannot revoke a did:key without out-of-band mechanisms
+
+### Mitigation
+- Use federation trust lists for key management and revocation
+- Store service endpoints (onion address, pubkey) separately in federation state
+- Support migration to did:peer or did:web in future versions if key rotation is needed

docs/adr/003-nostr-for-discovery.md

@@ -0,0 +1,35 @@
+# ADR-003: Nostr Relays for Node and App Discovery
+
+**Status**: Accepted
+**Date**: 2026-03
+
+## Context
+
+Archipelago nodes need to discover peers and community apps without a central registry. Options: custom P2P protocol, DHT, BitTorrent tracker, Nostr relays, IPFS.
+
+## Decision
+
+Use Nostr relays (NIP-78, kind 30078) for both node discovery and marketplace app manifests.
+
+## Consequences
+
+### Positive
+- **Decentralized**: Multiple independent relays; no single point of failure
+- **Existing infrastructure**: Thousands of Nostr relays already running globally
+- **Censorship-resistant**: If one relay censors, others still serve events
+- **Simple protocol**: WebSocket + JSON — easy to implement without heavy dependencies
+- **Key management**: Nostr uses secp256k1, same curve as Bitcoin — natural fit
+- **NIP-33 replaceable events**: Latest event replaces previous — clean update model
+- **Tor-compatible**: WebSocket over Tor SOCKS proxy works natively
+
+### Negative
+- **Relay availability varies**: Some relays may be down or rate-limited
+- **No guaranteed persistence**: Relays may prune old events
+- **Spam potential**: Open publishing means anyone can publish junk manifests
+- **Latency**: Querying multiple relays adds latency to discovery
+
+### Mitigation
+- Query multiple relays in parallel; deduplicate results
+- Cache results locally with 15-minute TTL
+- Use trust scoring to rank manifests (DID verification, relay consensus, federation trust)
+- Use hashtag filtering (`archipelago-marketplace`) to narrow queries

docs/adr/004-tor-for-peer-communication.md

@@ -0,0 +1,35 @@
+# ADR-004: Tor Hidden Services for Peer Communication
+
+**Status**: Accepted
+**Date**: 2026-03
+
+## Context
+
+Federated nodes need to communicate directly for state sync, app deployment, and peer verification. Options: direct IP, VPN tunnel, Tor hidden services, I2P.
+
+## Decision
+
+Use Tor hidden services (.onion addresses) for all inter-node communication.
+
+## Consequences
+
+### Positive
+- **NAT traversal**: Works behind any firewall or NAT without port forwarding
+- **IP privacy**: Nodes never expose their real IP addresses to each other
+- **End-to-end encryption**: Tor provides encryption without additional TLS setup
+- **Censorship resistance**: Onion routing makes traffic analysis difficult
+- **Stable addressing**: .onion addresses persist across IP changes and network migrations
+- **No central infrastructure**: No VPN server, STUN/TURN server, or relay needed
+
+### Negative
+- **Latency**: Tor adds 200-500ms per hop; 3 hops per direction = noticeable delay
+- **Bandwidth**: Tor network has limited bandwidth; not suitable for bulk data transfer
+- **Reliability**: Tor circuits can break; connections may need retry logic
+- **Setup complexity**: Requires running a Tor daemon (`archy-tor` container)
+- **Blocked networks**: Some networks block Tor; bridges can help but add complexity
+
+### Mitigation
+- Use Tor only for RPC/control plane; bulk data (container images) pulled from registries
+- Implement retry with backoff for Tor connections
+- Container `archy-tor` runs automatically with host networking for hidden service access
+- Federation sync interval (5 min) tolerates occasional connection failures

docs/adr/005-chacha20-backup-encryption.md

@@ -0,0 +1,32 @@
+# ADR-005: ChaCha20-Poly1305 for Backup Encryption
+
+**Status**: Accepted
+**Date**: 2026-03
+
+## Context
+
+Backups contain sensitive data (keys, credentials, app state) and must be encrypted at rest. Options: AES-256-GCM, ChaCha20-Poly1305, XChaCha20-Poly1305.
+
+## Decision
+
+Use ChaCha20-Poly1305 (AEAD) with Argon2id key derivation for backup encryption.
+
+## Consequences
+
+### Positive
+- **Software performance**: ChaCha20 is faster than AES on hardware without AES-NI (common on ARM/SBCs)
+- **Constant-time**: No timing side channels, unlike some AES implementations
+- **AEAD**: Authenticated encryption ensures both confidentiality and integrity
+- **Widely audited**: Used in TLS 1.3, WireGuard, and Signal Protocol
+- **Simple implementation**: No padding, no CBC/CTR mode complexity
+- **Argon2id KDF**: Memory-hard key derivation resists GPU/ASIC brute force attacks
+
+### Negative
+- **96-bit nonce**: Must ensure nonce uniqueness per encryption (random generation with collision check)
+- **Not FIPS-certified**: Some enterprise environments require AES (not relevant for personal nodes)
+- **Less hardware acceleration**: AES-NI on x86 can make AES faster on desktop CPUs
+
+### Mitigation
+- Generate random nonce per backup; store nonce alongside ciphertext
+- Argon2id with high memory cost (64MB) and iterations (3) for password-to-key derivation
+- Target hardware is mixed x86/ARM; ChaCha20's consistent performance is an advantage