XSF Discussion - 2022-08-16

edhelas, origin-id doesn’t bring any more guarantee than message@id, some people tried to give it additional meaning such as “it’s a UUID” or “it MUST be unique” but on the receiving end you can’t be sure of any of that, so those guarantees are moot.

The proper way forward would be to deprecate origin-id, and politely ask for message@id to be globally unique instead of per-stream, which most clients are doing anyway.

In slixmpp we already stopped including it anywhere, I would recommend that to other clients as well.

It was merely a hack for when MUC didn’t carry over message@id, but MUC has since been fixed to do so.

> what you see in the wild is messages with both message@id and origin-id, with the same big uuid > twice! If this is such a bad thing, one could have an empty origin-id that indicates that the message ID unique.

The whole id situation is frankly laughable. The ids literally take up more space than the data (the message) itself most of the time. What's the point in an ID then if you can just compare said data itself more efficiently than the ids? Not to mention the need for multiple IDs or ids at all wouldn't exist if messages were hashable, but they're not, because original xmpp developers wanted to overdose on XML

Hashes don't really solve the problem, and I don't really know many (any?) widespread protocols that do it that way

I don't think that having more metadata than the actual data is an issue. Just that as a developer I'd like some simple explanations on how to handle those IDs and here I have different behavior in different XEPs using the same base IDs :/

edhelas, any chance you can post a small overview of your woes to standards@?

I'll see if I can write an email about that yes

Having a nice discussion IRL for the next meetup with a review of all the related XEPs could be awesome as well :D

I'm only aware of two id-related issues: 1) origin-id is obsolete 2) clients don't know the archive id of their sent messages

To be clear, (1) is contested by some people

MattJ actually I think that the tools we have are good, the issue is mostly how we navigate through them. I'd prefer to have one simple flow in the 0359 and all the other XEPs that are simply saying "base the ID we're relying on on this thing".

Better then reinterpretating 0359 in the other XEPs like its done in Message Reactions and Message Replies

*than

Isn't the difference between id and origin-id that id is only unique to the stream whereas origin-id should be unique do the whole client/origin?

Either are set by the client

> Isn't the difference between id and origin-id that id is only unique to the stream whereas origin-id should be unique do the whole client/origin? The issue is the "SHOULD" ↺

edhelas: well you can *never* guarantee uniqueness. Bugs exist

Using origin-id may mean that the client promises to use a more unique id than if you only see <message id=''>

Zash: right, since it has to at least be unique across sessions

Whereas message@id is often just a counter

In what case would a client author choose to use 2 different types of id generation to send in the same message?

But the problem that tag was meant to solve was that conference.jabber.org would rewrite the message@id sent trough a MUC (because if you squint at it, the MUC is the sender)

I think that's a narrow interpretation of the use of oigin-id. What it also does, is give you a unique ID for the message, which message@id by itself isn't ✏

And yes it sucks that message@id isn't unique, but that's the way it is

At least until fairly recently, before I started using origin-id, I got bug reports because of clients that don't have unique message@ids

If a message had an element that said, my message@id is unique, that would also be a solution for me

As long as MUC sevices didn't rewrite it... ✏

jcbrand, but I don't understand - what do you do with those clients that don't send <origin-id> and have non-unique @id? I don't see how origin-id fixes anything for those clients. They still exist, and you still have to deal with them.

I fall back to heuristics, but I'd want to avoid that for messages where I don't have to. Also I know I can ignore messages from those clients when it comes to features that rely on XEP-359

you have to on all messages though, since origin-id might not actually be unique, since it comes from an untrusted source ?

moparisthebest: you check the `from` as well

jcbrand, but since you have to handle the scenario where any id you don't generate is non-unique, what does origin-id give you again ? just another id to check with no benefit seems like

if you leave and I `/nick jcbrand` and then reuse your origin-id or message@id, where is your glob then‽

moparisthebest: I consider the combination of origin-id and from to be unique.

Zash: that's where XEP-421 comes in

So really origin-id and occupant-id rather than from

Right