[Standards] XEP-0280 Carbon Rules for MUC-PMs

Jonas Wielicki jonas at wielicki.name
Thu Feb 16 16:53:13 UTC 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey list,

On Freitag, 27. Januar 2017 14:36:56 CET Georg Lukas wrote:
> Suggestions
> -----------
> 
> #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 
doesn’t know).


> #2 Mediated MUC invitations
> 
> XEP-0280 §6 needs to be extended with an invitation exemption. Possible
> variants:
> 
> a) add "A <message/> is eligible for carbons delivery if it is a MUC
>    invitation"
> 
> 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.

Hell no.

cheers,
Jonas
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG/EPV+Xzd5wEoQQIwGIDJZdiWIoFAlil2PkACgkQwGIDJZdi
WIq9pxAAoFNh6n1bccDB2LHYnl8ipzJ9GQfj/ytI+/9W9qSL+ISezzEhrswsDpli
YgYoHTfCshGzgrEcUUxIXP9pL5r0NMVwzaOT4XiMNM5Huext3IRDc/71WUyGsK8Y
3jXhvs201p1JZ7RgJOcl88A87jXUl8g+GrJqh2qdfEIaPjIK42zWgzp33zu+bC7k
HVCi0wJ/i5OBcvy1GLfCU0RogB326Nc0s2kv7MLqfDiMcdjgAtPQ1Bk1M1otgarX
3FeKeHdoOySuR5BQzHrAc+SzZWmuQ0J0lKYYX7x8bZeI3o+3OGTdgkE5nWtppwQ7
aVSlfA+w1Hlv2RbYM6GwACQ/GoasBM6eLJMo2liSWRakQMEYGsq7tRj14uCWhNyO
1/4pssker1fM7qjB3DY2YVm+7rZEo+TrQltFqBolV+uuhhXvaL/o32buY6t/MQLz
bw8GJpDDeGZKvMGvb1QkddzhRAgY5dWHkG2MCbOJ8Fwx1qve2ytxKgCmnuIQ3YVX
V4HsNEpaVIvQZP+sB3T5TzxJ6TL72jh4flUD9gjtalDEABwzldqMsUjJ7KdpTIM2
4V1pZOUus+KoyLEygYQqYLeXvMlHfVqi9GmUbBU8bzsewNXb9nYueQMVNVY546II
D5YrT/Xk/DbEyVEBMXCtsJJg7jWAklbYSW8mazzrM8jomUyc+Ik=
=3y3/
-----END PGP SIGNATURE-----



More information about the Standards mailing list