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

81–90 of 154 posts

Re: IPFS Project Roadmap

#81

Post by threeme3 »

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.

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.

Re: IPFS Project Roadmap

#82

Post by mirimir »

heyitsguay wrote: post #62
viraptor wrote: post #61

Earlier quoted context omitted.

> They aren't really nazis, right? At some point... is there a difference? If you find yourself in a group "ironically" screaming you all support X for long enough, soon you'll find that some of you actually support X. And that you enabled those people.

Well and besides, the actual content on the site seems to skew alt-right pretty heavily, whether the racial slurs and swastikas are ironic or not. Taken altogether, it paints a pretty clear picture of a voat-style forum that will alienate most other people if it stays that way.

They're there because they've been excluded from mainstream sites. It may seem extreme, but one way to assess how uncensorable something is by its content of stuff that you hate. Even stuff like child porn that any sane person would hate. So you just ignore it.

Re: IPFS Project Roadmap

#85

Post by AgentME »

paulsutter wrote: post #63

So I can store a file in ipfs by its hash, but there’s no way to link to the next version of the file. I can only link to older versions? I’m a giant advocate for decentralized architectures but so far I’ve never found a use for it that doesn’t rely on a centralized way to find out about new data

It doesn't have to be 100% decentralized to be useful though. A central server could be in charge of linking the hash to the latest ipfs directory of files. (Or they could use ipns, but let's ignore it for a moment.) But then all of the files are available from a decentralized cloud of users, from everyone running ipfs and hosting the content. And if the central server giving the latest hash ever goes down, people will still be hosting the files and people can find the latest directory hash elsewhere.

Re: IPFS Project Roadmap

#86

Post by aiNohY6g »

anandology wrote: post #57

In addition to apt and npm, I would like to see docker image distribution powered by IPFS. It really feels stupid to pull images from a central registry sitting on the other side of the globe when the image is already present in the next node in your kubernetes cluster.

https://github.com/miguelmota/ipdr

Re: IPFS Project Roadmap

#87

Post by troymc »

paulsutter wrote: post #63

So I can store a file in ipfs by its hash, but there’s no way to link to the next version of the file. I can only link to older versions? I’m a giant advocate for decentralized architectures but so far I’ve never found a use for it that doesn’t rely on a centralized way to find out about new data

A file in ipfs is stored/addressed by a hash of its content.

If you know the hash of the next version and put that in the file, then that hash will affect the hash/address of the file itself.

But the hash of the next version depends on the hash of the _next_ next version, and so on out to infinity... and you almost certainly don't know all those hashes, so you can't compute the hash of the next version, so you can't compute the hash of the current version, if it must contain the hash of the next version.

Re: IPFS Project Roadmap

#88

Post by gritzko »

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…

What you actually want is to break the universe. It is physically impossible to revoke information unless it happens by a strange coincidence. 24x7, you emit information that races away with the speed of light. You can't chase it down. Physically.

On the other hand, if you can decide which information stays, you essentially own the system.

So, given the project's mission, I guess it is a requirement that information stays online as long as someone somewhere is willing to keep it.

Re: IPFS Project Roadmap

#89

Post by philips »

marknadal wrote: post #15
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.

it is already here! If you use a mix of SSB, GUN, DAT, IPFS, & WebTorrent. SSB = Social-like P2P data. GUN = Firebase-like P2P data. SEA = End-to-end encryption. ( https://gun.eco/docs/SEA ) DAT = GIT-like P2P data. IPFS = Images/assets. WebTorrent = Video-like P2P data.

Are there example applications with some complexity on GUN?

Re: IPFS Project Roadmap

#90

Post by pault »

cortesoft wrote: post #71
mirimir wrote: post #69

Earlier quoted context omitted.

Sure, of course. But the problem is that if you can delete that stuff, someone else can delete stuff that you don't want to be deleted.

If you don't want something deleted, you can always keep a copy of it yourself.

Exactly. Which means you can't delete your bathroom video from any networked system. See the Streisand effect.
Post reply on HN