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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
