Hacker News new | comments | show | ask | jobs | submit login

To rephrase my comment:

Some disadvantage of OP's method:

- hash code is difficult to read for human. Urls under some hierarchy share some common patterns, it also bear some meanings. All hash code will look same and have nothing to hint on the content.

- You have to copy it, almost impossible to type it, or compare two visually similar string.

- You may end up with some link shortening service for hash code, but you can use link shortening to solve the portable file host problem already.

The Merkle Trees can solve some problems, but I don't think portable urls are the right one.

I agree 100%. Also, Merkle Trees would only benefit static content uploaded to the Internet. Updating any dynamic content would constantly generate a new root hash meaning a new URL with each update to that specific content. It's just not a good option for anything other than static content in general.

One place I could see it being valuable is with an online archiving type service like Archive.org where the content doesn't change except when a new snapshot of that content is recorded displaying any changes made to that content.

The way this is done in dat (via the hypercore module) is that the share key is a publickey, the merkle tree is signed with the private key. Updates can stream in on the log, and only the keys in the tree that have changed need updating. The history is stored in the log so you can retrieve any previous version.


I actually really like the idea of updating new hashes and etc. While I don't disagree with your statement, I definitely feel it's a challenge worth looking into.

Why? Well a lot of what I think is touted on the IPFS homepage, but to put it in my own words, I've become dismayed over how mutable the web is. It seems to entirely benefit those who seek to lie and disorient. Yet, if something from an "honest person" leaks onto the internet (nude photos, credit card, email, etc) it's nearly impossible to remove it.

This has less to do with the technology, and more to do with human nature. Facts are easy to mutate and spread misinformation about. Pages can be edited, blocked, DDOSed, etc. Yet often leaks of information that small actors, i.e. I upload my secret key, is basically permanently stolen on the web. So I feel like the mutable web is all cost to the public, with no benefit.

I feel/hope that IPFS and IPNS can allow for software to present a normal Reddit-like experience, where users never deal with weird hashes and etc, but underlying it all is an immutable and entirely audit-able paper trail. Information is key in this day and age, and if we can have an immutable web with no UX loss, I think it's a boon.

As it stands, people have identified trends among bad actors on the web - such as politicians botting Reddit to sway opinion, but the trail goes fuzzy quite quick when the entirety of the bots content can be deleted, mutated, etc.

Anyway, just sharing my thoughts / rambles.

I don't see how content addressing helps with leaks. If I have some stolen data I can distribute it with padding on the end so it has a different address faster than you can push out blacklists.

It doesn't - my point was that leaks (as in, anything of mine that gets out) already tend to be permanent on the web. Yet, news sites, botters on social media, etc - all change their content with no paper-trail for us to follow.

Anything I leak is basically permanent on the current web. If that's the case already, why would I want a mutable system in place where people can edit what they said? Alter what was posted, alter votes, take ddos content, etc.

I see. Thank you for clarifying.

Exactly! Editing content is the elephant in the room which author didn't even address

It was only a 10 minute talk, so I had to cut something out ;)

Blahah’s comment above may interest you:


Editing is easy, fwiw - content hashes are immutable and are not to be used for mutable content (obviously). That's why IPFS has IPNS - so we can have mutable pointers to data.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact