XSF Discussion - 2022-04-30

“12:17:29 Holger> And I just doubt this would improve if ProcessOne started to spec their own solutions in addition to the existing mess.”, I tried to do that, but got shot down because I made yet another XEP instead of bolting it onto another, IIRC.

https://linkmauve.fr/extensions/muc-avatars.html was the protoXEP before edhelas modified it to support PubSub too, and besides the addition of a muc#roominfo_avatarhash it is a rewrite of Ejabberd’s tutorial.

I guess I could resubmit it as historical, since it’s now in so widespread use that it makes sense to have it specified anyway.

Is that what everyone currently does with muc avatars anyway?

It is

Then its really at least historical 😀

Have we redefined 'Historical' to include things developed after the creation of the XSF?

Zash, I might propose a change to XEP-0001 to this effect.

Hm. Indeed it would be cleaner to just repropose it as a normal xep and not historical

Because we have no other status to accept a sub-par specification which is despite that in widespread use.

But IIRC the issue with that one was too many numbers related to avatars.

So even historical might not fit.

I think it should be accepted if Everyone uses it anyways..

I would think so too.

I'd accept it as a standard XEP fwiw, and move it to Stable/Final, or Obsolete if there's already an alternative (but there isn't here)

Informational would work

"People are doing XEP-0153 in MUC like this. GLHF"

I once proposer a (better imo) alternative, about exposing 0084 on a MUC room.

What's the difference though, Zash

This time I made sure to add it to 0045, which as everyone knows grows up when you aren’t looking.

Link Mauve, maybe you can submit this first, and then we'd obsolete the other one when it's clear it's actually a replacement

It got rejected once already.

Yeah well council can get over it for once

Dunno, IIRC it was out of concern for some implementations being unable to have both a MUC room and a PubSub service on a same JID.

Maybe someday process will be less rigid

It wasn’t so much about process this time.

MUC-PEP would actually be helpful :/

In other places as well

Isn't there a MEP protoxep already?

mathieui, XEP-0316.

Right

Ah well if it's already specced, then the MUC avatar spec just needs to reuse it

Hmm, in the case of non-anonymous MUCs, would it make sense to make the PubSub nodes persistent, so that clients don’t need to publish them again every time they join?

I just read it again and the only mention of lifetime is that it is tied to occupants.

For MUC avatars?

For occupants maybe do so only when a nick is registered or sth?

For MEP.

Unless you equal non-anonymous to "private" (which isn't the case in the wild), then, it might make sense yeah

The examples are about COIN stuff, but it could be applied to 0084 as well.

pep., right, having a consistent nick is the actual requirement for MEP nodes to be persistent between joins.

couldn’t a recent MEP piggyback on occupant-id?

Is it necessary?

MUCs have access to realjids

Persistency doesn't even need to be limited to non-anonymous

A MUC may want to GC nodes though sometimes(?)

pep., in this case, having JID a take JID b’s nickname would cause the service to delete all nodes?

That would be a kind of leak for which JID ends up using which nickname though.

If the nick is registered, no?

Is it always?

No but that could be a constraint for persistency

There's a ton of things widely deployed that weren't blessed or in some cases were rejected by the XSF, I think that blows any argument that the XSF holds any protocol hostage out of the water

IMHO the council's job is to vet specs for technical correctness and ... Implementability (did I just make up this word?) Not to steer the protocol in any specific direction, that's what running code and consensus is for

ideally not only the council would be able to vet specs for technical correctness and implementability (see, now that i've used it, it's certainly an established term), but I always feel like we could do better to guide protocol design from the very first stages over the first ProtoXEP submission till it reaches stable

like a source repo for XEPs in development, stable (snapshot) versions of XEPs, and a forum to discuss this

+ the machinery around that source repo for linting, building and publishing those XEPs

maybe that would even motivate companies to publish their XMPP protocol extensions there. while this would not stop duplicate protocol functionality (which is IMHO impossible to prevent), at least everything would be in one spot

flow, isn’t this “forum to discuss this” what standards@ is?

Link Mauve, sure, and while I am subscribed to many mailing lists, I believe that discourse would be better

and even if it's just because you can tag things. tags help a lot with grouping topics about the same complex

and the obligatory reminder that you can use discourse just like a mailing list

I didn't mean what I said was the *only* thing council should do to be clear, just that it should not try to steer the protocol in a specific direction

yes, it will be a bit different than your "normal" mailman mailing list, but I think it combines the best of both worlds

moparisthebest, I believe that council should be able to express their opinions, but ulitmatley, as you IIRC said, power balance between council, implementors, and users that decides how the protocol evolves

so council should try to be apply its corrective factor to that, but it is certainly not able to decide how the protocol evolves ✏

but what I really like to see is mechanisms that prevent that non-idomatic and/or (slightly)-flawed protocols get widely deployed

How would you prevent people from implementing and deploying something?

take OMEMO for example, i'd really think that it should be possible to encrypt arbitrary XMPP XML elements, but body-only is what we have now

mdosch, don't, but we are hopefully able to convince them about better approaches (if there are any)

Everyone should express their opinions, members and council alike

> mdosch, don't, but we are hopefully able to convince them about better approaches (if there are any) And why you were not able to talk to omemo inventors and convince them and what mechanisms would have helped?

mdosch, I don't remeber the details, it's been a few years. I know I talked with someone (daniel) about this, but I don't know how far OMEMO was at this stage

> take OMEMO for example, i'd really think that it should be possible to encrypt arbitrary XMPP XML elements, but body-only is what we have now flow: isn't stanza content encryption [eventually] taking us in that direction?

flow, OMEMO the XEP allows you to encrypt arbitrary payloads, just that everyone implements the pre-standard in order to be compatible with everyone.

I don't remember how much OMEMO was developed in the open, but it certainly would helped if there is one central place where more or less all development in XMPP-space happens, irregardless if it has blessing from the XSF of not

wgreenhouse, that is what we have now a XEP with a new namespace, but nobody(?) implements the current OMEMO version, only the old one

moparisthebest, non-members as well.

Link Mauve, per-standard?

flow: sure. that's how it goes :-|

flow, pre-, aka XEP-0384 version 0.3.

Link Mauve, how is that pre? IIRC it's simply experimental?

Version 0.3 is basically the first draft, which got implemented in Conversations before being published as a XEP, and which everyone follows.

0.2 already incorporated changes from the standardisation process, which made it incompatible with what was deployed in the wild.

… or not? It seems to still be using the legacy namespace.

Maybe I’m remembering the chronology wrong.

Link Mauve, my git history tells me that OMEMO 0.1 was accepted by council with the "Its <payload>, when decrypted, corresponds to a <message>'s <body>." part

flow, ok, my bad, the actual change according to the history is that 0.0.2 switched to Olm instead of Axolotl, and 0.2 switched to SignalProtocol instead of Olm.

and while I am in the corner "accept all the things as experimental" I wonder if this shouldn't been a reason for council to reject the XEP. But I also remember that strong desire for a libsignal-based XMPP encryption mechanism, so it was probalby good to have it, even in this shape. But then again, this would have been a trivial fix

So only 0.0.1, 0.2 or 0.3 correctly describe the current implementations.

With the old issue that non-GPL implementations couldn’t use Axolotl back then, IIRC that changed at some point.

yep, but that's a different discussion that brings back some painful memories from that era ✏

^^'

> flow wrote: > Link Mauve, sure, and while I am subscribed to many mailing lists, I believe that discourse would be better Isnt discourse javascript based? That sounds horrible

there is twomemo aka omemo:1 which uses SCE. and the spec was written very openly

we had a two day meeting

with lots of people

flow, oh and 0.2 was already using the urn:xmpp:omemo:0 namespace, probably 0.1 as well.

flow, preventing non-idiomatic protocols is cool, except when it's actually what holds back things from getting deployed and used. Not saying I don't want it but one has to be somewhat careful about how it's done

that's why the current XEP also has a billion authors

What I'd like to see is common patterns more documented

but implementing twomemo is far, far more complex than siacs omemo

Daniel, is the current omemo:2 named threememo? :D

Daniel, right, omemo:2 was very openly developed, I was talking mostly about the OMEMO ProtoXEP

no. the latest NS bump is BS and doesn’t really change anything

it's still twomemo

It's not implemented anywhere anyway.. bump or not

and I don't want to blame the OEMO ProtoXEP authors here, they probably did not know any better and we, the XSF, do not provide guidance on that

pep., yes. but the protocol has become tremendously more complex

flow, alright so doing archaeology, it seems the ProtoXEP and 0.3 are what is implemented in the wild currently, and 0.1 and 0.2 changed namespaces as well as encryption mechanism (using Olm instead).

No one implemented those AFAIK.

Daniel, you mean between :1 and :2?

i don’t think that any of the large siacs-omemo implementors have anything against twomemo - but the actual real world benefit is also not that much compared to how difficult it is

The only client having recent omemo is the UWXP or something in windows

Daniel, oh

And Kaidan in a bit supposedly

pep., no, between encrypting the body only and encrypting arbitrary payloads.

Link Mauve, ?

+ siacs omemo works good enough, so there is not much intrinsic incentive to switch

flow, “good enough” for plain text messages and nothing else.

good enough, given that is how we communicate right now :)

plus we had two years of pandemic between the twomemo sprint and now

We don’t use this right now.

flow, for example when you say non-idiomatic patterns, I'm thinking about documents that have been stopped, for example reactions with fastening, and now fallbacks?

Ah, you mean in general? Yeah perhaps, but that’s one of the reasons I don’t use OMEMO (at all).

pep., I am sorry, I don't get the question? :?

flow, not a question, a comment. On being careful about stopping stuff because it's not idiomatic

well you can't really stop stuff, council can probably deny their blessing

then there is a chance that you end up with two protocols: an idealized one and a pragmatic one

Which is already a big blow and many projects actually care about this blessing

I am not aware of any FOSS community projects that care *much* about council blessing

my guess would be that only industrial certified project care about the wax seal on the document

but I don't think this is a problem

flow, there was this project, Pidgin, which refused to implement specification before they were final.

Pidgin (which may be a special case, but it's a real case) doesn't implement anything not draft? Dino also seems to care very much about standardisation, and apart from their slow release cycle, they've had reactions ready since 2019(?), in a branch. I mean even in poezio, we don't have anything official about this but it's rare enough that we implement things that aren't specced

Ah Final, heh

the spare-time hackers can hack-up an implementation of the pragmatic protocol and the industrial side can use the idealized one, blessed by council

Link Mauve, TIL, not sure if this contributed to the success of Pidgin

When bookmarks or carbons were implemented for instance, they refused to merge the patches because the specifications were still draft and experimental resp.

flow, this worked in the early days, when XEPs went through the process much faster than nowadays.

flow, have you seen there's a lemmy instance btw. Maybe you want to try it out

It's not discourse but it's still some sort of forum

pep., yep, I've seen it

As I said above I think it would be useful to list/document common patterns and where/how they can be used

Maybe that can also be done by finally having that tagcloud for xeps

But I'd say slightly more explanation is required

> then there is a chance that you end up with two protocols: an idealized one and a pragmatic one mix vs muc