[Standards] Council Minutes 2020-05-27

Jonas Schäfer jonas at wielicki.name
Tue Jun 2 14:26:03 UTC 2020


Hi Marvin,

This is the worst day for such an email after being paged twice this night, 
but since tomorrow is council day, I still tried to catch up. Apologies if I 
missed something or misunderstood something.

On Montag, 1. Juni 2020 17:58:38 CEST Marvin W wrote:
> 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).

Thank you for the summary, it is very well written in my opinion, and covers 
nearly all issues.

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

I think we disagree fundamentally, though, on whether this is an advantage, or 
at least as a necessary advantage. It necessarily implies that if a client 
does not have support for it, I have no way to opt out if I know that my 
message will "style" badly.


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

Yes, body-only encryption breaks a lot of richer use-cases, like SHIM. That’s 
nothing new, and I refuse to cater for it at the expense of other concerns.

(also note that there was a terrible hack which conveyed XHTML-IM over OTR, 
which is even more transport agnostic than body-only OMEMO is.)

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

+1.

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

Also +1.

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

Partial +1. First, note that not many clients actually show the quotation 
markers, which can lead to fun confusion with things which happen to start a 
line with `> ` for whatever reason. So this rule isn’t quite working out in 
practice.

Then note that the added styling plus potentially deemphasising of the 
metacharacters can still make a message unnecessarily visually harder to read.

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

+1.

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

+1, though see above about how well that requirement works in practice.


I think this is missing one disadvantage without an explicit opt-in flag:

- We cannot upgrade or fundamentally change the syntax in a non-breaking 
fashion, without:

  - forcing everyone using a newer version to send opt-out flags for all 
eternity, or 
  - adding explicit support for detecting other non-Styling markup and 
disabling the Styling parser in those cases (which introduces a weird 
coupling; you might call that ideological, too), or
  - have inconsistent displaying of styling, which is the one of the primary 
things this XEP is intended to solve.

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

Obviously +1.

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

Agreed.

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

Right. Passing messages through foreign transports always incurs loss of 
metainformation. Another related issue is if the transport uses a different 
type of markup (for example, RocketChat uses markdown).

I think this is even more so a reason to have an explicit opt-out.

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

I don’t see that as a reason to not make it a MUST. See above re encryption, 
and transports are, again, inherently lossy.

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

Yes please, that’d be the sanest solution. And that’s also why I think that 
having an opt-in is imperative, see above.

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

I think this is fundamentally problematic.

- Either the user inserts those characters themselves, which makes for 
extremely terrible UX.
- Or the sending client has to do it (-> requires client support) and I wonder 
what the UI would look like for that.

Then it has a non-obvious disadvantage (apparently) even to technical users, 
in that it inserts invisible unicode codepoints. This will cause hard-to-
troubleshoot issues when (parts of) the message are copied into a thing which 
cares about it, such as a C compiler.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200602/dde3e625/attachment.sig>


More information about the Standards mailing list