Federation trade-offs in self-hosted social feeds
A self-hosted social feed that only shows followed accounts is easier to reason about than one that also pulls in boosts, quoted posts, suggestions, and out-of-network resharing. Once the feed accepts remote content, the boundary moves from “who you chose” to “who someone else amplified”, which is a different social contract.
Chronological ordering helps here because it keeps ranking logic out of the middle. It also leaves less room for hidden discovery layers that broaden the social graph without asking. If the feed should stay narrow, the narrowness has to be enforced in the delivery path, not left to a settings page nobody checks twice.
Identity, trust, and who gets to speak in your feed
Federated identity is not the same thing as trust. A remote account can be valid and still be a poor fit for your feed, and a remote server can be well-run today and abandoned next month. Treat both as moving parts.
Keep the follow graph small enough to audit
A small follow graph is dull, which is the point. It gives you a chance to spot when a feed starts leaking in content from outside the expected set, whether through boosts, quotes, relays, or a plugin that got clever on your behalf. The larger the graph, the harder it becomes to tell whether a strange post came from a direct follow or from some federated side door.
For practical identity management, favour explicit follows over inferred interest. Suggested accounts, auto-joins, and “people you might know” features all widen the blast radius of one bad recommendation. In a self-hosted social feed, that is usually a nuisance first and a trust problem second.
Treat remote identities as untrusted until proven otherwise
Remote identities need a lower trust default than local ones. That does not mean blocking everything from outside your instance. It means assuming that metadata can lie, moderation history can be incomplete, and profile claims are cheap to fake.
The hard part is operational, not philosophical. If a remote user changes servers, deletes posts, or vanishes, your local view may still carry stale references and cached context. Verification, if it exists at all, should be narrow and boring: account ownership, posting permissions, and whether the source instance still behaves well enough to keep federating with.
Federation, moderation, and the bits that break in practice
Moderation looks tidy in policy text and messy in live traffic. Once content comes in from other servers, moderation becomes a moving target with delays, partial information, and failure to propagate. That is true even before spam gets involved.
Blocklists, instance rules, and the cost of keeping them current
Blocklists are only useful while they are current. Instance rules rot faster than people expect because federation changes the shape of the problem every time a server is added, renamed, merged, or quietly drops off the map. A rule that looked fine last month may now block the wrong place or miss the place doing the damage.
The cost is not just admin time. Each extra rule creates another thing to audit when a user says they can still see content they should not, or cannot see content they expected to. At some point, moderation turns into catalogue maintenance, which is a grim use of evenings.
Test the dump path, not the policy wording
Policy wording is cheap. Exporting the real moderation state is where systems get embarrassed.
Test whether you can dump blocklists, reports, local bans, muted accounts, and server-level exclusions in a form that survives a restore or migration. If the only working copy lives in the admin interface, the system has a single point of social failure dressed up as convenience. The same goes for federation logs and moderation notes. If they cannot move cleanly, they will eventually be lost, truncated, or ignored when the instance changes hands.
Data portability and privacy controls that survive real use
Data portability sounds neat until it meets partial exports and awkward history. Posts are the easy bit. Follows, bookmarks, mutes, blocks, and private preferences are where migrations start to look like archaeology.
Move posts, follows, and history without dragging in the whole mess
A usable export should move the account state that matters and leave behind the junk that only existed to make the old platform comfortable. That usually means posts, follows, blocks, mutes, and enough history to preserve context without exporting every draft, cache entry, and stale notification. Anything else tends to become baggage that slows a move and complicates import.
The main trap is trying to preserve everything and ending up preserving nothing cleanly. A portable account that restores badly is not portable, just awkward in a new place.
Keep local settings ahead of remote defaults
Privacy controls need to stay local. Remote defaults are useful only until they conflict with what the instance or user has already chosen. If boosts, quotes, reposts, public indexing, or contact suggestions are enabled upstream, local policy should still win.
That matters when federation imports content with its own assumptions attached. A remote server can expose more by default than your instance is comfortable with, and a sloppy import can quietly widen visibility after migration. Local settings should survive import, export, and reconnect without being reset to whatever the remote side considers normal. A privacy setting that only works before the first sync is decoration.
