3 ms·

> Which simply doesn't work because timestamps are not unique to location. Yes, I know. This is okay. Whatever time you think you wrote the message at is fine.

by btrask 11y ago

> Which simply doesn't work because timestamps are not unique to location. Yes, I know. This is okay. Whatever time you think you wrote the message at is fine. Even if your clock is off. Even if you lie. That is (part of) the message content (in this case). The time the message is sent is meaningless and can't be used, I agree. The time the message was written, or created, or "thought to be created" is what matters (or doesn't). > If your message isn't unique, the message you are replying to probably isn't either, so it's useless to use it as an identifier. Git does this and works great. If your entire message history (via hash chain) is identical, then you really do have duplicate messages. > UUIDs are unique identifiers, you generate them to label things that couldn't be distinguished without them. Content addressing is nothing more than summarizing a given object in a way that (almost certainly) preserves identity. So, one creates distinction, the other maintains identity. I agree, you're right. However, this is a feature.

zAy0LfpBZLC8mAC 11y ago
> Yes, I know. This is okay. Whatever time you think you wrote the message at is fine. Even if your clock is off. Even if you lie. That is (part of) the message content (in this case). Yes, it's part of its content, sure. That doesn't make it an identity of the event that originated it. > The time the message is sent is meaningless and can't be used, I agree. The time the message was written, or created, or "thought to be created" is what matters (or doesn't). But still doesn't provide an identity of the event. > Git does this and works great. If your entire message history (via hash chain) is identical, then you really do have duplicate messages. But that is simply because you have defined message identity in this context to mean just that, which is fine because of the semantics of the "messages" that git is made to manage. What it does not is provide identity of commit events. You can not, for example, implement a distributed counter in git that works by committing changes to a file that add a line with a number in it. If two git instances commit adding the same number based on the same parents at the same time with the same authorship information [...], the merge result might not reflect all counter increment operations that happened. > I agree, you're right. However, this is a feature. Well, it just is what it is, and each has its uses, but they are mostly orthogonal. It's just that when a UUID is part of an identity, summarizing that identity is easier done by dropping everything but the UUID instead of hashing everything.
- btrask 11y ago
  > You can not, for example, implement a distributed counter in git that works by committing changes to a file that add a line with a number in it. If two git instances commit adding the same number based on the same parents at the same time with the same authorship information [...], the merge result might not reflect all counter increment operations that happened. Yes. That's why content has to be defined at the application level, based on what the application is trying to accomplish. If absolutely every message is logically unique, then under a content addressing system each message needs to include some random data, which will result in random hashes equivalent to UUIDs. That is the worst case scenario for content addressing. Even so, it's still "as good or better" (aside from performance concerns, which I don't mean to dismiss).

by btrask 11y ago

zAy0LfpBZLC8mAC 11y ago

> Yes, I know. This is okay. Whatever time you think you wrote the message at is fine. Even if your clock is off. Even if you lie. That is (part of) the message content (in this case). Yes, it's part of its content, sure. That doesn't make it an identity of the event that originated it. > The time the message is sent is meaningless and can't be used, I agree. The time the message was written, or created, or "thought to be created" is what matters (or doesn't). But still doesn't provide an identity of the event. > Git does this and works great. If your entire message history (via hash chain) is identical, then you really do have duplicate messages. But that is simply because you have defined message identity in this context to mean just that, which is fine because of the semantics of the "messages" that git is made to manage. What it does not is provide identity of commit events. You can not, for example, implement a distributed counter in git that works by committing changes to a file that add a line with a number in it. If two git instances commit adding the same number based on the same parents at the same time with the same authorship information [...], the merge result might not reflect all counter increment operations that happened. > I agree, you're right. However, this is a feature. Well, it just is what it is, and each has its uses, but they are mostly orthogonal. It's just that when a UUID is part of an identity, summarizing that identity is easier done by dropping everything but the UUID instead of hashing everything.

btrask 11y ago
> You can not, for example, implement a distributed counter in git that works by committing changes to a file that add a line with a number in it. If two git instances commit adding the same number based on the same parents at the same time with the same authorship information [...], the merge result might not reflect all counter increment operations that happened. Yes. That's why content has to be defined at the application level, based on what the application is trying to accomplish. If absolutely every message is logically unique, then under a content addressing system each message needs to include some random data, which will result in random hashes equivalent to UUIDs. That is the worst case scenario for content addressing. Even so, it's still "as good or better" (aside from performance concerns, which I don't mean to dismiss).