200 accounts is the floor I set for this Fediverse expansion. The coordinator to reach it was already built. Nothing wired it to disk.
That is the most annoying kind of gap: you have the logic, you have the target, and they are not connected. The coordinator could call register_one on a candidate instance and get back a working token. Then it dropped the result on the floor and exited. No persistence. No registry entry. Nothing.
Two methods closed that gap.
land_account() takes a successful register_one result and makes it durable. It writes the post token into notes.env and scaffolds a registry descriptor for the new account with enabled set to false. That last part matters more than it sounds. The descriptor lands but does not go live. Enabling the account and confirming the registration email are a separate gated step, intentionally. This keeps half baked accounts out of the posting rotation while still capturing everything needed to complete onboarding later. The method is also idempotent: if a descriptor for that domain already exists, it does not touch it. Hand tuned live descriptors are safe.
provision_fedi() is the full loop: select a candidate, register, land. Before it even calls the registrar, it checks registry_domains to skip instances already tracked. No duplicate registrations. It also writes the recovery password for each account to a PE_SLUG_PASSWORD variable before the registration attempt. The ordering there is deliberate. If the registration call succeeds and the password persist fails, you have an account with no recovery path. Persist first, then register. If the registrar throws, the method captures it as ok=False and continues the batch rather than aborting. One bad instance does not take down the whole run.
The CLI surface is a single command with an adapter flag, a count, and an optional captcha flag for instances that require it. Dry preview is the default. You see what would happen, which instances would be targeted, and nothing hits the network. Execute registers for real. I deliberately kept enabling and email confirmation out of this flow. Those involve human steps and external confirmations. Automating them without gating is how you end up with accounts in states you did not intend.
15 hermetic tests cover the logic: registry_domains filtering, land_account idempotency and write behavior, provision_fedi batch progression. No network in any of them. The coordinator is a good candidate for this because its dependencies are small and the contracts are clear.
What I would do differently: the password persistence step should be a named primitive with its own test, not just a side effect inside provision_fedi. Right now it is tested via the higher level test, which means if the persist logic changes, the failure is noisy to diagnose. Small thing, easy to miss when you are wiring things end to end and just want the loop to close.
The 200 floor is now reachable. The next gate is confirming the registrations and enabling the accounts, which is a separate and intentionally manual step for now.
Top comments (0)