XSF Discussion - 2024-01-20

  1. Guus

    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?

  2. lovetox

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

  3. Andrzej

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

  4. Andrzej

    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

  5. Andrzej

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

  6. Guus

    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)?

  7. Andrzej

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

  8. Guus

    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.

  9. Zash

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

  10. lovetox

    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.

  11. Guus

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

  12. Zash

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

  13. lovetox

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

  14. Guus

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

  15. lovetox

    Are there edge cases around type = normal maybe?

  16. Zash

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

  17. lovetox

    Indeed there are quite detailed :)

  18. lovetox

    Indeed they are quite detailed :)

  19. Zash

    > 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.

  20. Zash

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

  21. Guus

    That section confused me

  22. Guus

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

  23. Zash

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

  24. Andrzej

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

  25. emus

    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.

  26. edhelas

    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 ?

  27. MattJ

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

  28. pep.

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

  29. MattJ

    That's the one, thanks 🙂

  30. edhelas

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

  31. pep.

    Maybe look at comments from council at that time

  32. pep.

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

  33. MattJ

    I recall there was a mailing list discussion about it

  34. MattJ

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

  35. MattJ

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

  36. edhelas

    thx 👍

  37. MattJ

    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?

  38. MattJ

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

  39. pep.

    That also means it's accepted right?

  40. moparisthebest

    Unless Sam vetoed on list yes

  41. pep.

    Ah it's been rejected by sam

  42. pep.

    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

  43. pep.

    > -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).

  44. pep.

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

  45. moparisthebest

    seems right to me...

  46. singpolyma

    The progress part is the only useful part though 😂

  47. pep.

    Is it?

  48. moparisthebest

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

  49. moparisthebest

    Spamming my clients with the progress of your upload is silly

  50. pep.


  51. singpolyma

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

  52. singpolyma

    > 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

  53. pep.

    This isn't typing though

  54. moparisthebest

    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

  55. pep.

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

  56. singpolyma

    I think it's covered by existing csn

  57. pep.

    As in "composing" covers it already?

  58. pep.

    Maybe lacking some details no?

  59. singpolyma

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

  60. moparisthebest

    Seems quite different