Possibility to run cafes on dynamic IPs

[ilyaigpetrov]

Is your feature request related to a problem? Please describe.

Opposition in authoritarian countries during important events (meetings, protests) faces all kinds of attacks on their means of communications. Among them:

1. Internet shutdowns so only few participants stay online with unstable connections,
2. Blacklisting of addresses (IPs, domain names) used to propagate information and censorship on providers level,
3. DDOS attacks, spam overflood.

The task is to create a chat room that is hard to get down or censor.

Describe the solution you'd like

1. Ability to spread chat rooms among as many participants as possible many of whom sustain cafes on dynamic IPs and also on public IPs when possible.
2. If it's already possible then add instructions here or to the docs describing approach to cafe setup needed to handle the problem stated.

Additional context

Slack logs:

ilyaigpetrov:

So one needs a static IP to run a cafe. Then if I develop an app for spreading news in China, they will easily block it by blacklisting ips of all cafes they know, with or without my app. Is this right?

sander:

The main reason to use a static URL is for the mobile background uploaders on iOS/Android. The coming 0.3.0 release brings desktop cafe connectivity back to peerID based. For mobile, there’s been talk of adding cafes to search so that you could do something like a cafe’s new URL discovery over pubsub.

ilyaigpetrov:

Hi. What are the plans for supporting cafes on dynamic IPs?

ilyaigpetrov:

I guess such dynamic ips will be anyway susceptible to DDOS attacks so we need a way of distributing one chat room to many hosts

carson:

With what @sander mentioned above, dynamic ips should be possible again, as the clients (mobile devices perhaps) could search by id rather than hit the ip directly... nothing specific on the way per se, but if this is something needed, would you mind filing a ticket with some details here: https://github.com/textileio/go-textile?

[sanderpick]

Here's what this looks like on v0.5.0 and above:

Desktop

All cafe communication is p2p based, with the exception of cafe-assisted search, which still utilizes HTTP for streaming purposes. We can remove this soonTM.

Mobile

All cafe communication that must continue in the background, like sync operations, are HTTP based, all else is p2p. In theory, it is possible to implement lower lever protocols in an Android background Service. It may be trickier on iOS, but I believe possible as well. I'd love some help here if this is something you're interested in.