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

141–150 of 154 posts

Re: IPFS Project Roadmap

#141

Post by momack2 »

woodandsteel wrote: post #131

I have a question for the IPFS people. I am a non-techy who really likes the IPFS idea and wants to see it succeed. However, whenever this topic comes up here at HN, we get a bunch of people who say they tried to use it but it was basically unworkable, like too much RAM usage and various sorts of failures. And rarely does anyone respond by saying that it is working just fine for them. So my question to the IPFS peopl…

As you seem to foresee - being "really usable" depends on the use case. The one we're focused on this year is package managers - and making IPFS work really well for that use case in particular. There is lots of room for improvement on performance and usability - setting the package managers goal gives us really a specific target to focus and deliver on. This won't solve "all the problems" (there's a lot to solve for package managers alone!) - but will help us take a big step forward in production readiness and hopefully knock out a swath of performance issues experienced by everyone.

Re: IPFS Project Roadmap

#142

Post by johnisgood »

StavrosK wrote: post #36
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.

What about Transmission? It seems much less bloated in comparison to uTorrent.

Re: IPFS Project Roadmap

#143

Post by StavrosK »

johnisgood wrote: post #142
StavrosK wrote: post #36

Earlier quoted context omitted.

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.

What about Transmission? It seems much less bloated in comparison to uTorrent.

I mean an IPFS client, not a torrent client. There are hundreds of those.

Re: IPFS Project Roadmap

#144

Post by hecturchi »

threeme3 wrote: post #81
StavrosK wrote: post #36

Earlier quoted context omitted.

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.

Exactly this: such an ultralight, accessible implementation would make it better suitable to run on embedded devices and mobile phones. And since we still live in as fairly disconnected world this is probably an area where IPFS can accelerate.

I kind of made this https://github.com/hsanjuan/ipfs-lite

May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).

Re: IPFS Project Roadmap

#145

Post by jonnydubowsky »

nmca wrote: post #127
marknadal wrote: post #124

Earlier quoted context omitted.

any links, please?

(Forgive janky thesis-ness) https://bit.ly/2P7w6cq

This paper is really well done. Im interested in seeing what comes of this. Going to spend some more time with it. Looks like you had the initial idea in 2011, ahead of its time. Well done.

Re: IPFS Project Roadmap

#146

Post by xj9 »

StavrosK wrote: post #33
xj9 wrote: post #29

Earlier quoted context omitted.

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.

you can only do that with IPFS keys that are aliased with IPNS which is equivalent to a BEP-46 mutable DHT key.

http://www.bittorrent.org/beps/bep_0046.html

Re: IPFS Project Roadmap

#147

Post by Grustaf »

miguelrochefort wrote: post #139
Grustaf wrote: post #114

Earlier quoted context omitted.

That’s just a dogmatic statement, you need to motivate it.

It's unreasonable to expect to be able to delete data that's been released publicly. Any attempt to delete arbitrary data will either fail or involve extreme authoritarian measures. Once you accept that, you can focus on reducing the output of compromising information, rather than trying to erase it after the fact. Prevention over cure. This will inevitably lead to a society where people do more of what society wants…

How does “should never be” follow from “difficult in practice”?

Re: IPFS Project Roadmap

#148

Post by Ericson2314 »

sideeffffect wrote: post #140
Ericson2314 wrote: post #48

If you want to do package managers, your #1 priority should be Nix. Don't do something more popular where you help less, go with the thing that you can really provide the killer missing feature. Nix + IPFS has been tried before, but what was missing is the Nix-side hierarchical content addressing of large data (not just plans). With the "intensional store" proposal, this should finally happen. Please push it along. D…

there's been some effort https://github.com/NixOS/nix/issues/859

Right but not connected to the intentional store.

Re: IPFS Project Roadmap

#149

Post by aw3c2 »

StavrosK wrote: post #32
aw3c2 wrote: post #27

Earlier quoted context omitted.

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.

That's not much different than changing my files, making a new torrent file with a small blocksize and having users use that.

What is the benefit here?

Re: IPFS Project Roadmap

#150

Post by StavrosK »

aw3c2 wrote: post #149
StavrosK wrote: post #32

Earlier quoted context omitted.

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.

That's not much different than changing my files, making a new torrent file with a small blocksize and having users use that. What is the benefit here?

That the old seeders can seed the new stuff without knowing about your new torrent.
Post reply on HN