How dare you ask this question. We need to "listen to the professional software developers." Oh but wait, what happens when they disagree? Oh, well then we should listen to the "majority of the main group" because that always works out.
The best case scenario is the notion of having “one codebase” cured with a new paradigm in source control management using Nostr. Not just a different backend on Git, but an entirely new way of managing pull requests and the review process. This paradigm uses `npub`-based web-of-trust and PRs that allow merges with arbitrary forks. Rather than trusting a single person with “the keys” to the repo, trust becomes divergent - as should the codebase itself - while harmony is achieved through automated functional testing against specifications.
This way, the end-user selects which features are included, and the forking, building, and validation process becomes trivially implemented through scripting. It achieves similar selectivity to `kconfig` and `kmod`, where every kernel can differ for its purpose, but here applied across general software.
## Core principles
1. **Divergent trust, convergent behavior.** No canonical repo. Interop comes from conformance to specs and test suites, not from custodial maintainer keys.
2. **Identity = keys (npub).** Web-of-Trust (WoT) computes reputation locally; every attestation is signed.
3. **Artifacts are content-addressed.** Code, specs, tests, build recipes, and results are blobs addressed by hash; Nostr carries signed metadata and references.
4. **Policy-driven selection.** Each user/organization runs a policy that selects which forks, features, and patches compose their build.
5. **Everything is attestable.** Reviews, CI results, SBOMs, and releases are signed events; no “state” exists off-ledger.
## High-level architecture
- **Storage layer:** content-addressable (CAS over IPFS/torrent/object store). Nostr events store hashes/URIs; data stores serve blobs.
- **Nostr event schema:** new event kinds to model repos, modules, specs, PRs, reviews, CI attestations, releases, and WoT edges.
- **Module graph:** repo ⇒ modules ⇒ units (packages/libraries/plugins). Directed acyclic graph keyed by `(module_id, version_hash)`.
- **Profiles:** kconfig-like “feature profiles” that select modules/variants and set version constraints.
- **Policy engine:** given a profile, WoT weights, and attestations, resolve a build plan deterministically.
- **CI/Validation network:** untrusted builders publish *signed* result attestations (pass/fail, logs, SBOM, reproducible build proofs).
- **Relay/rate limiting:** relays enforce anti-spam using blind-signed tokens and per-npub quotas; attestation relays may be specialized.
## What this enables
- End-user chooses features; builds are trivially scriptable and hermetic.
- PRs become portable, testable *offers*—not pleas to gatekeepers.
- Fork explosion becomes an asset; convergence emerges from tests + policy.