Architecture Decision Records

An Architecture Decision Record (ADR) captures a single significant decision — the context that forced it, the choice made, and the consequences accepted — so the reasoning survives the commit that implements it.

These records are intentionally append-only. A decision that no longer holds is not edited away; a later ADR supersedes it and the old one stays as history, its status updated to point forward.

Status vocabulary

Status	Meaning
Proposed	Written up for discussion; not yet agreed or built.
Accepted	Agreed and in force (built, or committed to build).
Superseded	Replaced by a later ADR (linked from the header).
Rejected	Considered and deliberately not taken (kept for the reasoning).

Index

ADR	Title	Status
0001	Allow bundled dependencies in plugins	Accepted
0002	Host-mediated plugin network access (net:fetch)	Accepted
0003	Marketplace trust tiers	Accepted
0004	Document & artifact association for transactions	Proposed
0005	Plugin-originated transactions (source:provide)	Proposed
0006	External market & reference data as a first-class source	Proposed
0007	Soft-delete: reversible transaction hiding	Proposed
0008	Inbound-webhook source (webhook archetype)	Accepted
0009	Selective peer-to-peer ledger sharing	Proposed
0010	Custody-free internet peer connectivity	Proposed

ADRs 0001–0003 form one arc: they widen what a plugin may do without abandoning the sandbox that makes plugins safe to install. ADR 0004 is the use case that motivated the arc — associating a receipt with a transaction — and shows how the new seams (plus the existing ones) compose to serve it. ADR 0005 takes the last step the arc deliberately deferred — letting a plugin originate a transaction — and resolves it through the existing ingestion seam (a plugin produces a batch; the engine writes it) rather than a raw write. ADR 0006 opens a different front: world data (benchmarks, quotes, FX) as a first-class source with its own archetype and a market_* cache namespace — the backend half of a decision shared with the sillview dashboard, whose own ADR-0004 records the consumption half. ADR 0007 turns inward to the ledger's own integrity: it replaces destructive hard deletion with a reversible soft-delete (deleted_at), so transactions — manual or synced — can be hidden from views and analysis without erasing the record, with hard deletion narrowing to genuine teardown (source uninstall, account deletion). ADR 0008 adds the first push source: the webhook archetype, where an external system POSTs a signed batch to an ingest endpoint instead of kasas polling for it. It inverts the Puller direction through a new Receiver capability while reusing the engine's existing persist path verbatim, and reuses kasas's own outbound-webhook HMAC scheme for verification — so the security boundary is a shared secret, not the dashboard token. ADR 0009 turns ADR 0008's one-way ingest into a relationship: selective, subscription-style peer-to-peer sharing between two self-hosted ledgers, with no mandatory central server. It reframes a "share" as a saved search query and a "subscription" as adding a peer source, so the engine's persist/dedup/events/rules all apply for free; on the receiver each row keeps its original originator (in an extension) and gains a shared_by:<ledger> tag, while a structural origin-guard forbids re-exporting rows you did not author. ADR 0010 fills the one gap 0009 left — connecting two strangers on different networks who share no tailnet and no out-of-band channel — on the Syncthing model: direct-first, with a content-blind community-relay fallback. An earlier hosted, paid zero-knowledge directory + encrypted mailbox draft was rejected (a data processor with privacy/DPA/retention/deletion duties over stored content); a still-earlier direct-only draft rejected relays entirely but forced every receiving peer to bring its own front door — too much friction. The current revision is "0009 + a keypair + a doctrine + a live relay fallback": ed25519 identity (realizing 0009's deferred proven-attribution upgrade) + age encryption, BYO front door now optional (a latency optimization), and — for the both-online-but-double-NAT case — kasas seeds content-blind, stateless, overridable relay and discovery defaults so it works out of the box. The crucial distinction: a live relay is not the rejected mailbox — it bridges two simultaneously-online peers and holds no content at rest, so the heavy mailbox duties (retention/deletion/breach/DSAR over content) are eliminated structurally. kasas is never a custodian of financial data (E2E always); the honest residual is a thin, non-zero duty (a privacy policy + abuse contact + no-logs posture for transient IP/metadata) on the defaults it seeds. No mandatory central server still holds — direct-first works with every default disabled — so 0010 preserves 0009's no-mandatory-central principle, softening the absolutist "kasas operates nothing" to "operates only content-blind, overridable defaults." No async, pure OSS, donations only.