Bootstrap geth Rust workspace

docs/adr/0000-project-goals.md

@@ -0,0 +1,18 @@
+# ADR 0000: Project Goals
+
+## Status
+
+Accepted.
+
+## Decision
+
+`geth` is a personal, local-first, script-friendly mesh runtime built as a Rust
+monorepo around Iroh networking and resource-oriented modules.
+
+It is not a blockchain, not a consensus system, not the Ethereum geth client,
+and not a replacement for OpenSSH authentication.
+
+## Consequences
+
+The project favors local ownership, explicit resources, durable metadata,
+capability-based authorization, and future multi-user collaboration.

docs/adr/0001-single-binary-cli-and-daemon.md

@@ -0,0 +1,18 @@
+# ADR 0001: Single Binary CLI And Daemon
+
+## Status
+
+Accepted.
+
+## Decision
+
+The project ships one executable: `geth`. It has daemon mode with
+`geth daemon run` and control mode through commands such as `geth status`.
+
+Control commands use a local Unix socket. There are no separate `gethd` or
+`gethctl` binaries.
+
+## Consequences
+
+Packaging and user mental model stay simple. The daemon remains the owner of
+identity, Iroh endpoint state, resources, and synchronized data structures.

docs/adr/0002-iroh-only-remote-transport.md

@@ -0,0 +1,17 @@
+# ADR 0002: Iroh-Only Remote Transport
+
+## Status
+
+Accepted.
+
+## Decision
+
+All remote geth node-to-node communication happens over Iroh. The daemon will
+own one shared endpoint and register module protocols on explicit ALPNs.
+
+There is no SSH transport fallback and no `ssh host gethd stdio` flow.
+
+## Consequences
+
+Transport behavior is coherent and resource authorization can be enforced before
+opening module streams.

docs/adr/0003-resource-model.md

@@ -0,0 +1,18 @@
+# ADR 0003: Resource Model
+
+## Status
+
+Accepted.
+
+## Decision
+
+Everything meaningful is modeled as a resource. Initial kinds are `db`, `kv`,
+`pipe`, `document`, `pubsub`, `cas`, and `ssh-proxy`.
+
+Resources have capability-scoped authorization. Roles may exist as bundles, but
+capabilities are the underlying permission unit.
+
+## Consequences
+
+Resource APIs, auth logs, secrets, and future replication can share one model
+without relying on global roles.

docs/adr/0004-keychain-and-auth-model.md

@@ -0,0 +1,18 @@
+# ADR 0004: Keychain And Auth Model
+
+## Status
+
+Accepted.
+
+## Decision
+
+The keychain is SSH-rooted and models admin keys, users, devices, nodes, agents,
+and endpoint bindings. Resource authorization is represented as signed operation
+logs reduced into a current permissions view.
+
+Mutable ACL blobs are not the primary source of truth.
+
+## Consequences
+
+The system can answer why an operation is allowed or denied and can evolve toward
+local-first multi-user authorization.

docs/adr/0005-bearer-resource-secrets.md

@@ -0,0 +1,18 @@
+# ADR 0005: Bearer Resource Secrets
+
+## Status
+
+Accepted.
+
+## Decision
+
+Bearer secrets may grant resource-specific capabilities. They do not create
+trusted node identity and should not normally grant trust graph mutation rights.
+
+Private resource access is modeled with resource master secret epochs. Revocation
+is approximated by rotating to a new epoch and distributing it only to remaining
+authorized devices.
+
+## Consequences
+
+Invites and temporary access can be practical without weakening node identity.

docs/adr/0006-keyhive-beekem-roadmap.md

@@ -0,0 +1,16 @@
+# ADR 0006: Keyhive/BeeKEM Roadmap
+
+## Status
+
+Accepted.
+
+## Decision
+
+The project will leave room for Keyhive-like local-first authorization and
+BeeKEM/CGKA-style group key evolution later. The bootstrap does not implement
+BeeKEM and does not claim strong forward secrecy or post-compromise security.
+
+## Consequences
+
+Types are versioned and capability-oriented, while advanced cryptography remains
+out of scope for the MVP.

docs/adr/0007-synchronized-data-structures.md

@@ -0,0 +1,15 @@
+# ADR 0007: Synchronized Data Structures
+
+## Status
+
+Accepted.
+
+## Decision
+
+The planned synchronized structures are `db`, `kv`, `pipe`, `document`,
+`pubsub`, `cas`, and `ssh-proxy`.
+
+## Consequences
+
+Each module can progress independently while sharing resource registration,
+capability checks, daemon-owned Iroh endpoint access, and local metadata.

docs/adr/0008-cas-and-blob-distribution.md

@@ -0,0 +1,16 @@
+# ADR 0008: CAS And Blob Distribution
+
+## Status
+
+Accepted.
+
+## Decision
+
+CAS starts as local filesystem storage with BLAKE3 content hashes. Future work
+adds iroh-blobs, provider tracking, pins, encrypted private blobs, collections,
+manifests, and file sync tree objects.
+
+## Consequences
+
+The MVP has useful local blob commands while preserving a path to networked blob
+distribution.

docs/adr/0009-ssh-trust-and-ssh-proxy.md

@@ -0,0 +1,16 @@
+# ADR 0009: SSH Trust And SSH Proxy
+
+## Status
+
+Accepted.
+
+## Decision
+
+SSH keys are admin signing identities and ecosystem integration points. SSH is
+not a geth transport. Future SSH proxy support will carry SSH protocol bytes over
+authorized Iroh streams, and OpenSSH will still perform normal login auth.
+
+## Consequences
+
+Knowing an Iroh EndpointID is insufficient to reach sshd. Geth authorization must
+allow `ssh_proxy.connect` before any SSH/admin endpoint is opened.

docs/adr/0010-crsqlite-db-sync.md

@@ -0,0 +1,16 @@
+# ADR 0010: cr-sqlite DB Sync
+
+## Status
+
+Accepted.
+
+## Decision
+
+Database sync will use local SQLite databases with cr-sqlite. Changes from
+`crsql_changes` will be exchanged over Iroh and applied through cr-sqlite, with
+schema hash gating and resource authorization.
+
+## Consequences
+
+The MVP stores DB resource metadata and leaves synchronization as explicit future
+work.

docs/adr/0011-kv-iroh-documents.md

@@ -0,0 +1,15 @@
+# ADR 0011: KV With Iroh Documents
+
+## Status
+
+Accepted.
+
+## Decision
+
+KV resources will use Iroh Documents namespaces for small replicated state,
+configuration, metadata, preferences, and script state. Authorization can include
+prefix-scoped capabilities.
+
+## Consequences
+
+The MVP exposes CLI shape and types while deferring iroh-docs API pinning.

docs/adr/0012-automerge-documents.md

@@ -0,0 +1,16 @@
+# ADR 0012: Automerge Documents
+
+## Status
+
+Accepted.
+
+## Decision
+
+Document resources will use Automerge for JSON-like CRDT state synchronized over
+Iroh streams. Documents may carry or delegate to their own resource-local auth
+state.
+
+## Consequences
+
+This leaves a path to multi-user local-first documents without implementing the
+full cryptographic model during bootstrap.

docs/adr/0013-pipe-and-pubsub.md

@@ -0,0 +1,19 @@
+# ADR 0013: Pipe And Pubsub
+
+## Status
+
+Accepted.
+
+## Decision
+
+Pipe resources will use authorized Iroh streams for stdin/stdout-style byte
+streams and forwarding. Pubsub will use lossy gossip for wakeups, presence,
+status, and ephemeral notifications.
+
+Pubsub is not authoritative storage. Important facts must live in durable
+resources such as kv, document, db, CAS manifests, or future auth logs.
+
+## Consequences
+
+The modules can support ad hoc workflow and presence without confusing gossip
+with durable state.