Decentralized networks facts: six behaviors of copied posts

Treat a federated post as a chain of copies, then choose the branch that matches what you need to decide. Locating the relevant server and action helps distinguish normal delivery limits from a local policy choice, without treating every difference as a fault.

If you need to follow one post to a reader

To trace a post, begin at its home server. An account address combines a local name with that server's hostname, and the server stores the account's posts and follower list. A follow request from another server reaches the home server; once recorded, that follower's server can receive later posts.

When the author publishes, the home server stores the post and sends a copy to each server with a follower of that account. There is one copy per destination server, not one per follower there. Each receiving server stores its copy in its database, subject to its operator's rules, retention choices, and backups.

Replies start on the replier's server, go to the author's server, and travel onward only where people at another server are involved. As a result, two participants can see different reply totals. Mastodon, Pixelfed, and PeerTube are examples of software run on separate, independently managed servers using this model.

The mechanics are public in a published specification. One widely implemented ruleset is the W3C ActivityPub recommendation; its delivery section states server behavior directly at each step. The W3C's Social Web Protocols note is a standards-body reference for this wider protocol setting.

That specification permits a server to send one copy to a shared inbox for every follower on the same server. It also says that once an activity travels from its origin server to a remote server, the protocol cannot force deletion of the remote copy.

• Rule of thumb: Follow the copies, not only the post on its home server.

If a post disappears, changes, or stays visible

If a post disappears, stays old after an edit, survives a block, or produces different reply counts, inspect which server received which request. Copy-based delivery can explain all six outcomes, including absent history and a server that drops out of view.

Deletion and edit requests go to servers that hold copies, rather than acting as commands with guaranteed reach. Most servers comply, but an offline, outdated, or unwilling operator may not. These outcomes follow from copy-based delivery, not necessarily faulty software.

• Rule of thumb: A request can reach copies without controlling what every server does.

If the conversation needs to stay private

If a conversation would be damaging if read by the people running both servers, do not put it in a federated direct message. In most systems, that message is an ordinary post with a restricted address list, traveling and being stored through the same delivery route as other posts.

That arrangement is not end-to-end encryption, and describing it that way can cause real harm. Some implementations provide sealed messaging and document it, so check their documentation rather than trusting interface wording. The message-sealing details clarify what that protection covers and leaves open, including an extra operator in the middle. The MLS specification is an official standards-body reference for messaging security.

• Rule of thumb: Assume both server operators can read a federated direct message unless the software documents otherwise.

If you are choosing a home server

If you are choosing a home server, identify the person or group behind it before judging the network. A server operator is a particular person or group, not an abstract policy; that relationship determines who holds your account and which local rules shape your experience.

Usually, the operator and funding of a server are easier to identify than the corresponding details at a centralized service. Your experience is therefore tied to one household or small group, rather than to an abstract network-wide policy. Consider that local relationship when judging whether the server suits you.

Network-wide removal is not in any one party's hands. Other servers can refuse to carry an account, and enough refusals can isolate it, yet it remains present and readable wherever servers have not refused it. Depending on which side of a harassment situation you occupy, that result may help or create a problem.

There is no reliable vantage point for counting the full network: each server sees a different portion, so a published total adds overlapping figures. The network cannot be measured as though every server supplied a separate, non-overlapping population count; any such total is built from partial views.

Hosting does not disappear with this architecture. Unless you operate the server, its operator holds your posts, your follow list, and your private messages, as a company would. A smaller operator changes possible failure modes, but it does not change the basic fact that someone else has your data.

Moderation also remains human work: reports must be read and abuse handled. A volunteer model spreads that labor among different people, but the work does not disappear. Volunteers can run out of capacity when the workload continues over time.

Audience size is not supplied by architecture either: a room still needs people to make it useful. That mismatch is a common disappointment, and the decentralized-network overview makes the same point in broader context without promising federation will create an audience.

• Rule of thumb: Judge a server by its operator, local rules, and limits.

If harassment is driving your decision

If harassment is driving the choice, block the person or the server as appropriate, but do not expect either action to remove anyone from the network.

Blocking is available at both levels; neither creates network-wide removal. That distinction matters because an account can remain visible on servers that have not refused it.

Federation offers different tools, not a reliably better outcome. Consider whether harassment comes from one place or several; the tools may help in the first case, while harassment from multiple places is harder to address. The source of the problem affects how useful blocking can be.

• Rule of thumb: Identify whether the problem comes from one server or many before relying on blocking.

If you need to know whether deletion worked

If you need to assess deletion, separate what your own server can do from what remote servers may do.

Deletion can be real on your server because you have a relationship with its operator and a right to ask. Other operators must honor a request elsewhere, although most software handles it automatically.

Treat a public post delivered widely as copied beyond your reach. This limitation is not unique to federation: the open web and centralized services also allow screenshots. A remote server may retain a deleted item if it has not processed the request, including when it is offline or its operator is unwilling; there is no dependable way to retrieve every copy.

You can only estimate destinations from the follower list that exists now. A server may retain a delivered copy after a follower leaves, and there is no dependable catalog of all places the post has reached. As a result, an author cannot identify every current copy with certainty.

• Rule of thumb: Assume a widely delivered public post may leave copies you cannot reach.

If you need to verify one particular network

If you need evidence about a specific network, read its protocol delivery specification, the reference software's moderation documents, and the rules of the server you are considering.

Together, these sources answer nearly every question for that network. If one is silent, record the gap rather than assuming the common behavior described here applies.

The mechanism-based classification sets out three questions answerable from those same sources. Answering them lets you predict most of the outcomes above without relying on a general description of federation or taking an operator's claims on trust.

Rules vary because no network-wide policy exists: every server publishes its own terms, while delivery is the shared mechanism. There is no larger rules document to appeal to. Finding people is a separate question, since search and discovery in a federated network follow their own behavior.

• Rule of thumb: Check the specification, software documentation, and rules of the server you are considering.