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.

docs/architecture.md

@@ -0,0 +1,88 @@
+# Architecture
+
+`geth` is a single-binary local-first mesh runtime. One executable provides both
+daemon mode and control mode. The daemon owns local identity, metadata storage,
+the future shared Iroh endpoint, resource registry, module routing, and local
+control socket. Control commands connect to the Unix socket and send typed JSONL
+requests.
+
+## Iroh-Only Remote Communication
+
+Remote geth node-to-node communication is Iroh-only. The daemon will own one
+shared Iroh endpoint and register module protocols on ALPNs such as
+`/geth/cas/1`, `/geth/kv/1`, `/geth/pipe/1`, and `/geth/ssh-proxy/1`.
+
+SSH keys are not transport keys. They are admin trust anchors and signing
+identities for keychain and authorization operations. SSH proxying, when added,
+will carry SSH bytes over an authorized Iroh stream and will not make SSH a geth
+transport backend.
+
+## Resource Model
+
+Everything meaningful is modeled as a resource. Resources have a kind, name,
+authority reference, local role, replication policy, retention policy, and
+status. Authorization is resource-scoped and capability-based.
+
+Resource kinds:
+
+- `db`: cr-sqlite-backed SQLite synchronization
+- `kv`: Iroh Documents backed key-value data
+- `pipe`: authorized byte streams and forwarding
+- `document`: Automerge CRDT documents
+- `pubsub`: lossy notifications and presence
+- `cas`: content-addressed blobs
+- `ssh-proxy`: SSH/admin proxying over Iroh
+
+## Module Overview
+
+`geth-cas` is implemented locally first using BLAKE3 hashes and filesystem blob
+storage. Iroh-blobs, providers, encrypted blobs, manifests, and file sync trees
+are future work.
+
+`geth-kv`, `geth-db`, `geth-document`, `geth-pubsub`, `geth-pipe`, and
+`geth-ssh-proxy` currently define types, command shape, and roadmap stubs.
+
+## Keychain, Auth, And Secrets
+
+The identity plane is `geth-keychain`: admin keys, users, devices, nodes, agents,
+and endpoint bindings. Endpoint rotation must not destroy higher-level node
+identity.
+
+The authorization plane is `geth-auth`: resource-local signed operation logs,
+grants, revocations, groups, and `auth explain`.
+
+The payload access plane is `geth-secrets`: resource master secrets, epochs,
+key envelopes, bearer secrets, and rotation. Revocation for private data is
+modeled initially as secret epoch rotation.
+
+## Multi-User Direction
+
+The project is structured for future multi-user local-first authorization:
+
+- authorization is replicated data, not one mutable ACL blob
+- resources can carry or delegate to their own auth state
+- users, devices, nodes, agents, and endpoints are separate principals
+- capabilities are the underlying permission unit
+- bearer access is resource-scoped and does not mutate the trust graph
+- offline revocation is eventual
+- encryption key distribution is part of authorization
+
+## Keyhive/BeeKEM Roadmap
+
+Resource secret epochs are the v0/v1 approximation for private payload access.
+Later designs can add Keyhive-like convergent capabilities and BeeKEM/CGKA-style
+group key evolution. The bootstrap does not implement BeeKEM and does not claim
+strong forward secrecy or post-compromise security.
+
+## Security Invariants
+
+- All remote node-to-node communication is over Iroh.
+- SSH is not a geth transport.
+- SSH keys are admin trust anchors and signing identities.
+- Agent/node keys handle routine local identity.
+- Discovery is untrusted.
+- Knowing an EndpointID does not grant access.
+- Bearer secrets are resource-scoped capabilities.
+- Bearer access does not imply trust graph mutation rights.
+- Authorization is capability-based and resource-scoped.
+- Network and control decoders treat input as untrusted.

docs/roadmap.md

@@ -0,0 +1,57 @@
+# Roadmap
+
+## Phase 0: Bootstrap
+
+- single CLI
+- local daemon
+- local store
+- local identity
+- local CAS
+- docs and ADRs
+
+## Phase 1: Iroh Foundation
+
+- Iroh endpoint
+- peer cards
+- peer discovery
+- peer exchange
+- basic authenticated peer connection
+
+## Phase 2: Trust And Authorization
+
+- SSH-admin-rooted keychain
+- signed keychain ops
+- resource auth ops
+- grants and revocations
+- auth explain
+- resource secrets
+- bearer invites
+
+## Phase 3: CAS/KV/Pubsub
+
+- iroh-blobs CAS
+- iroh-docs KV
+- iroh-gossip pubsub
+- private topics and encrypted values
+
+## Phase 4: Pipes And SSH Proxy
+
+- dumbpipe-style streams
+- TCP and Unix socket forwarding
+- SSH proxy over Iroh
+- restricted geth admin shell
+
+## Phase 5: DB And Documents
+
+- cr-sqlite sync
+- Automerge sync
+- resource-attached authorization
+- secret-derived encryption
+
+## Phase 6: File Sync And Advanced Local-First Auth
+
+- CAS tree objects
+- file roots
+- conflict handling
+- Keyhive-like convergent capabilities
+- BeeKEM/CGKA-inspired group key evolution