Ghost Keys: evaluate recurring membership as the funding model

[sanity]

Parking a design direction so it isn't lost. Nothing here is built, and this is deliberately not scoped as a task yet.

The observation

Ghost Keys are a one-time purchase. At roughly $3 average, "a major funding source" means order 100k purchases a year, which needs distribution the project doesn't have.

Recurring changes the unit from transactions to people. At $3/month, a ~$240k annual run rate needs about 6,700 active members. Same money, and instead of persuading 100,000 people a year you persuade about seven thousand once and keep them. That is a plausible community size for a project with Freenet's profile; 100k annual buyers is not.

Why it's compatible with the anonymity model

The obvious objection is that a subscription needs a standing customer record with an email and a card, which sounds like it wrecks the privacy story. It doesn't, and the distinction is worth stating precisely:

Donor anonymity was never the promise. Key unlinkability was.

Blind signing does not hide that you donated. It makes it impossible to connect your donation to the key you walk away with. Someone can be a fully identified monthly member, on a receipt and a tax letter, and still hold a Ghost Key nobody can tie to them.

What the code says today

• No expiry mechanism exists. NotaryPayload (rust/gklib/src/notary_certificate.rs) carries a verifying key and a free-form info string; GhostkeyCertificateV1 carries the notary cert, a verifying key, and a signature. Nothing temporal anywhere.
• Period cohorts would need no wire change. Notary keys are already per-amount. Making them per-(amount, period) and putting the period in info gives apps a freshness signal for free, with old notary keys staying published so old certificates keep verifying.
• Anything stronger is a V2. The CBOR field names are frozen for backward compatibility (see the #[serde(rename = "delegate")] comments), so a real expiry field means a new certificate version and a verifier migration.

The tradeoff to decide deliberately

Period cohorts shrink the anonymity set. Today it is everyone who ever bought at that tier; with monthly cohorts it is everyone who bought at that tier that month, which early on could be very few people. Quarterly or annual cohorts are a middle ground if a freshness signal is wanted without slicing the set too thin. This is the same volume-is-a-security-property point that the tier ladder (#100) already had to reckon with.

Suggested shape, if pursued

Don't expire keys. Sell a membership that recurs; keys already minted stay valid forever. Continued membership buys the right to keep minting (where bundled issuance, freenet/ghostkeys#2, earns its keep) plus the ordinary reasons people sustain a nonprofit. Expiring keys would rent people their identity, which undercuts the thing the project trades on, and would drag offline verification toward the call-home the design deliberately avoids. If an app wants recency it can apply its own policy against the cohort in info.

Cost, stated honestly

Not a tweak. Stripe Subscriptions is a different integration from the PaymentIntent flow the whole API is built on, and recurring billing brings a permanent operational tail for a small team: failed cards and dunning, cancellation, proration, receipts, tax letters.

Cheaper experiment first

Make River require a Ghost Key to post. It is the project's own app, it has the spam problem, and it is the only way to learn whether the flow survives contact with real users at a price above zero. It creates baseline demand and dogfoods bundled issuance, at a fraction of the cost of a go-to-market.

Related: freenet/ghostkeys#2 (bundled issuance), #25 (unlinkable presentation via ZK).

[AI-assisted - Claude]

[sanity]

Issue Priority Assessment

Generated: 2026-08-22T16:44:34.265573447+00:00
Issue hash: db0e77c0

Value Assessment

The code confirms the issue's technical claims are still accurate: NotaryPayload in rust/gklib/src/notary_certificate.rs carries only notary_verifying_key and a free-form info: String — no temporal/expiry field exists, and the CBOR field names are indeed frozen via #[serde(rename)] for signature-compatibility reasons, exactly as described. The API (rust/api/src/routes.rs, payment_claim.rs) is built entirely around one-shot PaymentIntent claims, confirming there's no subscription/recurring billing plumbing at all today. Nothing in the issue is stale.

This is explicitly a parked design note, not an actionable task — it says so up front ("deliberately not scoped as a task yet"). Its value is as a considered strategic option for Ghost Keys' funding model, backed by real unit economics (100k one-time buyers vs. ~6,700 recurring members for the same revenue) and a correct, non-obvious privacy analysis (donor identity vs. key unlinkability are separable, so recurring billing doesn't compromise the anonymity property). That distinction is the most valuable part of the issue — it pre-empts an objection that would otherwise kill the idea in review.

Strategic alignment is real but the issue itself resists commitment: it flags recurring billing as a substantial new integration (Stripe Subscriptions vs. PaymentIntent) with an ongoing operational tail the team doesn't currently carry, and it proposes a cheaper, concrete precursor experiment — gating River posting behind a Ghost Key — to validate demand before building any of this. That precursor is actually actionable today and would produce evidence this issue currently lacks.

There's no blocking factor: nothing else depends on this, and no urgency — it's a funding-model direction, not a bug or regression. Recommended value: keep open as a reference/parking issue, but don't schedule engineering work against it; if anything is actioned near-term it should be the River-gating experiment it proposes, not the subscription build-out itself.

Cost Assessment

This issue is explicitly a design placeholder ("Nothing here is built, and this is deliberately not scoped as a task yet"), and the code inspection confirms it's accurately describing the current state: rust/gklib/src/notary_certificate.rs has no temporal/expiry field, and rust/api/src/routes.rs and handle_sign_cert.rs are built entirely around Stripe's one-shot PaymentIntent flow (create → retrieve → mark spent → sign), with no subscription object anywhere in the API crate. So the issue is still fully relevant and accurate; nothing has drifted.

The real cost here isn't the code, it's everything the issue itself flags as out of scope for "cost": this is a business-model decision, not an engineering task, and the issue explicitly declines to scope an implementation. If someone did pursue it, the cheap slice (period-cohort notary keys, i.e. (amount, period) instead of amount, encoded via the existing free-form info string) is genuinely small — a change to how notary keypairs are generated/published plus threading a period value through routes.rs/handle_sign_cert.rs, no wire format change, no new CBOR version. That's maybe a day of work across rust/gklib and rust/api, low risk, easy to unit test since it's just an added string parameter.

The expensive slice — actual Stripe Subscriptions — is a different integration surface than what exists today: recurring billing needs webhook handling for renewal/failure/cancellation events (nothing in rust/api/src currently touches webhooks beyond the one-time payment flow), dunning logic, proration, customer-facing receipt/cancellation UX, and a permanent operational tail (failed-card handling, tax letters) that has no code-only fix — it's ongoing support burden. None of that is blocked on external approvals or waiting on third parties in the traditional sense, but it is a scope and maintenance commitment the issue itself declines to size, correctly.

Given the issue's own recommendation — dogfood via making River require a Ghost Key to post, before building any recurring-billing infrastructure — the actionable near-term cost is near zero (it's a decision/experiment, not a PR), and the real subscription build should be costed only once that experiment produces signal. As filed, this issue is correctly a "park it" item, not an implementation-ready one.

---

Generated by issue-prioritizer