I once solved a similar problem by creating a link at tinyurl and then updating that link to point to whatever the name of my uploaded file had become :)

Well, the site already uses DNS as an escape hatch for getting a pointer to content, so setting up a http-redirector might be a good idea...

This is a problem that Freenet solved a long time ago. It means you need public-key cryptography rather than hashes for security, but they support updating pages--and, of course, any and all leaf content can still use hashes for better cacheability.

Do you know about WebRTC and Webtorrent? You can do this even without a relay server. Just browser-to-browser.

It's worth noting that WebRTC still requires a server of SOME sort -- typically you want a "signaling" server, and you need at least a STUN server to pierce firewalls, though the latter can be found for free.

And some corporate networks are too restrictive to be pierced by STUN, which means you need a TURN server, which is a relay server.

But yes, 98% of the time, WebRTC can go directly browser to browser. As long as neither browser is Internet Explorer. Sigh.

These guys have an open source plugin that allows IE to join the webRTC party.

http://skylink.io/plugin/

This library they also have makes WebRTC cross browser compatible.

https://github.com/Temasys/AdapterJS

> As long as neither browser is Internet Explorer. Sigh.

If all popular torrent sites moved to in-browser downloads over WebRTC, virtually everybody would move away from IE :)

I never knew about STUN, this solves so many problems I've had. Thanks.

Is it even possible to open a socket from a browser to another browser directly? I was under the impression that was restricted for security reasons (websites becoming botnets and such).

I think you are correct, this appears to require a sever side element, I assume you don't have any real proof of deletion with something like this.

I have just written a library to make building something similar over webrtc easy: https://github.com/charlieschwabacher/ultrawave

An idea to make this(and the editable content suggestion in another comment) possible could be to add something to the protocol to define "previous versions" sha hashes. If you want to edit a page then create a new page which includes the sha hash of the previous versions. If you get a request for the content of a sha hash of an old version, you could suggest your sha hash as an updated version.

Or just send a new piece of content with the same ID and hope that it will win. But seriously, just a new created date. Same ID.

ID is a hash of the content so that's not possible unless you find a hash collision (highly unlikely with sha256).

Hmm, ok, but that is just an implementation detail. I just see a really simlple service here that could become really beautiful if one could manipulate the content, once it is in your browser, so the next time it is passed along, it will have evolved. Into what? I don't know. But what if I seeded the system with an image, a simple drawing or a shape, vector or whatever, and then just sat back, observed how other people took it further. Like graffiti. Forking of content could be insteresting. Or a github, but a peer-to-peer version?

This is a really cool idea.

Implement it as a merkle tree so that you can reference parents and know it will only evolve forward.

Doesn't git use hashes also? The old hash could redirect to the new "commit" hash, keeping the cycle and allowing for updates at the same time. One of those updates could be the page "changelog".

Yes, git does use hashes, but git similarly doesn't work in that manner for the same reason. Git commits can only point to commits in the past and not future commits. It is not possible to update old commits like you suggest.

The HEAD of a repository is like a pointer to the hash of a commit. You may think of HEAD like a repointable alias. `cat .git/refs/heads/master` in any of your git repositories to see what I mean.

> Git commits can only point to commits in the past and not future commits.

Not true! With git time-travel, you can refer to a future commits in the commit message. Eg:

    $ git log --oneline HEAD~2..HEAD
    9428c8c I am the child
    cdd3ab5 I am the parent of 9428c8 

https://github.com/hundt/git-time-travel

:p

Ha, that's a clever little tool!

For anyone curious, this uses the same idea as the "guess-and-check" approach spullara mentioned: https://news.ycombinator.com/item?id=953569

It changes the content of the commit (by iterating the hash in the commit message itself) until the hash of the child commit matches. A big part of the trick is that it only looks at a prefix of the hash, so the search space is much smaller than the full SHA1 hash.

I just used firebug to alter the page in my browser. I changed the first heading from "This page exists only if someone is looking at it" to "What happens if I use Firebug to alter this page in-situ. Do I end up with malware?".

Will this change propagate? Has anyone yet seen this modified page in their own browser?

Edit:

From the original page: "The server double checks the hash of the content it gets and then passes it along to the new person." I guess the answer is that the change won't propagate?

Correct, the change won't propagate for the reasons you say. (See source [0]). Also, though, note that the content comes to you as a blob of JSON, which gets rendered into your page, and you respond to future content requests with that blob of JSON, rather than the HTML itself.

[0] https://github.com/losvedir/ephemeral2/blob/master/web/chann...

Thanks for the explanation.

I found this line amusing.

>and you shouldn't be trusting me any more than any other random internet person.

Because I did trust you more than most other random internet persons, I trusted your javascript by temporarily whitelisting it in my browser to view the contents. :)

Are you able to adjust the url of the HN submission? I don't feel like creating one just to check, but that makes it easy to link the discussion, create the discussion before the page.

It seems ID's are assigned sequentially, so by timing your submission you should be able to get a predictable url.

No, but that would be the way to do it, for sure. There's a link to "edit" my submission, but the form it takes me to only allows updating the title. It displays the URL as ordinary text, rather than a text input.

We'll change the URL for you if you like.

I guess you'll need a fixed URL that redirects to the HN submission.

Ok I am at a loss here. Why can't you link this discussion on that page?

The web-pages are recognized by their hash, so you can't change them after you setup the page. The problem is that you would have to supply HN with the link to the page, and then go back and edit the page to include the link to the new HN article. Since you can't go back and edit the page, you can't include the link.

the hash is a hash of the content itself, so the link is immutable - if you changed the content the link wouldn't be pointing to the same thing anymore.

Changing the contents changes the hash and the hash is used in the url

Would a page be able to leave and come back into the network by having a computer that's offline but viewing the page and then comes back? i.e. is there anything to prevent it?

im not 100% sure how this all fits together, but you should be able to recreate a page, so long as the content was exactly the same, and therefor produced the same hash.

So you could set it up to automatically recreate the page when your machine comes back online.

is that what you meant?

Not quite but I assumed similarly. I'm wondering if it'll connect to the peers automatically after coming back online if just left in the browser. If it did then it'd be possible to keep a page unpublished except when asked for through another channel. It's definitely a really interesting idea to play with. It makes me wonder if it could be used to create a nicer interface for things like Freenet by doing more clientside these days.

I've actually seen people successfully get a tweet to link to itself through trial and error. You can try and guess the IDs and you will eventually get it right.

It's great! Will the client complain if it receives content that doesn't hash from a malicious client?

You'd have to be able to generate some pretty fantastically unique hash collisions!