Hi all, it’s nice to be part of this promising project!
I am thinking of making an app based on IPFS.
Every user will run a node to store personal files that have been encrypted.
These files will be sporadically accessed only by their owner.
The goal is for these files to have 24/7 availability, even if the user’s node goes offline for a while of an unexpected reason.
The app will be used by an entire community.
So, is there a way to setup/customize IPFS to ensure full availability of personal files among a subset of nodes?
Is this possible without defining a specific community, but using the entire IPFS network?
Of course every user will be willing to offer local storage space by far larger than the space required by his own files.
i don’t reminder but i think ipfs have a params with pub-sub to “alert” networks change. After with ipfs and pud-sub feature it can possible to imagine a system
@stebalien thanks for the reply. the only thing about cluster that troubles me is the fact that adding/removing peers is said to be quite inflexible in order to maintain consensus.
for my usecase i would like the cluster management to be totally transparent to the users.
i wonder if joining a cluster can be configured to be fully automated and ofc decentralized.
@josselinchevalay if i got you right you are suggesting to use pubsub to inform nodes when a new file is added, so they can pin it. interesting idea, i will have to look into it.
it looks like some kind of custom clustering, only you 'll have to run your own code in every node.
Hi, we are planning on adding this to cluster, possibly leveraging pubsub. We call this feature collaborative pinsets and it’s planned for mid-term in our roadmap (https://cluster.ipfs.io/roadmap/)
Please consider the following scenario:
There is a community of people (users of a specific app, etc) who want 24/7 availability of their personal files.
If the community increases a lot, a plain collaborative pinset would lack performance if everyone’s files were replicated to all other peers.
I believe a concept of a replication factor would be usefull.
This factor would define how many copies of a file should exist in the network and could be set cluster-wide.
The factor’s value would be set according to the file availability level the community would like to achieve.
PS: Ofc the ideal would be to have such a feature in IPFS in general. I mean, to be able to store 1GB in 10 copies i should “donate” 10GB of my local storage to the network. But i guess that’s crazy difficult to implement.
But i guess that’s crazy difficult to implement.
@plexus yes, mostly because people can lie about how much space they’re offering and how many things they are replicating. This is where Filecoin comes in. Filecoin pretty much addresses those problems with the novel Proofs of Replication and SpaceTime.
Cluster will try to handle simpler usecases and not overlap with Filecoin, like notifying a group of people that they should pin a new Cid (or maybe notifying some of them only if we introduce some notion of replication factor). But cluster cannot enforce that non-trusted individuals will effectively back up anything. Thus, it will be more for semi-trusted or non-adversarial environments.
If you’re dreaming of a magical place where people will store your files for free, that will not happen.
If you think you can create a protocol where you would share a part of your filesystem with other people who would in turn share a part of theirs, then you’re up for a much much more complicated task than what you’re describing.
If you just want your files to be available 24/7, I suggest that you pay someone to host them. https://eternum.io/ is a good place.
@fiatjaf Yep, as i wrote before i know this is crazy difficult.
But its necessity is so obvious i’m curious why no one implemented it yet.
I know filecoin aims to fill this gap and i hope it succeeds, but not everyone is willing to engage in scenarios with token/coin logistics.
The ideal would be a tit for tat approach, my storage space for yours.
Who knows, perhaps filecoin will permit usecases with transparent handling of the tokens, time will tell.