Regarding Message Fastenings https://xmpp.org/extensions/xep-0422.html what if the message one wants to apply-to has only origin-id and not stanza-id? Does one use origin-id? https://xmpp.org/extensions/xep-0422.html What if it has both? Which id one should use to attach-to? stanza-id?✎
flow
my stance is that one can only reasonably attach to stanza-id using both the ID value and the value of 'by'
flow
note that there could be multiple <stanza-id/> extensions
flow
but at most one <stanza-id/> with the same by value✎
flow
but at most one <stanza-id/> with the same 'by' value ✏
flow
I also guess that you usually want to use the <stanza-id/> that was added by the service arbitrating the messages of the particular conversation. that is, use the MUC by if it's a MUC, and not the 'by' of your user account (archive)
Beherithas left
Beherithas joined
florettahas left
florettahas joined
machas joined
SouL
Regarding Message Fastenings https://xmpp.org/extensions/xep-0422.html what if the message one wants to apply-to has only origin-id and not stanza-id? Does one use origin-id? https://xmpp.org/extensions/xep-0359.html What if it has both? Which id one should use to attach-to? stanza-id? ✏
Beherithas left
paulhas left
paulhas joined
machas left
debaclehas left
Holger
SouL: Doesn't it already say "origin-id" (first sentence of #3.1)?
Holger
Though I thought origin-id was supposed to die!
Ge0rG
Holger: there is no consensus on that :(
marmistrzhas left
marmistrzhas joined
flow
I don't think missing consensus wrt the death or life or origin-id is the problem here. But Holger is right, xep422 § 3.1 specifies origin-id as anchor
flow
Even though I think it is dangerous, as it allows malicous entities to add duplicate, with respect to origin-id, messages into an archive, which makes fastening/attaching harder (select oldest message in case of duplicate origin-id?)✎
Ge0rG
I think we have a number of XEPs that use some sort of id to reference other stanzas, and that have different and conflicting rules on which id to use with which priority
flow
Even though I think it is dangerous, as it allows malicious entities to add duplicate, with respect to origin-id, messages into an archive, which makes fastening/attaching harder (select oldest message in case of duplicate origin-id?) ✏
Ge0rG
like 0184, which we are probably not going to get "fixed" anyway.
there are sure different rules about "referencing IDs"
flow
but hopefully there are no conflicting rules
Ge0rG
different _is_ conflicting
flow
yeah ok, if you think so. I would use the term "conflicting" if it where not possible to implement and use both approaches at the same time
Beherithas left
Ge0rG
I just think it would make sense to have a separate "The Art Of Message Referencing" XEP, that would be Standards Track and that all the others can reference for stanza referencing rules
Beherithas joined
flow
that I could very well agree with
flow
but I guess we don't have such a thing because nobody wrote a draft for discussion
flow
I am mostly concered that <origin-id/> is the wrong ID to use a anchor for referencing, amongst other things because of the reason mentioned above✎
flow
I am mostly concered that <origin-id/> is the wrong ID to use as anchor for referencing, amongst other things because of the reason mentioned above ✏
Ge0rG
I am concerned that <origin-id/> shouldn't have existed in the first place
flow
I honestly wonder why? While others also seem to like it that much that they use it for referencing
Ge0rG
because I'm on a quest to fix message @id
flow
ok, but even if you (successfully) worked on a better fix for the MUC reflection issue, that does not automatically mean that you have to condem everything else more-or-less related?
flow
I mean sure, origin-id originated more-or-less from the same issue, but that does not mean that it has not value in other areas too✎
flow
I mean sure, origin-id originated more-or-less from the same issue, but that does not mean that it has no value in other areas too ✏
marmistrzhas left
Wojtekhas joined
marmistrzhas joined
Ge0rG
flow: I know that we disagree on that, and I still fail to see that value.
flow
Ge0rG, ok, but you also see no active harm either, right? You may see passive harm in something being specified that has no value, akin to dead code in your codebase, that you typically want to get rid of. But I don't hink that dead code is our main issue within the XMPP specificiation zoo
debaclehas joined
Ge0rG
flow: it's not only dead specification and dead code but also dead XML on the wire
Ge0rG
and it's adding ambiguity because you now have at least three different IDs for a single message
Ge0rG
flow: which is also why I still insist on "The origin-id value MUST be equal to the stanza's @id attribute"
flow
I don't see how specifying that "origin-id == stanza @id" is sensible, you could simply omit the stanza id then✎
Ge0rG
As I said before, I don't see any value in signalling "I'm really generating unique stanza IDs", as the receiving entity must be able to do a graceful degradation anyway.
Ge0rG
flow: you could simply omit the origin-id then.
flow
I don't see how specifying that "origin-id == stanza @id" is sensible, you could simply omit the origin-id then ✏
flow
exactly
flow
(see my correction)
Ge0rG
Well, then why is it even specified? ;)
flow
arguing that dead XML on the wire is bad, while also arguing that origin-id should have the same value as something else within the same stanza is inconclusive
Ge0rG
flow: well, stream compression will allow to reduce the length then :P
Ge0rG
</s>
Ge0rG
flow: just remove <origin-id/> altogether and we are fine again :P
Ge0rG
My order of preference is:
1. No <origin-id/>
...
...
...
2. origin-id = @id
3. As it is now
Ge0rG
In terms of Council decisions that would probably be something like +1 / 0 / -1.
Ge0rG
(now would be a good time to vote me out!)
Zash
Ge0rG, you think 3 IDs are bad? I noted a week ago or something a message that had FIVE IDs, not counting @id
Ge0rG
Zash: that's quite a feat
Zash
Altho two were timestamps. (the same timestamp in different formats)