XSF Discussion - 2021-04-21

gajim and dino's omemo has worked with each other, but they haven't worked with conversations.im

Also origin-id must die.

Ge0rG to be replaced by ?

top-level id attr

make origin-id == @id a MUST NOT

edhelas: the only information it coneys on top of @id is that the client honestly promises not to reuse @id values

Other than that, it's just xml bloat and additional complexity for people wondering which id to use

if only XMPP was one big centralized database

To be fair the real reasoning for origin-id is (was?) that some MUC services rewrote the top-level `id`, right ...

edhelas: you mean a gloablly distributed eventually consistent json graph database? geeeeet out!

Holger: yes, and we solved that root cause.

edhelas: use the @id attribute unless the specification you are implementing tells you which id to use.

Right. I just thought it might be useful to understand how we ended up here (e.g. to understand whether/why we can change/revert that idea again).

Unless it tells you to use origin-id, in which case still use @id

Holger: we ended up here because when 6120 was written, nobody expected we would have solved the "enough random data available" problem.

Plus (or mainly?) nobody anticipated real use cases for a proper ID.

When you fire and forget you don't need one.

Yeah, IQs weren't so important back then

They were, and what I said is true nevertheless 😉

edhelas: you need to design your receiver in a way that will gracefully degrade when somebody sends you non unique IDs, because you can't prevent it anyway.

Also if you receive stanzas with no ID, or if somebody is using auto increment integers and starts anew every few minutes

And if somebody claims they can guarantee sending really random IDs, I'll kindly remind them of https://android-developers.googleblog.com/2013/08/some-securerandom-thoughts.html

what about debian ? too old ?