Cafe peers should optionally use IPFS Cluster

[sanderpick]

Right now, an account peer can sync with a cafe peer. In terms of pinning/storage, this means:

• All threads and updates (including account-related thread for contacts, profile info) are synced (encrypted)
• All thread content (file DAGs) are synced (encrypted if schema dictates)

You can register with multiple cafes. However, this is a pretty poor method of achieving replication, putting extra bandwidth and load on (often low-power, mobile clients).

I have spoken briefly with @hsanjuan about embedding cluster in a cafe… Ideally we could support:

• textile w/ an IPFS node embedded for very easy config and deployment (this is the current setup)
• textile w/ an IPFS cluster embedded, requiring users to at least configure some additional IPFS nodes attached to the cluster
• textile w/ only libp2p services that communicates with an IPFS cluster's HTTP API, requiring users to also configure some additional IPFS nodes attached to the cluster

[hsanjuan]

Might be a really interesting thing with the upcoming "collaborative clusters" since configuration will be minimal and it pretty much allows you to have failover cafes (instead of running 1 cafe, run 2 and they keep their IPFS data magically synced regardless which one is taking the requests).