Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Marvin W]

Hi,

On 09.01.22 21:50, Dave Cridland wrote:
> I'd still argue that it's a bad idea these days, even if Matrix haven't
> learned from the trouble it's caused in email. Most other proprietary
> messaging apps just have one form, the only reason email (and us, and
> Matrix) went for alternatives is because of an existing deployed base
> that only understood plaintext. This causes not only the problem of
> messages having potentially wildly different meanings between the
> alternatives, but also you can never get rid of the compatibility layer.

I do not agree here at all. The "compatibility layer" is not only for
older clients that don't implement the latest version of the protocol.
It is also to make client development easier (so that clients don't have
to support a large set of features to do basic things) and for
situations where rich text is just technically not feasible.

I just also took a look at two popular proprietary apps:

Slack messages have two alternatives: one is plain text or markdown, the
other one is using "blocks" [https://api.slack.com/block-kit/building].
Every message must have the plain/markdown version, blocks are optional,
but if present should be preferred for rendering. Notifications on
mobile (which are transported through the heavily restricted OS native
push messaging systems) always use the plain/markdown variant.

Microsoft Teams messages can be plaintext or HTML. Both have a plain
text "summary" which is the same as the body for plain text messages and
is meant for push notifications and as a fallback for when HTML
rendering is not possible.

To me it rather looks like whenever a complex markup system is available
(HTML, "Blocks") a simple version (plain text, markdown) is provided as
a fallback.

Of course a lot of messengers just only support plain text or markdown
and are fine with it, especially as inputting any formatting on mobile
is tedious.

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Sun, 9 Jan 2022 at 13:38, Marvin W  wrote:

> Given that (as you know) I originally proposed this for XEP-0428 and you
> argued against, I'd say that updating XEP-0428 *was* my first choice,
> but it is your right as author to refuse this.
>

XEP-0001: XMPP Extension Protocols


No, it isn't! A XEP in Experimental state isn't the property of an author,
the author just gets the responsibility to incorporate feedback from
discussions on this mailing list. All published XEPs are owned, entirely,
by the XSF, and subject to change control under XEP-0001.

We have, as a community, generally deferred to the author to decide how to
(and indeed whether to) incorporate specific suggestions, but if the rough
consensus of the participants of the standards list is to add something, it
should be added even if the author is in the rough. If an author isn't
doing that, we find another author who will (and Council have,
historically, made that kind of decision formally).

But equally, if you're in the rough that doesn't mean you just submit
another XEP. That just gives us fragmentation, and it's something that the
Council has correctly pushed back on over the years (sometimes including
against XEPs I've proposed).

In this case, I don't think we got consensus either way. You made an
argument, I disagreed - but I certainly didn't intend to "refuse". I did
intend to see what other people thought before I went further - that is, I
wanted to get an idea of where the consensus was - but that's why I asked.
Nobody at all replied, and quite honestly I forgot about it, but it doesn't
seem to me that we got any kind of consensus.

The "for" thing I *did* mean to add, since I just didn't really see much
point but wasn't against it. Since everyone else seemed largely for it or
ambivalent, I would have added it - except that one slipped off my todo
list. I think, in my defence, I was waiting for replies to the other
question.

In the case of the other two XEPs you've proposed, it's actually worse -
both have close prior art, but unless I'm missing something these came as a
total surprise to the authors, who are both active (XEP-0353 is being
updated *right now*). As I said, this appears to be a general pattern, and
it's a worrying one to me.

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Sun, 9 Jan 2022 at 13:38, Marvin W  wrote:

> On 09.01.22 13:24, Dave Cridland wrote:
> > Still, as written, the ability send a message which is rendered in
> > *radically* different ways in different clients just fills me with
> > unease. Fallback bodies are nasty like this - it's why I've never been
> > happy with the "multipart/alternative" style of XHTML-IM, for example
>
> "multipart/alternative" style as you call it is being used in e-Mail for
> centuries. I might also be worth looking at other modern messengers like
> Matrix, which transports html and plain text as alternatives
> [https://spec.matrix.org/unstable/client-server-api/#mroommessage-msgtypes
> ].
>

Yes, I'm aware that "multipart/alternative" is used in email, hence my
usage of that particular MIME type to describe the style (I wouldn't say
centuries though - I remember MUAs getting MIME support as an exciting new
feature).

It doesn't surprise me that it's repeated in Matrix - it seems like a
practical, sensible idea at first, and it was the only reasonable option
for email, which prior to this had just plaintext ASCII email bodies. It
was generally impossible to update software on your workstation as well,
since (for most people) you only had user level access.

I'd still argue that it's a bad idea these days, even if Matrix haven't
learned from the trouble it's caused in email. Most other proprietary
messaging apps just have one form, the only reason email (and us, and
Matrix) went for alternatives is because of an existing deployed base that
only understood plaintext. This causes not only the problem of messages
having potentially wildly different meanings between the alternatives, but
also you can never get rid of the compatibility layer.

We (like Matrix) would have been better off without it - content
negotiation or graceful degradation are always better options when
available, and upgrading client software is vastly simpler than it used to
be as well.

RFC 1341, which introduced multipart/alternative, also introduced the
MIME-Version header. We repeated that error too - both our versions are
stuck forever at "1.0". (Mark Crispin actually predicted that one back in
1990 or so).

Dave.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Marvin W]

Hi,

On 09.01.22 13:24, Dave Cridland wrote:
> I'm astonished you can simultaneously argue that XEP-428 should have
> added this functionality *and* the functionality has no overlap. Surely
> it must be one or the other, and not both?

After I proposed this and you argued against, I understood your position
and agreed. I expected you didn't just argue for the sake of arguing,
but actually also argued in your own favor, so this should be in your favor.

> Well, part of the intent was that clients could know that it *was* a
> fallback message, and render it as such, so the user knew that the
> message wasn't being rendered at the sender intended. I know this isn't
> in the XEP, but it was discussed at the time I think.

If this was intended, then again the "for" attribute is not optional
because the client would not know if they should render that they
received a message that isn't rendered as intended or not, if they don't
know if they actually implemented the specification that this body was a
fallback for.

Example 1:


 
  
 
 
 Unfortunately your client does not support Jingle Message
Initiation. Please click this link to accept my call:
https://call.example.com/accept?id=a9d9fa=sen...@example.com
  


Example 2:


 
  
 
 
 Your client does not support the unknown element. Nobody does.
 


> As I said, my concern is that updating '428 isn't the first choice here.

Given that (as you know) I originally proposed this for XEP-0428 and you
argued against, I'd say that updating XEP-0428 *was* my first choice,
but it is your right as author to refuse this. Again, if your opinion
changed since, that's fine by me. But your reply also basically says
that you don't want this in XEP-0428.
> 1) Markup, where removing the quotation marks radically alters the
> message (and the markup is intended not to be intrusive anyway), and

Removing the quotation marks does not alter the meaning if the client
understood through other means (markup) that the part of the message is
meant as a quote. We need a way to transition from markdown-style
formatting to something else (as markdown-style formatting is overly
restrictive and at the same time has false positives) and this is a
proposal to do this.

> 2) Replies, where including a quoted message has security problems all
> of their own, as I note elsewhere, and

The current situation is that people do quote messages for replies with
all the "security" problems it has. Again we need a way to transition
from this to something else. As we are in a federated environment, we
can't force upgrade everyone at the same time and users won't use the
new feature if it does not work properly with their friends' clients, so
for this transition we need a fallback. The fallback does not worse
anything for existing users, as they are already using quoted messages
for replies today.
> Still, as written, the ability send a message which is rendered in
> *radically* different ways in different clients just fills me with
> unease. Fallback bodies are nasty like this - it's why I've never been
> happy with the "multipart/alternative" style of XHTML-IM, for example

"multipart/alternative" style as you call it is being used in e-Mail for
centuries. I might also be worth looking at other modern messengers like
Matrix, which transports html and plain text as alternatives
[https://spec.matrix.org/unstable/client-server-api/#mroommessage-msgtypes].

> 
>   Dave is not a genius
>   
>     
>   
> 

The ProtoXEP clearly states "The exact behavior for a compatibility
fallback should be defined in the respective specification. Not
displaying the fallback in supporting clients would be an example for a
behavior.". As such, in this example, the fallback element would not
result in part of body being stripped, as the specification for
"urn:xmpp:call-invites:0" has no behavior defined for this case.

>  id='message-id3' type='chat'>
>   
>     > Anna wrote:
>     > We should bake a cake
>     This is not a great idea!
>   
>    id='message-id1' xmlns='urn:xmpp:reply:0' />
>   
>     
>     
>   
> 

Nothing prevents receiving clients or specifications from adding checks
or requirements to the fallback and warn users/moderators if the
fallback seems to be significantly off from what it should. For example,
a valid fallback for replies will typically be a single block in the
body, etc.
But, I also doubt that this is strictly needed, given the experience
with other systems using alternative formats. I agree it makes sense to
think about this, but should really a large amount of users suffer from
us not proceeding the specification process because there are some
things that arguably are not and never will be perfect?

Of course spam prevention and moderation must be prepared to operate on
everything that may be eventually rendered to the user (which is a good
argument to prefer using body instead of new elements for new features)

> And if you think removal of arbitrary words isn't a problem, be assured
> that 

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Dave Cridland]

On Sun, 9 Jan 2022 at 10:58, Marvin W  wrote:

> Hi,
>
> On 08.01.22 23:34, Dave Cridland wrote:
> > In this case, you've got a pre-existing fallback extension that you
> > *could* - and indeed *have* - proposed extending in exactly this way
> > without any problem, but for some reason you've decided to make an
> > entirely new one instead of continuing that discussion, which just feels
> > a bit odd.
> >
> > If you want to just edit that one please let me know, but otherwise, it
> > seems this is trying to do something in the same space but without using
> > the same XEP. This just feels like it's not really following the spirit
> > of our process at all, and it has to be considered an overlap since one
> > of the authors was actively proposing these changes to XEP-0428. What
> > happens if I update XEP-428 to support these use-cases?
> Beside "fallback" in the name, there is really no overlap in
> functionality of this ProtoXEP and XEP-0428. This is also explained in
> the ProtoXEP itself.
>
>
I'm astonished you can simultaneously argue that XEP-428 should have added
this functionality *and* the functionality has no overlap. Surely it must
be one or the other, and not both?


>  as described in XEP-0428 is basically similar to a
>  hint of XEP-0334 (which is hinted to in the XEP itself and
> also was explained by you on list) as such that it instructs
> intermediaries (servers) to handle the message as if there was no body.
> Clients have little use of this specification as they should only ignore
> the body if they understand what the message in question is actually
> supposed to transmit and thus will always know if they should ignore the
> body or not.
>
>
Well, part of the intent was that clients could know that it *was* a
fallback message, and render it as such, so the user knew that the message
wasn't being rendered at the sender intended. I know this isn't in the XEP,
but it was discussed at the time I think.

But yes, also the rejection of XEP-0334 does cause servers some problems,
so '428 fills that gap too. Arguably it shouldn't (or at least, not
always), but the loss of XEP-0334 was rather fresh in my mind, so as
written it is indeed equivalent to .


>  as described in the ProtoXEP in contrast is purely client
> side and only applies to a part of the body, never the full body.
> Intermediaries should not interpret it and if Stanza Content Encryption
> (XEP-0420) is used, this  element should be part of the
> encrypted payload and not outside, so that intermediaries are not even
> capable of interpreting it.
>
> Of course you can update XEP-0428 to divert from its current intended
> meaning. Or you just add new features to XEP-0428. If you feel that is
> more sensible, I'm open for that as well. It's not like it really
> matters in which XEP number this new client-side feature ends up, as
> long as it does end up in a XEP.
>
>
As I said, my concern is that updating '428 isn't the first choice here.
(See also, updating XEP-0353 and reusing any of the prior art at all in
replies). This feels like Not Invented Here.


> > Now, as it happens, my view is broadly unchanged after 18 months - I
> > think it gets very complicated when different extensions add bits of
> > textual markup they then need removing under some circumstances, and so
> > I worry that while this is a desirable UX, it's also a pretty nasty way
> > of getting there. The example given has parallel fallback "trims" for
> > markup and reply, and a client supporting both feature would have to
> > know which to apply and in what order. However, if a client knows that a
> > quoted section should be trimmed for replies, then the fallback trim
> > information is superfluous. It surely must know to remove the markup
> > with markup. I can be persuaded I'm wrong, mind, or simply that the
> > consensus is we should have this part of the protocol - but this is the
> > conversation we were having 18 months ago, and I never got a reply.
>
> Removing parts of the body under circumstances is exactly the only
> purpose of this ProtoXEP. If we were to remove that feature, the
> ProtoXEP would be entirely useless. I wouldn't know what a client should
> do with the information "Parts of the body are only for fallback
> purposes, but we don't tell you which part".
>
>
The examples you've given are:

1) Markup, where removing the quotation marks radically alters the message
(and the markup is intended not to be intrusive anyway), and

2) Replies, where including a quoted message has security problems all of
their own, as I note elsewhere, and

3) Breaking News, where arguably you'd want to send a different renderable
payload element entirely and if a body element is provided *at all*, it'd
be a pure fallback.

On the other hand, we've prior art like XEP-0308 where the biggest UX
problem is that the users don't understand why they're seeing a message
twice. '428 might help with allowing the users to understand that their
client is missing some 

Re: [Standards] Proposed XMPP Extension: PubSub Namespaces

[Dave Cridland]

On Sat, 8 Jan 2022 at 23:04, Maxime Buquet  wrote:

> On 2022/01/08, Dave Cridland wrote:
> > On Tue, 4 Jan 2022 at 17:55, Jonas Schäfer  wrote:
> >
> > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > >
> > > Title: PubSub Namespaces
> > > Abstract:
> > > This extension defines a new PubSub node attribute to specify the type
> > > of payload.
> > >
> > >
> > Oh no it doesn't!
> >
> >
> > > URL: https://xmpp.org/extensions/inbox/pubsub-ns.html
> >
> >
> > What this extension appears to be trying to do, based on the (entirely
> > unreferenced and unmentioned on this list) Github discussion, is to
> define
> > the pubsub node *semantics*. That's a different thing to a namespace, and
> > certainly different from the "type of payload".
>
> Indeed, this is based off a PR[0] that I made a while back on 277, that
> got somewhat-rejected-but-not-really by one of its authors (stpeter). I
> got asked to go to standards but I thought that would get no interest as
> pubsub stuff usually does and we would redo the same discussion just the
> two of us. So I gave up, until this.
>
> > The canonical example given was microblogging with Atom, where you don't
> > just want random Atom payloads - the node might require Atom to work, but
> > it has additional semantics around it that can be expected. IOW, the need
> > is to know it's a microblog node, and not just an Atom node. So this
> isn't
> > really about payload formats, it's about node semantics, and that's a
> > radically different thing. And definitely not a "namespace".
>
> Yes! I think you captured very well what we wanted to say! We do want
> a way to express semantics.
>
> “Payload” may not be the word, then we'll change it. “Namespace” annoys
> people, we're also happy to change it. Suggestions welcome for a
> field(?) name, and also another XEP name!
>
> If that is the meaning that is generally given to (payload) “type” (a
> very generic word), then I understand stpeter's resentment to accept the
> PR.
>
> > The pubsub#type form field we already have (and rarely use) is stipulated
> > as being the "type of node data, usually specified by the namespace of
> the
> > payload (if any)". I think this covers what's needed here, whereas this
> > specification as written actually doesn't - and isn't any clearer than
> > pubsub#type.
>
> Suggestions on how to make the document clearer is also very welcome. As
> you can see edhelas and I are not particularly great at writing,
> especially in english.
>
>
Si j'ai écri en francais je ne peut pas etre tres claire aussi! Mais un
"namespace", ca veut dire une place du noms, comme les rues dans un cité -
c'est un protection contre avez plusiers rues avec le meme nom dans autre
cités.

(And also, apologies for not being able to type accents properly on this
machine - I should have just given up and used on online translator)

Translation to English: If I wrote in French I couldn't be very clear
either! But a "namespace" means a place of names, like the streets in a
city. It's a protection against multiple streets with the same name in
other cities.

So "type", while as you note very generic and horribly overloaded, is
closer to what you're aiming for I think.


> I do want to say though that some more words on pubsub#type would be
> great. I am definitely not the only one to be confused.
>
>
I think pubsub#type is sufficiently underspecified that using it for node
semantics seems fine to me. Usefully, it is *not* specified as being the
type of the payload, just noted as being "usually" the same as the payload
namespace - again, I think that fits your requirements. If I were on
Council, I'd want to understand very clearly why it does not before
accepting the XEP.

However, your specification here contains more functionality than just an
opaque-to-the-service label for the node semantics, so itself may not be
superfluous, but I think the additional field is - and the advantage of
reusing the existing field is that you can roll it out immediately.

Therefore, I would:

* Replace the new field with the existing one.
* Strike section 5.2 (pubsub node, no longer needed)
* Make 5.3 and 5.1 operate on the pubsub#type field.
* Also: Put in a PR against XEP-0060 (sorry Ralph/Peter) to indicate that
the pubsub#type means a label for the node semantics, and while it is often
the same as the payload namespace it can also be any other URN.


> > This specification is also unimplementable as written, due to the
> > requirement in 5.1.1 to have realtime access to the registry, but that's
> > really a non-issue - the specification isn't clear enough to even know
> what
> > the intent is. Once we understand the intent, we can then compare it with
> > pubsub#type, and decide if it'd be better to make better use of that.
>
> I guess we'll fast-forward to the time the XSF has a working registry.
> I'm not sure that should prevent a spec from getting in.
>

Well, impossible isn't a reason not to work on fixing it, for sure.

Re: [Standards] Proposed XMPP Extension: Compatibility Fallbacks

[Marvin W]

Hi,

On 08.01.22 23:34, Dave Cridland wrote:
> In this case, you've got a pre-existing fallback extension that you
> *could* - and indeed *have* - proposed extending in exactly this way
> without any problem, but for some reason you've decided to make an
> entirely new one instead of continuing that discussion, which just feels
> a bit odd.
> 
> If you want to just edit that one please let me know, but otherwise, it
> seems this is trying to do something in the same space but without using
> the same XEP. This just feels like it's not really following the spirit
> of our process at all, and it has to be considered an overlap since one
> of the authors was actively proposing these changes to XEP-0428. What
> happens if I update XEP-428 to support these use-cases?
Beside "fallback" in the name, there is really no overlap in
functionality of this ProtoXEP and XEP-0428. This is also explained in
the ProtoXEP itself.

 as described in XEP-0428 is basically similar to a
 hint of XEP-0334 (which is hinted to in the XEP itself and
also was explained by you on list) as such that it instructs
intermediaries (servers) to handle the message as if there was no body.
Clients have little use of this specification as they should only ignore
the body if they understand what the message in question is actually
supposed to transmit and thus will always know if they should ignore the
body or not.

 as described in the ProtoXEP in contrast is purely client
side and only applies to a part of the body, never the full body.
Intermediaries should not interpret it and if Stanza Content Encryption
(XEP-0420) is used, this  element should be part of the
encrypted payload and not outside, so that intermediaries are not even
capable of interpreting it.

Of course you can update XEP-0428 to divert from its current intended
meaning. Or you just add new features to XEP-0428. If you feel that is
more sensible, I'm open for that as well. It's not like it really
matters in which XEP number this new client-side feature ends up, as
long as it does end up in a XEP.

> Now, as it happens, my view is broadly unchanged after 18 months - I
> think it gets very complicated when different extensions add bits of
> textual markup they then need removing under some circumstances, and so
> I worry that while this is a desirable UX, it's also a pretty nasty way
> of getting there. The example given has parallel fallback "trims" for
> markup and reply, and a client supporting both feature would have to
> know which to apply and in what order. However, if a client knows that a
> quoted section should be trimmed for replies, then the fallback trim
> information is superfluous. It surely must know to remove the markup
> with markup. I can be persuaded I'm wrong, mind, or simply that the
> consensus is we should have this part of the protocol - but this is the
> conversation we were having 18 months ago, and I never got a reply.

Removing parts of the body under circumstances is exactly the only
purpose of this ProtoXEP. If we were to remove that feature, the
ProtoXEP would be entirely useless. I wouldn't know what a client should
do with the information "Parts of the body are only for fallback
purposes, but we don't tell you which part".

We intentionally have a complex example in there, so that developers
will directly think of them when implementing this. However you are
wrong in that clients need to know the order in which to process certain
markup or trimming XEPs, for as long as all of them are a reference to
characters in the original body, i.e. before any markup or trimming took
place.

Regarding your message from Jan 10, 2020 (which I think is the one you
are referring to): You were asking if anyone is keen on doing this and
if anyone knew an alternative. I'm not keen on this, but I don't know
any sensible alternative (and given there was no reply, apparently
nobody else is keen or knows an alternative) - so this is why I'm
pursuing this now, even if this is not a solution which immediately
rings "that's awesome" in my head, because we need something like this
and don't have any alternatives. I'd be happy if any sensible
alternative was provided.

> Having a "for" attribute listing the feature that the fallback is for
> seems fine to me, though I kind of think it might be superfluous. But as
> I said 18 months ago, it doesn't do any harm.

Without the "for" attribute, clients will not know if they should remove
a part or not as they don't know if this is a fallback for a
specification they implement or a fallback for some part of the message
they did not understand (if any). As such it's not superfluous in this
case but strictly needed (opposed to XEP-0428 where it is not a
requirement as intermediaries do not really mind why they won't store a
message in persistent storage).

Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: