Item 7: the comparison, landing and donation pages were written on a branch and
never deployed, so the live site described a product that stopped being accurate
several changes ago. Cherry-picked and deployed; the comparison page now says
relays federate, that an address is derived rather than issued, and why
federating is a trade rather than a win.
Donation flow verified end to end against production keys: out-of-range amounts
are refused before Stripe is contacted at all, and a valid amount creates a real
Checkout Session and redirects to it. No payment was made -- an unpaid session
expires on its own. ⚠️ I could NOT verify with test keys: there is no Stripe
test key on the box, and inventing one proves nothing.
Item 9, which is a narrower claim than it looks and worth testing exactly:
**hosting only Messenger leaves nothing missing.** Proven three ways -- a local
relay names no account service at all, runs a full sign-up and sign-in cycle
with nothing else involved, and never probes for Files.
And when the shared service IS used, one handle and passphrase signs in to both
Messenger and Files. The two sessions carry DIFFERENT pseudonyms, which is the
point rather than a detail: same-pseudonym would let the two services correlate
their users, which is exactly what a shared account service must not enable. A
Files-scoped token is also refused by the Messenger relay -- the product scope
is a boundary, not a label.
⚠️ The shared-account tests now back off and retry on the account service's rate
limit, because a dozen registrations in a burst is something any sane service
should refuse. They still fail if it never clears: a rate limit that does not
lift is a real problem, and skipping on it would hide one.
Paul Hitt
ca626b3368