Re: [Standards] XEP-0280 Carbon Rules for MUC-PMs
-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:
>
> 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 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 , 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 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 of type "groupchat" is not eligible.
> - A of another type than "groupchat", originating from a MUC
> service or room (bare JID), as detected by the presence of an
> tag, is eligible.
> - A from a MUC participant (full JID) containing an tag,
> is not eligible.
> - A 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 ,
> carbon-copy the 'sent' MUC-PM to all clients, require carbon-enabled
> clients to check for 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-
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] XEP-0280 Carbon Rules for MUC-PMs
On Fri, Jan 27, 2017 at 02:36:56PM +0100, Georg Lukas wrote: > 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 , > carbon-copy the 'sent' MUC-PM to all clients, require carbon-enabled > clients to check for 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). I believe at least two implementations do this already. > 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%. This has the nice property that a service administrator can fix the problems for their own users in one upgrade, as opposed to having to wait for all remote MUC services beyond their control. > 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. Yeah. No. Let's not. However it would be an interesting experiment to re-invent groupchat using carbons. > My favorite is to mandate (a) now and possibly follow up with (b), > depending on server implementer feedback. -- Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0280 Carbon Rules for MUC-PMs
Hi,
I know everybody hates MUC PMs, but still. People are using them, and
they are broken in the wild as soon as you have more than one client.
We need to fix XEP-0280 and our server implementations, and probably
also XEP-0045 and our MUC implementations, to tackle this.
Problems TL;DR
--
1. There is no defined way for a server to detect "messages sent by a
MUC room or service", often causing incorrect behavior (spec).
2. Mediated MUC invitations are not allowed to be carbon-copied (spec).
3. Incoming MUC-PMs are wrongfully CCed if #1 fails (implementation).
4. Outgoing MUC-PMs are wrongfully CCed to non-joined clients (spec).
Fortunately, we can solve all of them with little work.
User Story / Problem Details
Let's say Alice is online with three clients as alice@xmpp.example/a, /b
and /c. /a and /b are joined to the MUC alicebobl...@muc.xmpp.example
as "Alice", using Multi-Session-Nicks.
First, Alice invites Bob using a mediated invitation, which is forwarded
by the MUC to Bob's bare JID. The rules in XEP-0280 §6 forbid this invitation
message ("sent by a MUC room or service") to get carbon-copied, so it
is only routed by §6121 §8.5.2.1.1 rules to Bob's primary client,
leading to a significant delay until Bob can join (see
https://prosody.im/issues/issue/744).
Once he figured this out, Bob joins and complains with a MUC-PM to
alicebobl...@muc.xmpp.example/Alice. The MUC takes care of routing
copies of this PM to /a and to /b. If Alice's server follows XEP-0280
§6, it has to automagically detect these messages as "sent by a MUC room
or service" and not carbon-copy them.
If this works, the UX is fine. However, the carbon prevention is often
broken in practice, so the following messages arrive:
/a: MUC-PM to /a and carbon of MUC-PM to /b.
/b: MUC-PM to /b and carbon of MUC-PM to /a.
/c: carbon of MUC-PM to /a and carbon of MUC-PM to /b.
(see https://prosody.im/issues/issue/798 for a reallife example)
If Alice now responds to that PM from /a, this message is theoretically
eligible for Carbon delivery to /b and /c, because it is not *from* but
*to* a MUC. However, the spec is not very clear on this and I can
imagine servers doing this wrong. Furthermore, /c will receive a copy of
the PM and have no idea what it is about.
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:
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 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?).
#2 Mediated MUC invitations
XEP-0280 §6 needs to be extended with an invitation exemption. Possible
variants:
a) add "A 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 of type "groupchat" is not eligible.
- A of another type than "groupchat", originating from a MUC
service or room (bare JID), as detected by the presence of an
tag, is eligible.
- A from a MUC participant (full JID) containing an tag,
is not eligible.
- A sent by the local user to a MUC participant is eligible.
'''
I'm willing to make a PR for (b), with slightly better wording.
#3 and #4 Fixing MUC-PMs
Because incoming PMs are forwarded by the MUC to all joined clients, #3
will be eventually solved with #1. Until all the servers have upgraded,
I suggest that we add a client business rule to 0280 as follows:
"Clients SHOULD discard carbon copies of 'received' messages that
contain MUC private message, irregardless of the client being joined to
that MUC".
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 ,
carbon-copy the 'sent' MUC-PM to all clients, require carbon-enabled
clients to check for 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).
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
