XMPP Council - 2025-01-07

Good morning. It’s time

1) roll call

👋

Here, Happy New Year!

👋

2) Agenda Bashing ✏

I need to bash my own agenda a bit because I'd like to add "issung last call on fast" to the agenda

3) Editors update

✏

* NEW: XEP-0501 (Pubsub Stories) https://xmpp.org/extensions/xep-0501.html * NEW: XEP-0502 (MUC Activity Indicator) https://xmpp.org/extensions/xep-0502.html

hello​

4) Items for voting

a) Move 'XEP-0421 (Anonymous unique occupant identifiers for MUCs)' to stable https://xmpp.org/extensions/xep-0421.html

+1

+1

+1

The concerns of dwd have not been adressed on list

I was typing that

regarding the "SHOULD"

Ditto

I would like to see them addressed before approving the move to stable. ✏

So I'll wait next week to cast my vote.

b) Move 'XEP-0424 (Message Retraction)' to stable https://xmpp.org/extensions/xep-0424.html

I have significant concerns about this one

(author hat on 0421): I should reply on the mailing list, but I don't think there are any actions that I want to take from Dave's comments ✏

I'll be on list. for XEP-0424.

I assumed the SHOULD in occupant-id was that adding a per-MUC secret was too difficult; but I think that's mitigated by my concrete suggestion of HMACs involving the MUD jid.

larma, no worries, but the message needs an answer IMHO.

> I assumed the SHOULD in occupant-id was that adding a per-MUC secret was too difficult; but I think that's mitigated by my concrete suggestion of HMACs involving the MUD jid. In short: In some situations, consider e.g. spaces, using the same occupant id across multiple rooms might be beneficial, it would seem weird to not allow that. ↺

larma, Given that's not at all what I expected, I would suggest some explanation. (Or a MUST-unless).

I’m +1 wrt xep-0424; despite some people thinking that LMC can also retract messages there seems to be enough interest from the rest of the community in this xep

I agree that the community interest probably trumps my concern about the overlap, but I'm also concerned about the id in use being different

I think 424 has some unresolved threads too? Blame dwd again?

I understand that some MUCs won't work with message@id but also some won't work with stanza-id and I think being consistent with LMC has more value than picking a second requirement

> larma, Given that's not at all what I expected, I would suggest some explanation. (Or a MUST-unless). We can add language to warn about the consequences if that's what you are after, so that server implementors don't go against the SHOULD (which they never should), except they really want to? ↺

My comments were queries rather than objections, but I would love to see us get rid of origin-id, since it seems like a wart.

> We can add language to warn about the consequences if that's what you are after, so that server implementors don't go against the SHOULD (which they never should), except they really want to? That would be fine by me. ↺

> My comments were queries rather than objections, but I would love to see us get rid of origin-id, since it seems like a wart. 👍 ↺

I think I'd prefer to wait a week on this one too, to see if we get movement on the standards list

(which by the way is only readable for me via the archive, since 90% of emails are thrown away due to DMARC and other enemies of mailing lists)

hmm, strange, everything from our mailing lists should pass DMARC​

but maybe some legacy filters out there

+1 to removal of origin-id from the sideline

I missed the origin-id bit. I’m actually in favor of that too

ok. I’m going to extend the LC for both of these by two weeks.

👍

I'd like to point out that the origin-id bit is widely implemented by clients.

I usually try to avoid that because it often leads to LCs being forgotten (see the fact that the occupant-id one was actually running for a couple of months)

It's too hard explaining to people why XMPP has 4 ids, I'd much rather have to explain why we have 3 and save my breath on why origin-id is just in case of this one weird client from 2006 that two people are still using.

but it looks like we have a decent plan of action here

daniel, don't we have still one week for both LCs?

+2 to removal of origin-id from the sideline :)

I'd love to get rid of origin-id, but that doesn't seem trivial at this point. Many clients have a logic that origin-id overrides message@id for most purposes.

larma, yes origin-id is implemented by some clients. but most clients set it to equal to the message id (the id on the message stanza); so just using that should be fine

in 1:1

so the plan forward for retraction would be to use message@id in 1:1 and stanza-id in MUC?

I agree that nowadays message@id is probably safe to use again, now that most clients that did shenanigans with it are end-of-life

I'd like to see it use message@id everywhere​

stanza-id in MUC does serve a purpose, because the MUC is the distribution point.

it serves a purpose in general for sure, but it's not needed for this particular case

Yes, stanza-id good, origin-id legacy-workaround.

and that would be consistent with display markers and reactions and stuff

Which 'that', Daniel? :)

out of curiousity, for which client was the origin-id done?

Kev, That which?

> it serves a purpose in general for sure, but it's not needed for this particular case Using message@id in MUC would mean that for purposes where you need the room-wide unique id, you need a second id. Better to always use the same id ↺

Goffi: None in particular, just that message ids were originally usually implemented as counters. ✏

'that' meaning message@id for 1:1 stanza-id for muc

> Goffi: None in particular, just that message ids were originally usually implemented as counters. counters that reset after restart, so clients would use the same ID again ↺

Goffi: None in particular, just that message ids were originally usually implemented as counters. So they were widely unusable for lots of things, as well as nasty leaks. ✏

>> it serves a purpose in general for sure, but it's not needed for this particular case > Using message@id in MUC would mean that for purposes where you need the room-wide unique id, you need a second id. Better to always use the same id what purposes? ↺

goffi, Aside, but I ran into a fascinating problem with a customer who relied on message@id being globally unique, which broke horribly with Psi, which reuses id sequences on multiple accounts.

> what purposes? reactions for example, I can react to other users' messages. ↺

sure, reactions is a totally different case

Other than needing to refer to the ID of a previous message :)

if it can be sent by someone other than author it needs different handling

but LMC and retraction are both author only and so the author referring to their own chosen id works out

100% agree, my point is that its really not nice to ask people to store 2 ids for all messages, one for retraction and one for reactions.

Kev, Other than the ways they are similar, they are different though.

> 100% agree, my point is that its really not nice to ask people to store 2 ids for all messages, one for retraction and one for reactions. Well, they need the other id anyway. for LMC at least, but also for other things in a MUC context (such as to detect reflections) ↺

reflection detection is only relevant for messages that you send, not for receive

and LMC is very legacy, that's why it didn't consider problems of using message@id in MUCs and is only meant to only edit the last message ✏

Well, that and that the problems don't affect its use case, right?

Should some of this be on the standards mailing list conversation?

> Should some of this be on the standards mailing list conversation? probably yes ↺

Certainly yes :)

yes I was trying to let this discussion play out in the hopes that we can get back to the author with some clear guidance. but if council doesn’t agree with themselves then we need to bring this back to the list

(Aside: I would love to collect some of this info/pitfalls and document them)

moving on then

> Well, that and that the problems don't affect its use case, right? If you write a message with id=1 in a MUC, leave the room, someone else joins using your nick and writes another message using id=1 and leaves again, how do you use LMC to edit your last message? ↺

c) Start Last Call on 'XEP-0484: Fast Authentication Streamlining Tokens'

+1​

+1

> c) Start Last Call on 'XEP-0484: Fast Authentication Streamlining Tokens' +1 ↺

(Other aside: I really appreciate the proactivity in seeking things to move along the Standards track)

+1

+1

5) Pending votes

none

6) Date of Next

+1w wfm

+1w wfm

daniel, Small AOB: Could people look at those process edits I've been working on? Affects Council more than anyone else, really.

+1w wfm

+1w wfm

But will miss +2w

7) AOB

just a question:

do you want to provide some links for that dwd?

do we have a minimum number of feedback required for LC ? After a quick glance I haven't seen anything about that in XEP-0001

They're all on the mailing list thread.

So what happens if nobody give feedback?

> do we have a minimum number of feedback required for LC ? After a quick glance I haven't seen anything about that in XEP-0001 There is no minimum feedback; Council people are welcome to assume no feedback means either no objections or no interest in advancing. ↺

OK

fine then.

any other aob?

None

nope

assuming none

8) Close

thank you all

see you next week

Thanks daniel, thanks all.

> do you want to provide some links for that dwd? https://github.com/xsf/xeps/pull/1407 // https://github.com/xsf/xeps/pull/1412 // https://github.com/xsf/xmpp.org/pull/1466 ↺

> 6) Date of Next Looks as if I might have a doctors appointment around +1w, but maybe will be able to join nonetheless. ↺

larma, does dino (or any other client that you are aware of) send different message@id and origin-id?

No, but if they would receive different origin-id and message@id, they would use origin-id right now

i mean you rightly point out that Conversations (and forks) pick the origin-id for LMC and stuff. but the assumption is that if nobody messed with the id on the way those are the same ✏

I think you wouldn't notice, because afaik all clients currently use origin-id for everything if present, independent of what the specs say. It also arguble makes things easier, because not doing so means you have to store up to 3 IDs for MUC messages.

so despite Conversations picking the origin-id I’m currently not concerned about simply removing the origin-id parsing

Because you might still need origin-id in MUCs for reflection detection

I don't think we have a reliable solution to entirely get rid of origin-id for MUC reflection detection

Maybe biboumi is using different origin-id and message@id in their message splitting reflection?

Because technically using the same message@id for all the splitted messages would be clearly RFC non-compliant ✏

Not that people do care about RFC compliance these days 😐

ok I’m unsure how to resolve this then. we try to get rid of occupant-id for all context where it is used to referer to a message (markers, reactions, retractions etc) but keep it for the sole purpose of tracking your own reflections?

and update the unique and stable id xep to say that?

That sounds feasible yes

I guess you meant origin-id when you wrote occupant-id there 😀

yes

> ok I’m unsure how to resolve this then. we try to get rid of origin-id for all context where it is used to referer to a message (markers, reactions, retractions etc) but keep it for the sole purpose of tracking your own reflections? > and update the unique and stable id xep to say that? Kev MattJ does that ^ sound good to you? (as people who spoke out against origin-id)

You only need it for detecting your own reflections in the case of a MUC service that mangles IDs, right?

Which I think 45 was updated to say not to do a while back, or do I misremember?

right, if the MUC service announces #stable_id feature it should not even be needed

So I think it can be watered down further to only needing an origin-id if you want to detect reflection and the MUC doesn't do stable_id?

TIL about #stable_id :-)

but yes

I don't think M-Link has made very many massive missteps over the years, but I very much regret that it caused stable_id.

I can assure you that M-Link wasn’t the only one

but I don’t have any overview over what if any implementations still mess with the id

#stable_id is a logical compliance requirement from RFC, or precisely, not doing what #stable_id requires was ✏

Oh? I thought we were the only ones, I feel a little better about life now, thanks Daniel :)

I think the bridges (biboumi, slidge, matterbridge) or probably the more complex cases.

but if origin-id is contained to this very specific use case and not referenced anywhere else we can maybe get rid of it in 20 years or so

I just checked and biboumi seems to announce #stable_id as well

> but if origin-id is contained to this very specific use case and not referenced anywhere else we can maybe get rid of it in 20 years or so This seems like a good plan to me, at the moment, before I've had a chance to think about it much :)

> Because technically using the same message@id for all the splitted messages would be clearly RFC non-compliant While biboumi should be doing as you say and I hope it gets fixed and/or I get around to fixing it, right now biboumi violates the spec yes ↺

So I checked biboumi: - If the original message has an origin-id, biboumi will include it in reflection and other resources joined in the room - If the message results in a single message being reflected, the message@id of the message is used in the reflection - If the message is split into multiple messages (e.g. becase it has multiple lines which is not supported in IRC), the first of the splitted messages will have the original message@id and all follow-ups will have a randomly selected message@id. They still do carry the original message origin-id (which thus shows up in multiple messages)

Oh that did get fixed? That's good

They always did (or at least did the last 7 years)

interesting. I was definitely told otherwise and thought I had tested it to be so. anyway. good to know​

As I said, they do keep the original origin-id in all messages, so as Cheogram prefers origin-id over message@id, this might have mixed up

Right, it may be that caused me to be confused. So another reason to remove origin-id heh

So how do you know that the three returned messages from biboumi are a reflection to the one that you sent without origin-id? ✏

only the first one is a reflection. the other two are new messages​

Either all of them together are the reflection to my message, or really none of them is and they're all new messages. Because the body of the first split message clearly is not the one that I sent. ✏

Well reflections are often different from what was sent, that's the reason to detect them so I can edit the local copy to whatever the MUC actually did​

According to which specification is that?

Practice, rather than spec, I think. E.g. the service might be adding security labels to the message on the way through.

I remember a note about adding or removing extended information and even how to announce which namespaces are allowed in 0045 ✏

The content of the body does not seem covered by this.

My point is not to blame biboumi for what they do, but I don't think any of the messages biboumi returns are reflection as per 0045

Nothing in 0045 and particular in #stable_id forbids the room from creating a new message with the same id as one that it received, so that is technically within compliance, it just isn't a reflection. Not sure if that makes things better or worse

I guess best would probably for biboumi to reject the message with some sort of error that indicates it is going to fix it, but we don't have such an error afaik and also it wouldn't be widely implemented. Abusing reflection however IMO also doesn't fix it either. I guess singpolyma is replacing the sent message body with the one from the reflection. I personally don't want my MUC room to be able to replace content in my local database, but also for OMEMO encrypted messages this doesn't even work, because an OMEMO client can't even understand the message it just sent.

I guess back then, MUC clients would only display messages they received from the room, no matter what was sent.

We have cases other than biboumi where MUCs edit the messages on the way through​

> I guess back then, MUC clients would only display messages they received from the room, no matter what was sent. yes exactly. whatever the MUC sends is what everyone else really saw so it's what I want to see as well ↺

You mean, you have cases other than biboumi that are non-compliant

I certainly would want my original message to not get lost

It sounds as if we're back in the days where it was acceptable to lose messages when you're temporarily offline ✏

> You mean, you have cases other than biboumi that are non-compliant I don't see any reason to label it as non compliant. Does 0045 say that you must not edit the stanza at all? ↺

No, it shows exactly what is allowed

> A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions

> the service MUST change the 'from' attribute to the sender's occupant JID and reflect the message out to the full JID of each occupant.

Of course you can argue that the term "reflect" is underspecified here

But to me, reflection doesn't change the content

I'll admit that the SHOULD (which we've learned means MUST) being used with an XHTML body example is pretty damning. OTOH I wouldn't want to lose this ability we've been using in MUCs for decades so maybe the XEP should be clarified to be in line with what is actually done...​

Well, client behavior is certainly not consistent in the case the reflection differs from the original message body, so not sure what "is actually done" means to you.

mod_pastebin's an old and very sensible example.

M-Link adding FLOTs to messages is another.

I'm not sure why mod_pastebin is considered a sensible example. 0045 makes the case for disallowing certain message content and even has the example of message length being restricted. The sensible thing to do with overlong messages is not to have the MUC put it in the pastebin and change the reflection, it is to reject the message with an error and ask the user to either upload it to a pastebin themself or to change their message

Turning large messages / pastes into .txt uploads on the client would also be nice

often enough mod_pastebin and similar did weird stuff. Like when people send a message and attach a log inside the same message body, mod_pastebin would put both into the paste. A human would recognize their mistake and upload the log to pastebin, then send the message with the url to pastebin in the same message.

You usually don't want actual messages to live outside the chat just because they are part of a message with a body too long

So if you ask about sensible, message size restrictions certainly are, automatically converting to pastebin IMO is not.

I think you'd be hard-pressed to argue about FLOTs, though.

I think "sensible" is subjective and up to the service admin​

Kev, what's FLOT?

I think adding metadata is certainly within bounds of what is reasonable, although often the metadata technically is probably only needed for all other recipients, not for the sender itself.

> Kev, what's FLOT? "First line of text". Adding security markings at the start of messages for systems that don't do 258.

But then, do you need to add that for the sending entity as well, or is that only for all other recipients?

(because I guess you converted the 258 to flot in first place, so the sending client was probably aware of 258)

Sometimes systems add a default marking on a message as it passes through.

And you would expect the sending client to display it as well?

Potentially.

But I think there are legitimate cases where a system may want to modify bodies passing through it.

It's unfortunate and annoying to deal with, but I don't it's stupid.

I don't disagree with that, I just don't think that sending clients should replace the content they sent because of a reflection in the MUC. It's like accepting a message correction for your messages from someone else

Don't make me fake a message correction from yourself! ;)

Which I guess some people probably want to be able to do as well

I certainly know of deployments where non-senders need to redact messages, yes.

(Although without getting into details, not necessarily in a 424 way)

Sure, that's not uncommon and also a common feature in commercial messengers, but in those cases I specifically grant permission to the service operators to do so

In systems where I don't intentionally authorize someone to modify my messages, I don't want them to do this

which I guess is why we encrypt these days and why some networks don't allow encryption (that they can't break)

So tl;dr: Let's break biboumi and mod_pastebin by using more encryption \o/

MIMI over IRC it is.

And we probably shouldn't have had all this discussion in council@ 😀

> I certainly know of deployments where non-senders need to redact messages, yes. if it's not done by the sender wouldn't it be a moderation not a redaction? ↺

Not exactly, no. But this isn't the pertinent part of the discussion :)