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

101–110 of 154 posts

Re: IPFS Project Roadmap

#101

Post by feanaro »

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…

Removing comments from a comment page is not deleting content, it's changing it.

This page would be an IPNS address under the admin's control which would point to some IPFS hash representing the current goatse-containing state of the page. The admin would then create a new page, which would get a new IPFS hash (since it's new content) and point the IPNS address to it.

As it turns out, you cannot ever really delete information, you can simply change where your "well known" pointers point to.

Re: IPFS Project Roadmap

#102

Post by fjs11jx »

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.

That is _literaly_ what we already have. If you delete (unpin) content, others are free to keep it (pinned).

The OP was suggesting a way to delete things from other peoples machines.

Re: IPFS Project Roadmap

#103

Post by sideeffffect »

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.

It's a bit sad, that Dhall (programmable configuration language for YAML & co.) used to use IPFS for its source/packages, but stopped, because of reliability :( (I'm wondering if there are/were others?)

> Early on in the language history we used IPFS to distribute the Dhall Prelude, but due to reliability issues we’ve switched to using GitHub for hosting Dhall code.

http://www.haskellforall.com/2019/01/dhall-year-in-review-20...

https://github.com/dhall-lang/dhall-lang/issues/162

I wish IPFS the best, because at least in theory this seems like a perfect use case

Re: IPFS Project Roadmap

#104

Post by rnhmjoj »

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.

I would love to see IPFS used in projects like Nix, but in the current state it's downright impossibile.

I have seen IPNS taking between 5-10 minutes to solve a single address and go-ipfs with a few pinned files taking more that 5GB of memory after running for a day.

Re: IPFS Project Roadmap

#105

Post by setr »

nine_k wrote: post #51
Risord wrote: post #31

Earlier quoted context omitted.

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.

A best-effort deletion could be beneficial for any node. It reduces storage requirements a bit. A way to mark something as deleted, in a form of another ipfc object, could serve as soft delete, and also a permission to actually delete hunks of the object marked as deleted. This, of course, is not secure deletion, and should not be.

>A best-effort deletion could be beneficial for any node. It reduces storage requirements a bit.

As far as I'm aware, any node is free to delete its own data. In fact, isn't only storing data at the user's explicit request in the first place? It just can't do anything about what other nodes choose to keep or delete. If you're referring to a particular node wanting to delete do a best-effort deletion of data on other nodes, it's not clear to me why node A cares about reducing storage on nodes B, C and D (if you own those nodes, delete it yourself; if you don't.. then I don't know what you're up to)

Re: IPFS Project Roadmap

#106

Post by cjslep »

miguelrochefort wrote: post #55
ezoe wrote: post #54

IPFS is a joke. They have name lookup feature but relies on traditional DNS! What are they thinking? Also, if the IPFS's idea of working as local server is sound, BitTorrent DNA(browser plugin, steaming video over BitTorrent) should had been worked. It seems to me, they suffered NIH syndrome. They tried to reinvent the wheel. The P2P file transfer protocol over IP has already been covered by BitTorrent. What we need…

The real innovation is making files content-addressable.

Hate to break it to you, but Freenet has been doing that since the year 2000.

It's amazing how many things that are popular now are simply re-discovery of Freenet features.

Re: IPFS Project Roadmap

#107

Post by caprese »

nonsens3 wrote: post #21
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.

What is Swarm's intended incentivisation layer and where can I read about their plans? It seems like all documentation including plans are outdated, and I was ignored in their gitter chatroom where devs wanted to talk about dev things and outreach people seemed nonexistent.

I see things being stored on Swarm without incentives, like plain text

Re: IPFS Project Roadmap

#108

Post by caprese »

theamk wrote: post #77
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…

Does Swarm’s closeness with the Ethereum means it will be unsuitable for any tasks which do not rely on financial incentives? For example, if in the future debian is moved to IPFS, then many organizations are likely run local IPFS servers with Debian repos pinned. But if debian is moved to Swarm, I do not think that many organizations will be incentivized - the money are insignificant in the total spending, while eng…

Why do you think that it would be different?

"If Debian is moved to Swarm, then many organizations are likely to run local Swarm servers with Debian repos pinned"

Re: IPFS Project Roadmap

#109

Post by 0815test »

wehriam wrote: post #46
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…

> Old packages that you simply don’t want to version It’s important to think of IPFS as a way to share using content hashes - essentially file fingerprints - as URLs. Every bit of information added is inherently and permanently versioned. This is a tremendous asset in many ways, for example de-duplication is free. But once a file has been added and copied to another host, any person with the fingerprint can find it a…

> It’s important to think of IPFS as a way to share using content hashes - essentially file fingerprints - as URLs.

That's not at all unique to IPFS though - in fact, this is what the ni:// (Named Information) schema is supposed to be used for https://tools.ietf.org/html/rfc6920

(Depending on whether the hashes being used are properly filed with the NI IANA Registry, some IPFS paths might already be interconvertible with proper ni:// format, though with some caveats. sha256 hashes are definitely supported in both, though ni:// does not use the custom BASE58BTC encoding found in ipfs paths. Moreover, ni:// does not standardize support for file-level paths as found in ipfs, but does support Content-Type, which ipfs seems to leave unspecified. Files larger than 256k in IPFS are a whole other can of worms however, as you apparently lose the ability to lookup by sha256 hash of the whole content, and thus to properly interoperate with other mechanisms.)

Also, nitpicking but a content hash defines a URI not merely a URL, since its use is not restricted to looking up resources over a network.

Re: IPFS Project Roadmap

#110

Post by pdxww »

This is not a roadmap, but rather a wishlist. There is a fundamental problem that IPFS needs to solve first. This problem is called an efficient WebRTC-based DHT. In order to change the web, IPFS needs to become usable in the browsers. Since the backbone of IPFS is DHT, there need to be an efficient UDP-based solution for "DHT in the web". Right now this isn't possible and reasons are not just technical, but political. The IPFS team would need to convince all major players that enabling this DHT scenario is a good idea.
Post reply on HN