Hacker News Reader

Comment by bencoder | Hacker News Reader

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.

View on HN

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

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.

Reply on news.ycombinator.com