Choosing where your account lives

Federation splits one decision into two. On a closed messenger, signing up means accepting the single operator’s software, policies and longevity in one bundle. On XMPP the account lives on a server someone runs, and the client is a separate choice that can be changed at will. That separation is the network’s strength and its first confusion: a new user picks an app in minutes and an address almost by accident, when the address is the decision that follows them.

The useful model is a property purchase, and the method comes from exactly that field. The guide at walking the neighbourhood first is built on a simple discipline for New England houses: visit at different hours, listen for the traffic, check what the street looks like in the season you did not buy in. Translated, the advice is that the thing being chosen is a context, not an object, and contexts are read by observation over time rather than by the listing. A public XMPP server rewards the same reading.

What is the neighbourhood of a server?

Everything the address inherits. A JID carries its domainpart to every room and roster it joins, so the server’s name, history and moderation posture arrive before the user does. A domain with a reputation for lax registration finds its users treated accordingly; a domain run by a named, reachable operator carries a different expectation. The account also inherits the operator’s jurisdiction, which decides what law governs the service and what data retention applies, a fact invisible in the client and decisive in a dispute.

There is also the quieter inheritance: the other residents. Federation means the server’s other users share its reputation, and a domain known for a particular kind of account, bots, throwaways, a single tight community, colours how strangers read an address from it. None of this is visible in a directory listing, which is precisely why the listing is the beginning of the search and not the end of it. Public directories such as the service list at search.jabber.network are the equivalent of the estate agent’s window: useful for seeing what exists, useless for telling you what it is like to live there.

How do you observe before deciding?

The way the house guide observes: over time, and from the street. Watch a candidate server for a few weeks rather than an afternoon. Does it answer consistently, or does it vanish on weekends? Is there a reachable operator, an abuse contact, a status habit, any sign of the weekly attention described in the maintenance round? Do its published policies say what it keeps, and do they survive a second reading? A server that has run quietly for years is evidence; a server launched last month with generous promises is a listing, not a neighbourhood.

Latency and features matter, but they are the survey, not the viewing. The client feature list, history sync, uploads, encryption defaults, is covered in the checklist essay, and a server’s advertised compliance can be checked against it. What no compliance badge shows is the operator’s staying power, and staying power is read from the past: how long the domain has existed, whether the same people still answer, whether the announcements are dated and consistent.

Why does moving cost more than it looks?

Because an address is a social fact. Every contact who saved you@oldserver holds a pointer that a migration does not update, and every room membership, published avatar and stored bookmark follows the address, not the person. The protocol makes the account portable in principle and social reality makes it sticky in practice, which is the same arithmetic a house move runs: the furniture moves in a van, the life takes a year. Choosing the address well at the start is worth more than any feature a server offers afterwards.

There is also a second cost that only appears later: the old address does not die cleanly. A lapsed account on a domain that recycles registrations can be re-issued to a stranger, who then speaks with your old name to contacts who never learned you moved. The risk is small on a well-run server and real on a neglected one, and it is one more reason the observation phase favours operators who document how they retire accounts as plainly as how they create them.

The short version

Read the domain’s history before its features. Prefer a reachable operator to a polished page. Watch a candidate across a few weeks rather than at one visit, and treat its existing users as neighbours you will be introduced by. The client can be swapped tomorrow; the server is where the account lives, and a good address, like a good street, is mostly the product of somebody else’s unglamorous long-term care. The observation is the whole method, and it costs nothing but a fortnight of patience.