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

31–40 of 154 posts

Re: IPFS Project Roadmap

#31

Post by Risord »

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…

Managing universal data removal is not universally solved (or even wanted) on internet scale. So it sounds weird to demand it from technology which is trying to solve completely different problem.

Re: IPFS Project Roadmap

#32

Post by StavrosK »

aw3c2 wrote: post #27
hiccuphippo wrote: post #25

Earlier quoted context omitted.

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?

ipfs add -r mydir/

(Add a file to mydir/)

ipfs add -r mydir/

That's it, two different hashes, different contents, but intelligently deduplicated so you only need to download the diff if you already have the files in the former.

Re: IPFS Project Roadmap

#33

Post by StavrosK »

xj9 wrote: post #29
fwip wrote: post #20

Earlier quoted context omitted.

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 c…

Yeah but you can't add an episode to the torrent later and have all existing peers seed the old episodes in the new torrent automatically.

Re: IPFS Project Roadmap

#34

Post by OrgNet »

Razengan wrote: post #17
robto wrote: post #5

Earlier quoted context omitted.

That's what's got me excited - they've managed to articulate a vision for the future that I'm totally on board with: decentralized, privacy respecting, and user owned. I really want to see that vision become a reality.

For the internet to be truly decentralized, it needs to be so at the physical connectivity layer as well. Perhaps a worldwide swarm of drones creating a mesh network.

Solar powered drone planes would be nice... or maybe even a swarm of satellites will eventually be possible.

Re: IPFS Project Roadmap

#35

Post by georgyo »

hombre_fatal wrote: post #22
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.

This is a over simplification I think. In IPFS to add a file to a folder, you need to rebuild that folder which changes the address. You still need to get people to access the new address to see any updates. IPNS makes that fairly easy, but a similar technology could be made for bittorrent.

I think what makes IPFS interesting is that all files are like torrents and all folders all like torrents of torrents.

And since each torrent is a hash if the file underneath it, if 100 people individually add files or folders that contain identical chunks, then without explicitly doing anything the are so helping each other share those files.

Re: IPFS Project Roadmap

#36

Post by StavrosK »

fwip wrote: post #18

"2019 Goal: The most used code and binary Package Managers are powered by IPFS." That's kind of stupid-ambitious for 2019 when another 2019 goal is "a production-ready implementation" and IPFS has been around for 3 years already. This isn't a roadmap, it's a wishlist. And I'm someone who wants to see IPFS succeed.

The IPFS client is such an untunable memory hog that I turn it off whenever I'm not using it (which, of course, defeats the entire purpose). I would be ecstatic if we had something like the old uTorrent, but for IPFS. A nice UI, easy configuration, an ultralight implementation. It would be a dream come true.

Re: IPFS Project Roadmap

#37

Post by Risord »

fwip wrote: post #30
tick_tock_tick wrote: post #28

Earlier quoted context omitted.

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…

If soft delete is ok there is no problem. But should it be part of protocol or application layer is another question.

Re: IPFS Project Roadmap

#38

Post by Razengan »

OrgNet wrote: post #34
Razengan wrote: post #17

Earlier quoted context omitted.

For the internet to be truly decentralized, it needs to be so at the physical connectivity layer as well. Perhaps a worldwide swarm of drones creating a mesh network.

Solar powered drone planes would be nice... or maybe even a swarm of satellites will eventually be possible.

I'm picturing something more like bird-like or even moth-like drones, intelligently repositioning themselves to provide the widest coverage.

Satellites are too big of a target, and not very transparent; e.g. we wouldn't know if someone went up there and installed some snooping hardware. The same can be said about drones, but with proper swarms the chances of you connected to a compromised drone would be less.

Re: IPFS Project Roadmap

#39

Post by whyrusleeping »

techntoke wrote: post #2

Would love to see Arch/Alpine Linux repo move to IPFS by default. Would also like to see better integration with Git, and an SCM platform comparable to GitHub (or GitLab). That could really get the developer community heavily involved in the project if it was sponsored by Protocol Labs.

Yeah! That's a thing we're working towards. We're currently looking into apt and npm, both efforts are coming along pretty well and driving development towards fixing the bottlenecks preventing it from "just working".

https://github.com/ipfs-shipyard/npm-on-ipfs https://github.com/ipfs-shipyard/apt-on-ipfs

Re: IPFS Project Roadmap

#40

Post by microcolonel »

Discovery performance is the biggest issue I see. If I deliberately load the same file on a couple of peers, it can take hours (or forever) to be able to find a peer with that file to pin it. It is clumsy and difficult to explicitly connect to peers (because you can't just try to discover peers at an address, you need to include the node ID as well), and even if you manage to enter the right information, you won't necessarily succeed at connecting to the peer the first time.
Post reply on HN