3 ms·

No one is talking about ordering events.

by btrask 11y ago

schrodinger 11y ago
Pretty sure messages are ordered events in this scenario, no?
- btrask 11y ago
  They're events, but no ordering is assumed, guaranteed, promised, implied, or enforced. The timestamps, if you choose to use them, are only for determining message identity (equality) and thus can be as accurate or inaccurate as relevant for your application. You don't have to use timestamps if they don't make sense. For example, what is the "identity" of a message in an instant messaging program? If you just use the message content, then duplicate messages don't work. It would make sense to include the sender and the time written (which is different from the time sent!) as well. You might also include the recipient, depending. Note that instead of using timestamps, you could use the hash of the message being replied to. However, IM software usually doesn't have a system for real replies, so doing that properly probably isn't worthwhile. (Edit: however, hashes are very useful for systems like email, forums, etc., where reply targets are explicitly defined.) If you do want ordering, BYO. Content addressing and UUIDs are equivalent in that regard.
  - zAy0LfpBZLC8mAC 11y ago
    > The timestamps, if you choose to use them, are only for determining message identity (equality) Which simply doesn't work because timestamps are not unique to location. Every clock experiences every timestamp, and thus potentially assigns any timestamp to an event, so multiple clocks can end up assigning the same timestamp to distinct events, and thus identifying them. > Note that instead of using timestamps, you could use the hash of the message being replied to. 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. > If you do want ordering, BYO. Content addressing and UUIDs are equivalent in that regard. No, they are not, at all, they aren't even the same kind of thing. 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.
    - 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.
zAy0LfpBZLC8mAC 11y ago
... in which case my post explains why UUIDs are the better solution.
- btrask 11y ago
  Content hashing doesn't rely on timestamps to act as a unique identifier. It relies on all of the content, which may (or may not) include a timestamp, depending on your application. To the degree that collisions occur, that's a feature, not a bug. If you get undesirable collisions, you aren't hashing the right data. Edit: to clarify, content hashes are just like UUIDs except you can get useful collisions if you want them.

No one is talking about ordering events.

by btrask 11y ago

No one is talking about ordering events.

schrodinger 11y ago

Pretty sure messages are ordered events in this scenario, no?

btrask 11y ago
They're events, but no ordering is assumed, guaranteed, promised, implied, or enforced. The timestamps, if you choose to use them, are only for determining message identity (equality) and thus can be as accurate or inaccurate as relevant for your application. You don't have to use timestamps if they don't make sense. For example, what is the "identity" of a message in an instant messaging program? If you just use the message content, then duplicate messages don't work. It would make sense to include the sender and the time written (which is different from the time sent!) as well. You might also include the recipient, depending. Note that instead of using timestamps, you could use the hash of the message being replied to. However, IM software usually doesn't have a system for real replies, so doing that properly probably isn't worthwhile. (Edit: however, hashes are very useful for systems like email, forums, etc., where reply targets are explicitly defined.) If you do want ordering, BYO. Content addressing and UUIDs are equivalent in that regard.
- zAy0LfpBZLC8mAC 11y ago
  > The timestamps, if you choose to use them, are only for determining message identity (equality) Which simply doesn't work because timestamps are not unique to location. Every clock experiences every timestamp, and thus potentially assigns any timestamp to an event, so multiple clocks can end up assigning the same timestamp to distinct events, and thus identifying them. > Note that instead of using timestamps, you could use the hash of the message being replied to. 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. > If you do want ordering, BYO. Content addressing and UUIDs are equivalent in that regard. No, they are not, at all, they aren't even the same kind of thing. 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.
  - 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.

zAy0LfpBZLC8mAC 11y ago

... in which case my post explains why UUIDs are the better solution.

btrask 11y ago
Content hashing doesn't rely on timestamps to act as a unique identifier. It relies on all of the content, which may (or may not) include a timestamp, depending on your application. To the degree that collisions occur, that's a feature, not a bug. If you get undesirable collisions, you aren't hashing the right data. Edit: to clarify, content hashes are just like UUIDs except you can get useful collisions if you want them.