[Standards] XEP-0280 Carbon Rules for MUC-PMs
jonas at wielicki.name
Thu Feb 16 16:53:13 UTC 2017
-----BEGIN PGP SIGNED MESSAGE-----
On Freitag, 27. Januar 2017 14:36:56 CET Georg Lukas wrote:
> #1 Detect "messages sent by a MUC room or service"
> Current best practice is for MUC implementations to add a tag to all
> messages (groupchat and PMs) sent from the MUC:
> <x xmlns="http://jabber.org/protocol/muc#user">
> Carbons implementations do check for presence of this tag and disable
> CC'ing accordingly. We need to codify this, and it belongs into both
> XEP-0045 (adding the <x/> tag) and into XEP-0280 (using the tag as a
> filter criterion). I'm willing to create PRs for both once consensus is
> reached ("45 version bump", anyone?).
If implementations are already doing it, and it works, and it solves a problem
at hand, I would strongly suggest that coding this into XEP 45 is a good idea.
It will help new implementations to get up-to-speed. The CC-ing of MUC PMs is
a real problem, and while it is possible to solve this with inofficial
extensions like implementations adding the <x/>, it is annoying for new
developers who then have to learn by failure instead of following the spec. I
don’t think that’s a route we should take.
What exactly is a version bump? I have seen versioned namespaces with
protocols other than MUC, but MUC isn’t namespaced. Also, in this case it
should be sufficient to advertise this as a disco feature (if at all; in the
end, noone needs to know that the MUC supports this, it will just magically
fix things), because it only adds something (the client doesn’t need to know
about this, as a client is generally held to ignore any children of message it
> #2 Mediated MUC invitations
> XEP-0280 §6 needs to be extended with an invitation exemption. Possible
> a) add "A <message/> is eligible for carbons delivery if it is a MUC
> b) replace the MUC sentence with a set of less confusing sentences
> covering all the possible MUC scenarios (e.g. sometimes you try to join
> a MUC and receive a "normal" message from the MUC bare JID asking to
> solve a captcha):
> - A <message/> of type "groupchat" is not eligible.
> - A <message/> of another type than "groupchat", originating from a MUC
> service or room (bare JID), as detected by the presence of an <x/>
> tag, is eligible.
> - A <message/> from a MUC participant (full JID) containing an <x/> tag,
> is not eligible.
> - A <message/> sent by the local user to a MUC participant is eligible.
> I'm willing to make a PR for (b), with slightly better wording.
(b) sounds sensible. I only have wording to bikeshed, but I’ll do that once
the PR is there.
> To fix outgoing PMs, these need to be carbon-copied only to the other
> clients of the user which are joined under the same nickname. This is a
> HARD problem. Possible solutions are:
> a) Require carbon-enabled clients to tag outgoing MUC-PMs with <x/>,
> carbon-copy the 'sent' MUC-PM to all clients, require carbon-enabled
> clients to check for <x/> tag and to drop if they are not joined. This
> is a 90% solution (it will still display outgoing PMs if you are
> joined to the same MUC under different nicknames, as the other client
> doesn't know which nickname the 'sent' message came from).
As a client/client library developer, fine with me.
> b) Require the user's server to track MUC joins, including nickname, and
> make the carbons logic depend on that. This is a 100% solution, at least
> once everybody has updated their servers, and it might add a significant
> burden on the server (at least comparable to tracking directed
> presence). Does not conflict with (a) so it might be a long-term
> improvement for the last 10%.
As a client/client library, I have no opinion on that :-).
> c) Let the MUC generate 'sent' carbons to other MSN clients. This is a
> security nightmare waiting to happen. I'm not going to go this route,
> and I only mention it for sake of completeness.
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Standards