#Aims and reasoning
#The problem: infrastructure without a growth engine
A non-profit with no engagement or growth incentive still has to pay to store and serve content. Funding must not reintroduce advertising, surveillance, or competitive standing through the infrastructure that supports the product (§01, §02).
#A friends-and-family hosting mesh
People should be able to offer spare capacity on old phones, laptops, home servers, or community hosts. The ordinary action is offering or accepting storage; operating a server must not be a prerequisite. A friend who offers storage should be visible to its recipient, so the contribution remains an interpersonal gift.
#Hosting is not reading
Storing a person's encrypted content grants no permission to read it. Reading follows the same audience rules whether the bytes come from a friend, a paid provider, or the person's own device. The same hosting service can support an optional community workspace without making its operator a member or decision-maker.
#Redundancy for intermittent hosts
A friend's sleeping laptop can contribute to an archive without being a reliable source for an urgent retrieval. The product therefore distinguishes durability—surviving losses over time—from hot availability—retrieving an item promptly. Recent, declared-important, or repeatedly unavailable content can use better-connected capacity without turning storage allocation into a public popularity ranking.
People see “well backed up,” “needs more hosts,” or “hot hosting enabled.” Coding parameters, repair thresholds, and provider payment machinery stay in the implementation. “Saved locally,” “copied elsewhere,” and “backed up under the selected policy” must remain different claims.
#Social-proof storage gifting
Recipient-visible gifts are the stable direction. Contact-visible contribution badges remain possible; global badges need a separate abuse and status review. Public “top hosters” leaderboards are excluded. Host reliability can inform placement without becoming a person's social score.
#Free tier and paid storage
The intended offer is some free capacity, with optional purchases of durable archive space or faster availability. Plain units such as archive GB-months, hot GB-months, and fair-use egress make the resource being bought legible. Paying for storage must not buy prominence, authority, or preferential delivery in another person's feed. A gift need not expose the recipient's content inventory to its funder.
#The Sybil-resistance fork (open)
A free tier needs bounded abuse costs. A phone number per signup conflicts with the no-phone-number identity direction and makes privacy depend on the ability to pay (§03). The alternatives remain explicit:
| Option | Abuse pressure | Privacy and inclusion tradeoff |
|---|---|---|
| Phone number | Adds account-creation friction | Conflicts with the identity direction; creates an identifier dependency |
| Invite scarcity | Makes capacity creation socially costly | Needs invite-abuse controls and a path for isolated newcomers |
| Small payment | Adds an economic cost | Exposes payment metadata and excludes some people |
| Small quotas with bounded abuse | Limits the value of each account | Requires operational tolerance and fair resource limits |
#Ciphertext hosting still needs legal design
Ciphertext is a privacy property, not a liability conclusion. Ordinary hosts must be able to pause, drain, or stop hosting and forward a notice without inspecting content. Personal hosting remains conditional on counsel defining service roles, notice handling, takedown, preservation, and host protection for the launch jurisdictions. Foundation or contracted hosting is the fallback where those protections are insufficient. The legal decision and evidence are coordinated with §08.
#Protocol and architecture
#Separate content authority from a storage lease
A storage locator identifies encrypted bytes, not a person, channel, or canonical TalkCo object. A scoped object record binds the representation, audience, and permitted actions. Unrevealed contexts normally require independently encrypted representations; sharing ciphertext or locators can expose equality. Releasing one lease neither cancels another valid lease nor erases plaintext or keys already held by a reader.
| Seam | Likely implementation or alternative | TalkCo work still required |
|---|---|---|
| Local custody ledger | SQLite through rusqlite; first-slice candidate | Atomic leases, quotas, crash recovery, retention and persistent retry state |
| Immutable representation | ERIS over application ciphertext; comparison with Bao/BLAKE3 ciphertext | Codec conformance, streaming authentication, read-capability handling and context separation |
| Block/custody service | Kapla, Tahoe-LAFS/ZKAP, or a smaller Rust service; competing experiments | Finite leases, resource accounting, repair, host departure and interface adaptation |
| Native peer transfer | iroh-blobs over iroh; candidate adapter | Authenticated fetch policy, bounded serving and route/privacy controls |
| Hosted bytes | S3-compatible opaque storage; controlled baseline | Scoped provider credentials, export, deletion and failure semantics |
| Object protection | AEAD and recipient key delivery; proposed in encryption research | Key lifecycle, device grants, deniable authentication and storage/key separation |
| Erasure-coded custody | Reed–Solomon implementation to be selected | Authenticated shards, K/N choice, placement, repair and failure-domain model |
ERIS is an immutable encoding, Kapla a candidate block service, and iroh-blobs a transfer/storage library: none alone implements the whole custody contract. The distribution page owns these boundaries; the tools index owns package evidence. These are integration candidates, not adopted dependencies.
#Variation — Replicas for the first custody experiment
Complete replicas simplify recovery and let the first experiment isolate leases, host departure, and privacy. Their storage cost grows with replica count. Two custody peers exercise distributed behavior; they do not establish a durability target. Hosted and peer adapters can coexist without sharing provider credentials or namespace identifiers.
#Variation — Erasure coding for larger archives
Coding protects availability, not access: K shards reconstruct ciphertext and convey no decryption authority. ERIS's block tree is not erasure coding. A storage adapter may code validated packs while preserving ordinary ERIS block identity. The variation earns its complexity only if measured attachment sizes, host churn, and repair costs beat replicas. Storj's repair design and Tahoe's client/storage separation are operational references (StorjFileRepair, Tahoe architecture).
Candidate storage parameters
Retain the existing simulation grid as hypotheses: seed-backed 10/20 or 16/32, and friend-mesh 20/40, 24/48, or 30/80. Test host classes separately: reliable seed, contracted, community, laptop, old phone, and temporary client copy. Placement should avoid correlated household, owner, network, provider, or jurisdiction failures where practical.
The earlier 80% watch, 65–70% repair, and “parity half spent” triggers cannot be copied into an ordered state machine. For K=N/2, half the parity margin is spent at 75% of N, above the proposed repair threshold. Each profile needs ordered watch, repair, and critical thresholds derived from repair delay and loss risk. Reachability is not proof of continuing possession; the possession-check method and its metadata cost are also unresolved.
IPFS pinning, Storj repair, Filecoin/Sia contracts, and Hypercore sparse replication clarify distinct jobs; none settles this composition. Logos Storage/Codex remains a benchmark. Supporting comparisons belong in the tools inventory, rather than a second catalog here.
#Repair, hot availability, and host departure
A repair grant is bounded by generation, destination, expiry and byte/work allowance. It cannot create readers, change content, or renew expired retention. Hot placement separately considers owner intent, recency, declared community need, retrieval failure, or coarse authorized demand. It must not produce public view counts, global ranking, or permanent social graphs. Hosts can stop accepting work immediately; a planned drain improves availability but cannot trap someone into providing service indefinitely.
#Give each operator only the metadata its job requires
| Recipient | Candidate minimum view | Excluded by design |
|---|---|---|
| Storage host | Opaque locator, size bucket, lease expiry, serving bounds, scoped notice route | Application keys, reader list, profile-root identity, complete placement map |
| Authorized repair coordinator | Required placements, integrity commitments, host class, finite allowance | Unnecessary social relationships or exact per-reader history |
| Payment broker | Purchased units and billing obligations | Content, audiences, decryption keys, social contribution score |
| Legal/safety route | Relevant scoped lease/object reference and service role | A universal read key or automatically published host graph |
A complete placement map and recovery-bundle index require restricted access. Exact legal metadata depends on jurisdictional review. Storage coordination must not casually expose a person's hosts or reconnect their profile spheres (RFC6973).
#The layered economics underneath
Model costs per selected profile: retained bytes and egress, repair traffic, relay operation, and any conditional-release service. Session-style transport or TACo may introduce network-specific fees or incentives if adopted; those costs are not inherent to every TalkCo design. A broker, foundation service, or advanced user-selected provider can absorb substrate accounting behind ordinary resource purchases.
Physical host quotas, funding/gifting, and spending authorization are distinct. Compare provider- or pool-bound allowances before globally spendable offline tickets. Capabilities can constrain an action but do not, by themselves, enforce a cumulative budget. The private accounting research owns ZKAP/Privacy Pass comparisons, double-spend tests and crash-safe metering.
#Open Threads
- Free capacity and Sybil resistance — compare invite scarcity, modest quotas, optional payment and bounded abuse without quietly making a phone number mandatory; lane #8.
- Custody and repair experiment (OT-11-002) — compare replicas with the retained K/N grid, including correlated outages, ordered thresholds, possession checks, quota exhaustion and host departure; lane #7.
- Hot availability (OT-11-003) — set promotion, demotion and price rules without global demand tracking; decide what must ship in the first release.
- Contribution visibility (OT-11-007) — choose recipient-only gifts, contact-visible badges, or a narrower alternative.
- Recovery bundle custody (OT-11-008) — test encrypted indexes, stale backups, and host migration without sphere enumeration or ownership reassignment; identity authority stays in §03.
- Personal-hosting launch gate (OT-11-009) — complete jurisdictional review and object-scoped notice, takedown and preservation procedures; retain contracted-hosting fallback.
- Sustainability (OT-11-006, OT-11-010) — compare full costs for each architecture variation in §12, rather than assuming three mandatory token-funded layers.