4 ms·
What are the practical downfalls of this? Will my data be lost if the project is not popular enough? Is it possible for peers to modify the repository? Can I us
by vortico 8y ago
What are the practical downfalls of this? Will my data be lost if the project is not popular enough? Is it possible for peers to modify the repository? Can I use access restrictions? I'm talking about the `gittorrent://81e24205d4bac8496d3e13282c90ead5045f09ea/recursers` URLs, not the GitHub based ones.
- transfire 8y ago> Will my data be lost if the project is not popular enough? I'd like to know how that works out too. I suppose in the end it's up to you to make sure you keep a base copy of your project so it is always available, even if near zero popularity.
- cjbprime 8y agoI can think of a few interesting approaches: 1) We set up something like the Internet Archive, spidering and caching the network, run using donated bandwidth. The hosting could be centralized like the Archive or p2p itself (donated by peers). 2) A system like FileCoin's where you pay a tiny amount of money to ensure other peers will always host your repos on the network. 3) A straight up centralized, for-profit service where you pay a company a monthly fee to host your data on the network, as people already do with GitHub itself.
- fwip 8y agoPlease note that FileCoin doesn't provide any guarantees. It only provides incentives for other people to host your data. It's like paying a centralized service, except you don't have any recourse (legal or financial) if the people hosting it decide to stop.
- cjbprime 8y agoThanks for the correction. I guess you get a probabilistic "guarantee" in that you could see how many peers are serving your content at any given time, and make assumptions about their independence from each other and likelihood that your content will stay available?
- chriswarbo 8y ago> Will my data be lost if the project is not popular enough? P2P data access isn't about free storage (we're not all Linus ;) http://www.webcitation.org/6P8EBZqQX http://www.webcitation.org/6P8EBZqQX ): it's about decoupling data access from device access. Web addresses like `github.com/foo` make requests to a specific machine (github.com), in the hope that (a) that machine still exists and (b) it will respond with the data we were after. Content addressing (bittorrent, ipfs, dat, etc.) lets us request the specific data we're after. If the original host is still serving that data, it can fulfil the request for us; i.e. the existing Web setup will still work. The advantages are those situations where the Web model would break down. For example if the host changes its address without a redirect, if their layout/navigation changes, or if they disappear but someone else just-so-happens to have it (even us!). Many people focus too much on that last scenario. I think it's nice that with something like IPFS I can have a few flaky boxes serving my files, including a laptop that's often suspended/offline, and I don't need to care about failover, load balancing, etc. Plus I don't need to do anything specific to support offline usage from a local cache: those with the files can just serve themselves.