Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IPFS Project Roadmap

github.com

Post reply on HN
Print view View original

21–30 of 154 posts

Re: IPFS Project Roadmap

#21

Post by nonsens3 »

caprese wrote: post #11

I've been considering Swarm distributed file system because of its closeness with the Ethereum development. It seems to do the same thing and works already but hardly gets any press. IPFS and the Protocol Lab's Filecoin sale seemed to generate a lot of marketing despite it becoming clearer later that Filecoin is for an unrelated incentivized network. It is hard understand the pros and cons of choosing to use IPFS ove…

Swarm and IPFS together with Filecoin try to address the same problem - persistent data storage in a decentralised network.

Swarm is not at all "working already" - the incentivisation layer for nodes to store data for other users is not implemented and currently mostly theoretical and work-in-progress.

IPFS is more mature in comparison to Swarm, but the underlying architecture is rather different.

Re: IPFS Project Roadmap

#22

Post by hombre_fatal »

0xb100db1ade wrote: post #16

I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?

One practical difference is that all the parts of a "collection" are individually addressable in IPFS.

For example, unlike torrents, you can seed a collection like "My Web Show (All Seasons)" and add new files as new episodes become available. With torrents, you have to repackage them as new torrent files. IPFS also then encourages file canonicalization instead of everyone seeding their own copy of a file.

Re: IPFS Project Roadmap

#23

Post by nonsens3 »

dymk wrote: post #9
fiatjaf wrote: post #7

Earlier quoted context omitted.

Dynamic content is not the problem. I don't want dynamic content. I think HTTP and servers are the way to go on dynamic content. I just tried, for years, to use IPFS as a way to distribute static content (you know, stuff that will never ever change, even if that stuff is referenced from a dynamic location), and the problems I encountered were so many I finally gave up. I would love to see all these problems solved an…

If you want IPFS to be a replacement technology for the web, you need dynamic content. Else, it's a useful static content distribution network, but it's not "the web", not even in the sense of what the web was in the 90s, or the "web" any more than Bittorrent is. Now, obviously, they're under no obligation to deliver anything. But I'm trying to understand what you mean when you say: The vision of a IPFS-powered web w…

I don't want to hijack the discussion from IPFS, but Swarm has good ideas with respect to dynamic content if you're interested how that might work in a decentralized setting, for example see Swarm Feeds presented here: https://www.youtube.com/watch?v=92PtA5vRMl8

Re: IPFS Project Roadmap

#24

Post by fwip »

marknadal wrote: post #13
dymk wrote: post #6

Earlier quoted context omitted.

I see this comment often when IPFS is discussed - but the devil is in the details when it comes to replacing the underlying tech of "the web" with something else. How does an IPFS powered website do dynamic content? User sessions? Is all the client's session data encoded in the IPFS address itself? Even if there's no user sessions, but the page content updates, how do you continuously point clients to fetch the right…

For dynamic data, you need to use a CRDT system like GUN ( https://github.com/amark/gun ). For instance, see P2P Reddit ( http://notabug.io ) which: - Running in production with GUN. - Handling about 42,000 monthly visitors. ( https://www.similarweb.com/website/notabug.io ) - Has done ~1TB in 1 day of decentralized traffic. You can then configure GUN to save to IPFS as the blob/storage engine (or we have filesystem,…

It's a shame that so many P2P advocates - or at least the ones using the stuff built with P2P tech - are very loud alt-right types.

I popped on notabug.io just now, and the chat is full of swastikas, racial slurs, and the most up-voted posts are primarily anti-gay misinformation.

I see you wrote GUN, which I'm sure was no small feat, and it looks like an impressive piece of technology. How do you feel about your tech being primarily used in this way?

Re: IPFS Project Roadmap

#25

Post by hiccuphippo »

0xb100db1ade wrote: post #16

I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?

Think of torrents that you can update: You have the magnet link for the one version you are downloading, but also you have available the magnet link for the current version so the uploader can update at anytime and you would receive the update. And if both versions share some pieces, then people can share them across both torrents, and any other torrent that happens to have a piece with the same hash.

Re: IPFS Project Roadmap

#26

Post by viksit »

One of the biggest challenges with IPFS in my mind is the lack of a story around how to delete content.

There may be a variety of reasons to delete things,

- Old packages that you simply don't want to version (think npm or pip)

- Content that is pirated or proprietary or offensive that needs to be removed from the system

But in its current avatar, there isn't an easy way for you to delete data from other people's IPFS hosts in case they choose to host your data. You can delete it from your own. There are solutions proposed with IPNS and pinning etc - but they don't really seem feasible to me last I looked around.

This list as @fwip said is great as a wishlist - but I would love to see them address some of the things needed in making this a much more usable system as well in this roadmap.

Re: IPFS Project Roadmap

#27

Post by aw3c2 »

hiccuphippo wrote: post #25
0xb100db1ade wrote: post #16

I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?

Think of torrents that you can update: You have the magnet link for the one version you are downloading, but also you have available the magnet link for the current version so the uploader can update at anytime and you would receive the update. And if both versions share some pieces, then people can share them across both torrents, and any other torrent that happens to have a piece with the same hash.

I would love to try that, can you share a quick and easy breakdown of how I would do publish that?

Re: IPFS Project Roadmap

#28

Post by tick_tock_tick »

viksit wrote: post #26

One of the biggest challenges with IPFS in my mind is the lack of a story around how to delete content. There may be a variety of reasons to delete things, - Old packages that you simply don't want to version (think npm or pip) - Content that is pirated or proprietary or offensive that needs to be removed from the system But in its current avatar, there isn't an easy way for you to delete data from other people's IPF…

I doubt there will every be a way to delete content as every legitimate method of deleting will be commandeered for censorship. Even if they did add something you can never really know the other nodes actually deleted it.

Re: IPFS Project Roadmap

#29

Post by xj9 »

fwip wrote: post #20
0xb100db1ade wrote: post #16

I love the idea of IPFS, but I can't think of a use case not covered by torrents. Would someone mind enlightening me regarding what sets IPFS apart from torrents?

Main feature is automatic data-sharing between distributions. With torrents, everything is siloed, and data is only exchanged between peers of that torrent. IPFS doesn't care /why/ you're getting information or the link you found it from, just that it can find it by its hash. Say you distribute "Julie's Webcast Complete Series" and somebody else distributes "Julie's Webcast - Episode 3, with Russian subtitles," peers…

this is an implementation detail of the DHT client. if you have enough cooperating bit torrent clients set up to seed a sparse swarm like IPFS does, you could do the same thing.

which begs the question, why fork the DHT in the first place? there are BEP drafts that cover all of the features that IPFS (and DAT for that matter) bring to the table.

my guess: there isn't a lot of money in making yet another bit torrent client.

Re: IPFS Project Roadmap

#30

Post by fwip »

tick_tock_tick wrote: post #28
viksit wrote: post #26

One of the biggest challenges with IPFS in my mind is the lack of a story around how to delete content. There may be a variety of reasons to delete things, - Old packages that you simply don't want to version (think npm or pip) - Content that is pirated or proprietary or offensive that needs to be removed from the system But in its current avatar, there isn't an easy way for you to delete data from other people's IPF…

I doubt there will every be a way to delete content as every legitimate method of deleting will be commandeered for censorship. Even if they did add something you can never really know the other nodes actually deleted it.

Sometimes, censorship is good. For a silly example, if somebody somehow filled this comment section with images of goatse, it would be nice if we could take that down.

I definitely agree from a technical level, you can't ever guarantee the deletion of files on somebody else's machine.

So the question is, how do we build systems that enable users to protect their communities, without them becoming yet another tool for abuse?

Post reply on HN