6 ms·

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" sh

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.

kreeben 11y ago
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.
- nanofortnight 11y ago
  ID is a hash of the content so that's not possible unless you find a hash collision (highly unlikely with sha256).
  - deleted 11y ago
    [deleted]
  - kreeben 11y ago
    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?
    - shocks 11y ago
      This is a really cool idea.
      - zardeh 11y ago
        Implement it as a merkle tree so that you can reference parents and know it will only evolve forward.
  - psykovsky 11y ago
    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".
    - nanofortnight 11y ago
      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.
      - fragmede 11y ago
        > 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 https://github.com/hundt/git-time-travel :p
        fordh 11y ago
        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 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.

kreeben 11y ago

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.

nanofortnight 11y ago
ID is a hash of the content so that's not possible unless you find a hash collision (highly unlikely with sha256).
- deleted 11y ago
  [deleted]
- kreeben 11y ago
  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?
  - shocks 11y ago
    This is a really cool idea.
    - zardeh 11y ago
      Implement it as a merkle tree so that you can reference parents and know it will only evolve forward.
- psykovsky 11y ago
  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".
  - nanofortnight 11y ago
    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.
    - fragmede 11y ago
      > 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 https://github.com/hundt/git-time-travel :p
      - fordh 11y ago
        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 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.