XMPP Council - 2023-02-23

But... do we need <good-id/>? What does it help, really?

I don't know if the additional semi-useless payload on every message stanza is worth it

exactly my question.

And I don't see how disabling features on messages that lack it is going to benefit the ecosystem

XMPP has a history of (rightly or wrongly) being called bloated, but mandating duplication seems a step in the wrong direction

<good-id/> would not carry an actual ID value, AIUI

and servers could translate <message id="$x"><origin-id id="$x"/></message> to <message id="$x"><good-id/></message> easily, fwiw

The current proposal AIUI is not to spec good-id but mandate origin-id == @id

Which I think is logically sound, only on the premise that we MUST have good-id at all

Which I dispute

I'm confused by the statement

Which one?

> Which I think is logically sound, only on the premise that we MUST have good-id at all

are you saying you don't see a need for the concept behind origin-id at all?

I am

why not?

I'd rephrase that as "the benefits of origin-id don't outweigh the drawbacks"

It was added as a workaround for one buggy MUC implementation that isn't even common on the network (and I think has been fixed now) ✏

Ge0rG [09:32]: > I'd rephrase that as "the benefits of origin-id don't outweigh the drawbacks" Sure, I can go with that

the rationale presented yesterday was that it's a marker to enable advanced functionality on the receiving side, like editing and referencing messages.

I see why people might want it, but not why we need it at this price

I think we can live with broken clients being broken

alright, fair

and the larger problem I see with that is that it will cut off many clients with good-enough @id's from advanced functionality

MattJ, thanks for clarifying

We have a slot for this already, we just need people to use it properly, which practically every modern implementation already does

But this is effectively giving up on it, adding a new duplicate slot to every message to fix a very minor uncommon issue

And we have to spend the next decades explaining to people why we did this

To be clear. I'm fine with killing it. What I said yesterday was meant as 'if we want to keep orgin id we should mandate message id==origin id'

Yes, I totally agree that it's the sensible way to do it, if we do it

I just really would rather we didn't

If it fixed a security issue, I could get behind it (or another solution)

so we do a Last Call, reject the XEP, remind the author to completely remove <origin-id>, and start from scratch?

No wait, we do an LC and MattJ writes those very eloquent words of rationale to the ML.

Happy to

MattJ: I hope you've copied that wall of text into a draft email already :D

I can do it when I'm at my laptop 🙂