3 ms·

>A lot of the content and data I consume on a daily basis is rarely-changing, so it would be fine to be immutable Would you want to see typos corrected, facts

>A lot of the content and data I consume on a daily basis is rarely-changing, so it would be fine to be immutable Would you want to see typos corrected, facts checked and other improvements on that content?

hobofan 7y ago
Would you want to see code you depend upon arbitrarily change, content you linked to become invalid through a 404, etc.? I didn't say "mutability needs to be completely eradicated". It's mutable-only (what we currently have) vs mutable-by-default vs immutable-by-default. Each of them has their own trade-offs.
- pfraze 7y ago
  FWIW Dat is going to add "strong links" in the near future, which are links that include a version & content-hash for pinning to a specific version.
  - hobofan 7y ago
    The end of my first comment explains why I don't think that's good enough: > Yes, I know that there are some fringe efforts to enable more immutability with "hypercore-strong-link" etc., but they look like an afterthought, that won't be supported by most of the Dat ecosystem if it finds major adoption.
    - pfraze 7y ago
      Why do you figure? If it's part of the protocol, wouldn't clients use it?
      - hobofan 7y ago
        Same reasons that you can't use many edge cases of email addresses (or even common "+"-addresses) with a lot of websites, even tough they are valid according to the spec: - Most developers don't read spec and add e.g. validations in end-user applications where they think they are being clever - Multiple fully fledged implementations of the core protocols are usually hard to come by. This means that rarely used features are that are not supported in all implementations won't be used and so organically wither
iamnothere 7y ago
You could simply make all content versioned, with a full history available. Browsers would probably want to show the "latest" content by default, but they could implement a function to view previous versions or even to highlight changes. Ideally versions would come with Git-style comments so you could read the reason for the change. This would provide an amazing archive for anyone wanting to see, for example, what was on a "front page" on a certain date. It would also let you see if someone had altered a specific article for whatever reason.
- kickscondor 7y ago
  This is true of Dat, though. You can jump back to a website’s prior history at any time, so long as those chunks are still seeded.
  - iamnothere 7y ago
    So in theory an archive.org type entity could continue seeding old versions of websites, allowing you to go back in time, and it could be verified that it was an older version? If so, that's a good compromise.
    - kickscondor 7y ago
      For sure! And the URLs aren't theoretical - you can view an older version of my own blog by adding '+version' to the end of the URL. Like so: dat://kickscondor.com+1600/. Each atomic file change creates a new version.

hobofan 7y ago

Would you want to see code you depend upon arbitrarily change, content you linked to become invalid through a 404, etc.? I didn't say "mutability needs to be completely eradicated". It's mutable-only (what we currently have) vs mutable-by-default vs immutable-by-default. Each of them has their own trade-offs.

pfraze 7y ago
FWIW Dat is going to add "strong links" in the near future, which are links that include a version & content-hash for pinning to a specific version.
- hobofan 7y ago
  The end of my first comment explains why I don't think that's good enough: > Yes, I know that there are some fringe efforts to enable more immutability with "hypercore-strong-link" etc., but they look like an afterthought, that won't be supported by most of the Dat ecosystem if it finds major adoption.
  - pfraze 7y ago
    Why do you figure? If it's part of the protocol, wouldn't clients use it?
    - hobofan 7y ago
      Same reasons that you can't use many edge cases of email addresses (or even common "+"-addresses) with a lot of websites, even tough they are valid according to the spec: - Most developers don't read spec and add e.g. validations in end-user applications where they think they are being clever - Multiple fully fledged implementations of the core protocols are usually hard to come by. This means that rarely used features are that are not supported in all implementations won't be used and so organically wither

iamnothere 7y ago

You could simply make all content versioned, with a full history available. Browsers would probably want to show the "latest" content by default, but they could implement a function to view previous versions or even to highlight changes. Ideally versions would come with Git-style comments so you could read the reason for the change. This would provide an amazing archive for anyone wanting to see, for example, what was on a "front page" on a certain date. It would also let you see if someone had altered a specific article for whatever reason.

kickscondor 7y ago
This is true of Dat, though. You can jump back to a website’s prior history at any time, so long as those chunks are still seeded.
- iamnothere 7y ago
  So in theory an archive.org type entity could continue seeding old versions of websites, allowing you to go back in time, and it could be verified that it was an older version? If so, that's a good compromise.
  - kickscondor 7y ago
    For sure! And the URLs aren't theoretical - you can view an older version of my own blog by adding '+version' to the end of the URL. Like so: dat://kickscondor.com+1600/. Each atomic file change creates a new version.