XSF Discussion - 2022-05-28

“14:51:45 jonas’> ok, can someone please load a module on this MUC server which sets origin-id to hello world for all messages? kthxbai”, I already have a poezio module for that, it broke Matrix.

Let’s load it. :)

Here, it is loaded.

Test.

If your client is displaying this message, it does better deduplication than just based on origin-id.

mdosch, poezio, not MUC.

Oh

Unless it got fixed recently, Matrix users won’t see my messages any more.

And from the discussion before, Converse won’t either.

Didn't work sorry

Ok plx thnx bye

Maranda, what didn’t work?

The last time it did, so perhaps you fixed it. :)

“14:56:08 Zash> Time to dig up the idea of IDs being based on a (stream-id, stanza-counter) tuple?”, that’s what we used to use in slixmpp, but people complained that it wasn’t unique enough. :<

Well it was predictable, mostly ✏

I'm not saying that would allow clients not to deduplicate still, but if we can avoid it..

It will break clients not Bifrost for sure

origin_id gets just stored, otherwise there's no processing on it

Bifrost cares about the stanza id attribute for deduplication not origin-id

So changing origin-id or stanza-id will do nothing changing the stanza id will get Bifrost to silently discard the messages until they fall off the deduplication cache hardly break anything

The problem as I see it is very simple, it's demented to have three different kind of ids for message stanzas (or any other kind), there should be only one which should be of (at least semi/simil-)unique nature

Doesn't Matrix have even more IDs?

Maranda[x], you don't say!

Maranda[x], now go and tell that to jcbrand ;) ✏

We need more IDs to keep up!!!

No Zash, all event ids are unique

(or was it timestamps?)

> > IDs being based on a (stream-id, stanza-counter) tuple > that’s what we used to use in slixmpp, but people complained that it wasn’t unique [or predictable] enough. :< But it would be guaranteed to be unique, since the stream id is supposed to be uniquely set by the server. Stuff the tuple trough HMAC to keep the stream ID secret, and the resulting ID shorter.

Also means you know what the ID will be ahead of time, without the server needing to tell you.

> <Zash> (or was it timestamps?) Probably timestamps, one is the original server timestamp the other is the age from the event processal when fetching batches from syncs or paginations ✏

Time-based uuids sound good enough and make collisions basically impossible, right?

I vote make it standard to use those for stanza-id and silently ignore origin-id

https://datatracker.ietf.org/doc/draft-peabody-dispatch-new-uuid-format/ FTR

Tho if you just say "use UUIDv7", that doesn't magically stop anyone from still setting the id to "lol", potentially causing havoc

Only the server can save us from that! :P

But who watches the server...

The server is perfect. The server always does the right thing. Trust in the server. The server is good.

Until it's wrong and doesn't do the right thing