Skip to content
This repository has been archived by the owner on Mar 12, 2020. It is now read-only.

Cafe peers should optionally use IPFS Cluster #734

Open
sanderpick opened this issue May 3, 2019 · 1 comment · May be fixed by #831
Open

Cafe peers should optionally use IPFS Cluster #734

sanderpick opened this issue May 3, 2019 · 1 comment · May be fixed by #831
Labels
cafe Related to the Cafe Service on-hold waiting for an event to happen

Comments

@sanderpick
Copy link
Member

sanderpick commented May 3, 2019

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
@sanderpick sanderpick self-assigned this May 3, 2019
@sanderpick sanderpick added cafe Related to the Cafe Service discussion Open discussion Enhancement A new feature request or enhancement to existing feature Epic labels May 3, 2019
@hsanjuan
Copy link
Collaborator

hsanjuan commented May 4, 2019

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).

@sanderpick sanderpick added this to the Sprint 14 milestone Jun 12, 2019
@sanderpick sanderpick removed Epic Enhancement A new feature request or enhancement to existing feature discussion Open discussion labels Jun 12, 2019
@sanderpick sanderpick linked a pull request Jun 16, 2019 that will close this issue
1 task
@sanderpick sanderpick removed this from the Sprint 14 milestone Jul 22, 2019
@sanderpick sanderpick added the on-hold waiting for an event to happen label Nov 21, 2019
@sanderpick sanderpick removed their assignment Jan 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
cafe Related to the Cafe Service on-hold waiting for an event to happen
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants