[Standards] Council Minutes 2020-05-27

Marvin W xmpp at larma.de
Mon Jun 1 15:58:38 UTC 2020


Hi,

Sorry, long mail ahead.

I'd like to express that I am very much unhappy where this is leading.
While I am personally not a big friend of inline message styling, I kind
of feel that the party of non-likers (or parts thereof) is trying to
make the XEP to something that is mostly useless instead of improving it.

In several discussions, I've been trying to maintain a more neutral
position, even though I personally do not like 0393. So I'm putting up
my thoughts here now (and a conclusion).

There are some advantages of using the inline styling directives as
described in 0393 for users:
- No sender support required: Even if your sending client is not aware
of XEP-0393, you can use it to do styling that is understood by other
clients that are XEP-0393 capable.
- Transport agnostic: Inline tyling works through gateways. It works
through body-only encryption. As long as there is no widespread
deployment of OMEMO 0.4+ or PGP-OX, there is no better way to send
encrypted messages with styling other than inline.

Some advantages are not exclusive to 0393 as they can be implemented
purely on the sending side with other kinds of markup XEP, however they
are implied by 0393.
- No recipient support required: Even if your client does not make
"*bold*" bold, it's clearly visible that this is emphasized. Support for
XEP-0393 will improve user experience, but is not required to transfer
the information of emphasizing a part of the message. Not being required
on the receiving end is listed as a requirement in the XEP itself.
- Prior art: Some people are/have been used to doing it before,
including outside of XMPP. Using what is already done in practice for
emphasizing improves user experience as people don't have to change
anything but still get new features. For example Thunderbird actually
renders "*bold*" in bold when reading a mail (not during writing it and
not for HTML mails).

Some disadvantages for users are:
- False positives: No matter how strict you do the rules, there is
always a little chance of having a false positive, resulting in wrong
styling being applied.
  This is mitigated partially by requiring clients to display styling
directives. While there is still wrong styling, the intended message is
still fully readable, it "just" looks a bit more ugly compared to when
no styling was applied.
  Clients can also reduce the likeliness of this to happen by adding the
styling directly inline in the text entry field where users type, so
they will visually see when their input would cause wrong styling.
- Aesthetics: Users of clients not supporting XEP-0393 will e.g. see
asterisks around emphasized words, but users may not like to see them
and would rather prefer to not have any emphasizing displayed at all.
  This is mitigated partially by requiring clients to display styling
directives, thus this disadvantage applies to all users, not only those
of non-supporting clients. Sending users are thus well aware that those
characters are displayed. The requirement to display "ugly" styling
directives also increases the need for an additional standard that does
not use inline styling directives.

Another kind of disadvantage:
- Ideological: Styling and content shouldn't be mixed. While I do agree
to this from protocol design, I don't think it's a disadvantage for
users on its own. I am still putting it as it comes up a lot. The actual
disadvantages are those like I described above which are inevitable when
mixing styling and content.

As it is the pure nature of 0393 to have styling and content mixed, this
is not up for discussion. Thus any change we do should try to (further)
mitigate or completely get rid of the disadvantages, ideally without
having to give up on the advantages.

Now the suggestion is to add both opt-in and opt-out flag and leaving it
open what happens when no flag is present, apparently hoping for it
eventually meaning the same as opt-out, while it currently means same as
opt-in.

So how does this change affect aforementioned advantages and disadvantages:
- False positives can still happen as long as no opt-out flag is used.
So I'd say that opt-out improves around that disadvantage, but does not
completely mitigate it.
- Styling directives will still be displayed by non-supporting clients
and should also continue be displayed for supporting clients (as a
mitigation to false positives), so there is no improvement around
aesthetics.
- Both opt-in and opt-out are no longer transport agnostic, which means
at least partially getting rid of advantage 2. If opt-in flag remains
optional, this only means that opt-out flag can be lost and even if
opt-out flag is applied, styling may occur (making the opt-out flag less
useful).
- Having a required opt-in flag means getting rid of advantage of no
sender support and transport-agnostic completely.

What I meant in the introduction with "making it mostly useless": A
required opt-in means the two distinct advantages of inline styling will
be lost. If opt-in is required, it would be possible to implement the
two other advantages using for example 0394 on the sender side: the
sending client just parses the 0393-like styling from the input box and
adds corresponding 0394 markup. Styling directives are left untouched in
the body. Of course that's more implementation work for the sending
client, but for the user it results in the same advantages and
disadvantages as a required opt-in flag for 0393.

So my conclusion:
- We can add the opt-out flag to 0393. Supporting it is SHOULD on the
recipient side and support for adding it is a MAY on the sender side.
Making support a MUST both on sending and receiving side is unrealistic
due to it just not being possible through transports and currently
deployed encryption.
- We put our energy into building a replacement (being it 0394 or
something completely different) instead of using it to make 0393 less
useful to harm its adoption.

Marvin

PS: As a sending client you can already opt-out using a hack: By
prepending the opening (and, if needed, closing) styling directive with
 zero-width space (U+200B), the styling directive becomes invalid,
stopping the receiving client from applying styling. This can actually
be done per styling directive instead of per-message as the suggested
opt-out flag, allowing for the sending user to disable styling where it
would result in a false positive without affecting other styling in the
same message.


More information about the Standards mailing list