[PATCH] UUIDv7 for MAM

7 views
Skip to first unread message

Stephen Paul Weber

unread,
Sep 25, 2023, 12:10:06 PM9/25/23
to prosody-dev
This patch set adds the ability to generate UUIDv7 to the util.uuid module, and uses it in mod_storage_internal and mod_storage_sql for the mam ids, setting the node portion to a merkel hash based on previous mam id and appended stanza id -- this allows verifying at any point that there is not a gap in the history.

Stephen Paul Weber

unread,
Sep 25, 2023, 12:13:06 PM9/25/23
to prosody-dev
Hmm, seems the UI here doesn't allow file attachments anymore, oops.  Here it is: https://0x0.st/HVAO.hg

Kim Alvefur

unread,
Sep 28, 2023, 11:40:19 AM9/28/23
to proso...@googlegroups.com
On Mon, Sep 25, 2023 at 09:10:06AM -0700, Stephen Paul Weber wrote:
>This patch set adds the ability to generate UUIDv7 to the util.uuid module,

I have a patch for this with wider Lua version compatibility,
timestamped 2021 that hasn't been merged because nothing uses UUIDv7.

>and uses it in mod_storage_internal and mod_storage_sql for the mam ids,
>setting the node portion to a merkel hash based on previous mam id and
>appended stanza id -- this allows verifying at any point that there is not
>a gap in the history.

While interesting, I feel like this is a layering violation. IDs
shouldn't have any semantics without additional negotiation.
>
>--
>You received this message because you are subscribed to the Google Groups "prosody-dev" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev...@googlegroups.com.
>To view this discussion on the web visit https://groups.google.com/d/msgid/prosody-dev/ab41c4ac-d01a-4079-ad0b-fa1c2f10e901n%40googlegroups.com.

Stephen Paul Weber

unread,
Sep 28, 2023, 11:52:59 AM9/28/23
to 'Kim Alvefur' via prosody-dev
>>and uses it in mod_storage_internal and mod_storage_sql for the mam ids,
>>setting the node portion to a merkel hash based on previous mam id and
>>appended stanza id -- this allows verifying at any point that there is not
>>a gap in the history.
>
>While interesting, I feel like this is a layering violation. IDs
>shouldn't have any semantics without additional negotiation.

Obviously the clients can't rely on this without some yet-to-be done disco,
but it's a valid way to construct the id either way and means that to enable
such feature becomes easy with discovery.
Reply all
Reply to author
Forward
0 new messages