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
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
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
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
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
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
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: Compatibility Fallbacks
> Abstract:
> This document defines a way to indicate that a specific part of the
> body only serves as fallback and which specification the
