-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
F2F low-diffusion filesharing app #961
Comments
This may be a better issue for https://github.com/ipfs/spec -- actually, maybe worth doing it in a https://github.com/ipfs/faq repo.
Yeah, IPFS is designed to solve this use case. (and others). The issues you track here are good. i imagine more things being needed to work really well. can already start on this. I should mention that we're interested in making this too, so probably should just work together.
Yep, precisely why Filecoin exists! |
I am very interested in such a feature. I have exacly the same requirements as @MichaelMure. In my mind, the most critical point to reach the "low friction" aspect is #875. |
Closing this issue as it's better suited elsewhere. |
This is a meta-bug that reference bugs that needs to be resolved for the following project. If it's not the good place for that, feel free to close it.
I would really like to see happen a friend-to-friend filesharing app with the following caracteristics:
The underlying goal is to reduce the need to use solution like Facebook, Dropbox, Drive... for file/pictures exchange that should be kept private. Also this.
IPFS seems to be the perfect backend for this project. What I envision is a thin GUI layer that provide the low-friction caracteristics. Most of the actual feature would be in IPFS. Here is the issues that needs to be resolved for this project to happen:
Optional:
On a side note, a problem that arise with low-diffusion filesharing is that sender and receivers need to be online at the same time. The future Filecoin seems to be a good solution to mitigate this problem as the sender could incentive other nodes to replicate and hold the encrypted blob online while he is offline.
The text was updated successfully, but these errors were encountered: