XSF Discussion - 2024-01-20

XEP-0280 defines that, in context of MUC-related messages, "a <message/> of type "groupchat" SHOULD NOT be carbon-copied" (section 6.1). Is there a difference with regards to type=groupchat messages that are and are not exchanged in a MUC? If so, how should you detect that?

Could you rephrase that question, i don't understand it.

Guus, I think that only groupchat message that does not require to be carbon copied are those from MUC and sent to you to full jid ✏

basically, all groupchat messages, I think, shouldn’t be cabon copied

lovetox, XEP-0280 says: > A <message/> of type "groupchat" SHOULD NOT be carbon-copied. But it also says: > The following rules apply to MUC-related messages: My question: should I try to detect if a message of type=groupchat is or isn't exchanged in a MUC (and process them differently, with regards to carbon copy)?

I mean messages of type=groupchat shouldn’t be carbon copied

Andrzej, thanks. I was hoping for that. I have a hard time figuring out if a particular message was sent by a MUC, as there's not necessarily something in the message itself that identifies it as such (without doing service discovery on the 'from' address) I think.

Guus, if you're a server, you would have seen the MUC join procedure.

The question from Guus as I understand it is: Do I need to know that a JID is a group chat to implement carbons correctly.

Zash, true, but I do not want to have to retain that knowledge if I can avoid it.

I can repeat what has already been said, that you can ignore type=groupchat in the context of carbons.

Guus: no other case comes to mind for me, simply copy everything that is not type=groupchat

Yeah, that's what I took from this. Thanks.

Are there edge cases around type = normal maybe?

Are the rules at https://xmpp.org/extensions/xep-0280.html#recommended-rules not clear on that?

Indeed they are quite detailed :) ✏

> it is of type "error" and it was sent in response to a <message/> that was eligible for carbons delivery. Is a bit tricky tho unless you have the original message.

Also MUC PMs in case there's any implementations that don't add the <{muc}x/> still

That section confused me

it defines the type=groupchat thing, but scopes it to MUC only.

I don't know how carbons and MIX ... mix-es

MIX sends messages of type=groupchat to bare jid, so you do not need to worry about that

Last call for XMPP projects to sign up with ideas and list in the wiki. Without XMPP projects and their ideas, we cannot apply this year.

I remembered that there was a XEP that allow a client to send a "recording" event when an audio message is being recorded, the same way "composing" is for text message. Do you remember which one ?

edhelas: yes, I remember it too, and I was looking at it not that long ago, but I can never find it easily

https://xmpp.org/extensions/inbox/fsn.html ?

That's the one, thanks 🙂

I'd replace type with filetype (image/jpeg, audio/opus...)

Maybe look at comments from council at that time

There may be a reason somewhere why it's been refused? (it's been refused right?)

I recall there was a mailing list discussion about it

Looks like there was some debate about extending CSN vs new XEP/protocol, I see nothing on the list about rejection

Here: https://logs.xmpp.org/council/2018-08-01#2018-08-01-4327e1cf61437403

thx 👍

Looks like everyone in the meeting approved it apart from Sam who said he would vote on list. Bets that it slipped through the cracks?

I guess nobody cared enough to notice, but that also means it shouldn't be hard to resurrect if we want it now

That also means it's accepted right?

Unless Sam vetoed on list yes

Ah it's been rejected by sam

Date: Wed, 08 Aug 2018 10:39:52 -0500 From: Sam Whited <sam@samwhited.com> To: standards@xmpp.org Subject: Re: [Standards] XMPP Council Minutes 2018-08-01

> -1 > > As it stands right now there are a few things that really concern me about this XEP. The only one really worth blocking for is the fact that this allows users to send file upload percentages as part of the chat state and I don't think this is something we want to encourage. Instead, it would make more sense to me for each file sending mechanism to have a way to send the total size of the file and allow clients to calculate the percent complete themselves. This makes it harder for a remote client to abuse the protocol (eg. to try and use it as a "time until completion" meter that counts down instead, or to be buggy and cause a meter to jump around on the remote client, making the user think it's their client that's having issues, etc.) Also, perhaps more importantly, this ties file percent completion to support on the remote client, so a local client wouldn't be able to support it consistently (some file transfers would have it, some wouldn't).

meh, remove the progress part of the spec? ??? profit?

seems right to me...

The progress part is the only useful part though 😂

Is it?

The useful part would be what edhelas asked for "Bob is recording a message to send to the chat"

Spamming my clients with the progress of your upload is silly

Indeed

> The useful part would be what edhelas asked for "Bob is recording a message to send to the chat" This is what composing notifications are for ✏ ↺

This isn't typing though

And, not even helpful, because it misses the "how long you will be recording for" and the "how long it will take me to download it" plus in public chats it'll be likely I won't download it

singpolyma: If you're only arguing about adding this to csn, no objection here

I think it's covered by existing csn

As in "composing" covers it already?

Maybe lacking some details no?

Maybe? Seems pretty clear to me. Composing a new message

Seems quite different