3 ms·

They say it doesn't solve the problem - "Would adding federation to Signal help with users behind country-wide blocks? Seems like a distributed service would b

They say it doesn't solve the problem - "Would adding federation to Signal help with users behind country-wide blocks? Seems like a distributed service would be harder to censor than a centralized one." - "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/" https://signal.org/blog/the-ecosystem-is-moving/" src: https://news.ycombinator.com/item?id=16868564 https://news.ycombinator.com/item?id=16868564

Boulth 8y ago
I think it may depend on how well distributed would a service be: having several big servers would not help but if every family and company had their own mini server, located in a non-censoring country then the censors would be unable to do anything easily. These servers, in turn, would be able to easily connect to the broader network. Of course that wouldn't be as easy to setup as a simple installation of the Signal app.
- jlund 8y ago
  An aspiring censor could also "easily connect to the broader network" and masquerade as a federated server in order to discover others. This process could even be automated. Federated services also require an identifier, and this identifier usually indicates where the user's account is located and how to connect with them (e.g. user@domain.com). As people share these identifiers, the aspiring censor can just keep adding new entries to the blacklist.
  - seba_dos1 8y ago
    At least in case of XMPP, the client doesn't need to be able to connect to other domains, so as long as you can connect to your own server outside of the censorship's reach (which could be accessible for c2s connections in a completely different way than for s2s), you should be fine.
    - Paul-ish 8y ago
      How do you ensure the censor doesn't block the major c2s connections? I suspect most techniques are too technical for your average user.
      - Boulth 8y ago
        Modern clients can connect via port 443. There is also support for XMPP via WebSockets, that looks like regular HTTPS traffic.
        majewsky 8y ago
        Sure, but they can just block the IP.
        Boulth 8y ago
        Yes, but it's always possible to block IP (targeted attack). Federated with a big amount of small servers make it hard to automate. You can block several hosts but the rest of the network would work fine. And because of how federation in XMPP works you just need a one client to server connection to reach the entire network.
  - Boulth 8y ago
    In XMPP you cannot easily enumarete other servers s2s connections. If the censor connects as a client he can only see their own contacts. As for sharing IDs if you post them publicly then of course they are revealed and can be blocked.
- s73v3r_ 8y ago
  When hosting one of those servers could potentially get limbs cut off, that makes it a much less attractive proposition.
seba_dos1 8y ago
It sounds like a hard thing, but in case of XMPP "rebuilding your social graph again" is very easy - it's just a matter of importing your roster and sending authorization requests where needed. Could be, and probably already is, easily automated with some user friendly tool.
- jlund 8y ago
  If the solution to censorship is to constantly switch to new hosts, it would be even easier to do this via a VPN (which wouldn't require you to rebuild your social graph at all, unlike a federated endpoint switch). If the more straightforward solution (VPN) isn't a panacea for censorship, then federation isn't either.
  - seba_dos1 8y ago
    Of course it's not a "panacea". It just makes some situations easier to handle, including server operator going rogue or broken by government. It doesn't magically provide answer to everything, but it's definitely an improvement when compared to purely centralized networks.
Arathorn 8y ago
I'm not sure this holds water, really - all you need to solve this is to allow identity to migrate between servers (by linking it to a keypair held by the user), or for that matter go the whole hog and go p2p rather than federated. Matrix is currently working towards transparent migration (account portability) between servers with p2p as a longer term target - and meanwhile projects like Status are going all the way to p2p today.

Boulth 8y ago

I think it may depend on how well distributed would a service be: having several big servers would not help but if every family and company had their own mini server, located in a non-censoring country then the censors would be unable to do anything easily. These servers, in turn, would be able to easily connect to the broader network. Of course that wouldn't be as easy to setup as a simple installation of the Signal app.

jlund 8y ago
An aspiring censor could also "easily connect to the broader network" and masquerade as a federated server in order to discover others. This process could even be automated. Federated services also require an identifier, and this identifier usually indicates where the user's account is located and how to connect with them (e.g. user@domain.com). As people share these identifiers, the aspiring censor can just keep adding new entries to the blacklist.
- seba_dos1 8y ago
  At least in case of XMPP, the client doesn't need to be able to connect to other domains, so as long as you can connect to your own server outside of the censorship's reach (which could be accessible for c2s connections in a completely different way than for s2s), you should be fine.
  - Paul-ish 8y ago
    How do you ensure the censor doesn't block the major c2s connections? I suspect most techniques are too technical for your average user.
    - Boulth 8y ago
      Modern clients can connect via port 443. There is also support for XMPP via WebSockets, that looks like regular HTTPS traffic.
      - majewsky 8y ago
        Sure, but they can just block the IP.
        Boulth 8y ago
        Yes, but it's always possible to block IP (targeted attack). Federated with a big amount of small servers make it hard to automate. You can block several hosts but the rest of the network would work fine. And because of how federation in XMPP works you just need a one client to server connection to reach the entire network.
- Boulth 8y ago
  In XMPP you cannot easily enumarete other servers s2s connections. If the censor connects as a client he can only see their own contacts. As for sharing IDs if you post them publicly then of course they are revealed and can be blocked.
s73v3r_ 8y ago
When hosting one of those servers could potentially get limbs cut off, that makes it a much less attractive proposition.

seba_dos1 8y ago

It sounds like a hard thing, but in case of XMPP "rebuilding your social graph again" is very easy - it's just a matter of importing your roster and sending authorization requests where needed. Could be, and probably already is, easily automated with some user friendly tool.

jlund 8y ago
If the solution to censorship is to constantly switch to new hosts, it would be even easier to do this via a VPN (which wouldn't require you to rebuild your social graph at all, unlike a federated endpoint switch). If the more straightforward solution (VPN) isn't a panacea for censorship, then federation isn't either.
- seba_dos1 8y ago
  Of course it's not a "panacea". It just makes some situations easier to handle, including server operator going rogue or broken by government. It doesn't magically provide answer to everything, but it's definitely an improvement when compared to purely centralized networks.

Arathorn 8y ago

I'm not sure this holds water, really - all you need to solve this is to allow identity to migrate between servers (by linking it to a keypair held by the user), or for that matter go the whole hog and go p2p rather than federated. Matrix is currently working towards transparent migration (account portability) between servers with p2p as a longer term target - and meanwhile projects like Status are going all the way to p2p today.