[jlund]

It's trivial to block several distributed hosts simultaneously. An aspiring censor would simply find the most common federated endpoints for a given service and block all of them. Only the users of that software would be affected. There wouldn't be any collateral damage.

If the censors somehow didn't hit every single worthwhile federated endpoint, users would still be left wondering why they couldn't communicate with most of their friends. Moving between federated hosts would also necessitate an entirely new identifier, so users would need to rebuild their social graph again.

In addition to being ineffective against censorship, there are several other properties and trade-offs that make federation a difficult proposition for an application like Signal: https://signal.org/blog/the-ecosystem-is-moving/

[seba_dos1]

> users would still be left wondering why they couldn't communicate with most of their friends

That's not how federation works, at least in XMPP. You only need to connect to one server that's out of censorships' reach to be able to communicate with everyone.

[jlund]

Let's say I have an account on a federated server and a censor then blocks my ability to access that server from my home country.

While it's true that my friends on other servers might be able to send messages that will arrive on my chosen server, that distinction isn't very meaningful because I am unable to connect and retrieve those messages.

I wouldn't be communicating with my friends until I switched to a new server and rebuilt my social graph.

[seba_dos1]

Rebuilding your social graph is easy - just import the roster and resend authorization requests as needed. The only inconvenience is a changed handle, so you have to point any potential new contacts to new JID.

Also, while it's not specified in XMPP (yet), it's easy to imagine a federated service that lets you connect to any server in the network that then behaves as a proxy to whatever server you have your account on.