-
Link Mauve
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.
-
Link Mauve
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.
-
Link Mauve
In slixmpp we already stopped including it anywhere, I would recommend that to other clients as well.
-
Link Mauve
It was merely a hack for when MUC didn’t carry over message@id, but MUC has since been fixed to do so.
-
jcbrand
> 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.
-
kurisu
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
-
MattJ
Hashes don't really solve the problem, and I don't really know many (any?) widespread protocols that do it that way
-
edhelas
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 :/
-
MattJ
edhelas, any chance you can post a small overview of your woes to standards@?
-
edhelas
I'll see if I can write an email about that yes
-
edhelas
Having a nice discussion IRL for the next meetup with a review of all the related XEPs could be awesome as well :D
-
MattJ
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
-
MattJ
To be clear, (1) is contested by some people
-
edhelas
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".
-
edhelas
Better then reinterpretating 0359 in the other XEPs like its done in Message Reactions and Message Replies
-
edhelas
*than
-
singpolyma
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?
-
Zash
Either are set by the client
-
edhelas
> 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" ↺
-
singpolyma
edhelas: well you can *never* guarantee uniqueness. Bugs exist
-
Zash
Using origin-id may mean that the client promises to use a more unique id than if you only see <message id=''>
-
singpolyma
Zash: right, since it has to at least be unique across sessions
-
singpolyma
Whereas message@id is often just a counter
-
moparisthebest
In what case would a client author choose to use 2 different types of id generation to send in the same message?
-
Zash
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)
-
jcbrand
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 itsel isn't✎ -
jcbrand
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 ✏
-
jcbrand
And yes it sucks that message@id isn't unique, but that's the way it is
-
jcbrand
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
-
jcbrand
If a message had an element that said, my message@id is unique, that would also be a solution for me
-
jcbrand
As longs as MUC sevices didn't rewrite it...✎ -
jcbrand
As long as MUC sevices didn't rewrite it... ✏
-
MattJ
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.
-
jcbrand
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
-
moparisthebest
you have to on all messages though, since origin-id might not actually be unique, since it comes from an untrusted source ?
-
jcbrand
moparisthebest: you check the `from` as well
-
moparisthebest
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
-
Zash
if you leave and I `/nick jcbrand` and then reuse your origin-id or message@id, where is your glob then‽
-
jcbrand
moparisthebest: I consider the combination of origin-id and from to be unique.
-
jcbrand
Zash: that's where XEP-421 comes in
-
jcbrand
So really origin-id and occupant-id rather than from
-
Zash
Right