-
Link Mauve
“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.
-
Link Mauve
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.
-
Link Mauve
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.
-
Menel
Is that what everyone currently does with muc avatars anyway?
-
Zash
It is
-
Menel
Then its really at least historical 😀
-
Zash
Have we redefined 'Historical' to include things developed after the creation of the XSF?
-
Link Mauve
Zash, I might propose a change to XEP-0001 to this effect.
-
Menel
Hm. Indeed it would be cleaner to just repropose it as a normal xep and not historical
-
Link Mauve
Because we have no other status to accept a sub-par specification which is despite that in widespread use.
-
Link Mauve
But IIRC the issue with that one was too many numbers related to avatars.
-
Link Mauve
So even historical might not fit.
-
Menel
I think it should be accepted if Everyone uses it anyways..
-
Link Mauve
I would think so too.
-
pep.
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)
-
Zash
Informational would work
-
Zash
"People are doing XEP-0153 in MUC like this. GLHF"
-
Link Mauve
I once proposer a (better imo) alternative, about exposing 0084 on a MUC room.
-
pep.
What's the difference though, Zash
-
Link Mauve
This time I made sure to add it to 0045, which as everyone knows grows up when you aren’t looking.
-
pep.
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
-
Link Mauve
It got rejected once already.
-
pep.
Yeah well council can get over it for once
-
Link Mauve
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.
-
pep.
Maybe someday process will be less rigid
-
Link Mauve
It wasn’t so much about process this time.
-
pep.
MUC-PEP would actually be helpful :/
-
pep.
In other places as well
-
mathieui
Isn't there a MEP protoxep already?
-
Link Mauve
mathieui, XEP-0316.
-
mathieui
Right
-
pep.
Ah well if it's already specced, then the MUC avatar spec just needs to reuse it
-
Link Mauve
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?
-
Link Mauve
I just read it again and the only mention of lifetime is that it is tied to occupants.
-
pep.
For MUC avatars?
-
pep.
For occupants maybe do so only when a nick is registered or sth?
-
Link Mauve
For MEP.
-
pep.
Unless you equal non-anonymous to "private" (which isn't the case in the wild), then, it might make sense yeah
-
Link Mauve
The examples are about COIN stuff, but it could be applied to 0084 as well.
-
Link Mauve
pep., right, having a consistent nick is the actual requirement for MEP nodes to be persistent between joins.
-
mathieui
couldn’t a recent MEP piggyback on occupant-id?
-
pep.
Is it necessary?
-
pep.
MUCs have access to realjids
-
pep.
Persistency doesn't even need to be limited to non-anonymous
-
pep.
A MUC may want to GC nodes though sometimes(?)
-
Link Mauve
pep., in this case, having JID a take JID b’s nickname would cause the service to delete all nodes?
-
Link Mauve
That would be a kind of leak for which JID ends up using which nickname though.
-
pep.
If the nick is registered, no?
-
Link Mauve
Is it always?
-
pep.
No but that could be a constraint for persistency
-
moparisthebest
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
-
moparisthebest
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
-
flow
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
-
flow
like a source repo for XEPs in development, stable (snapshot) versions of XEPs, and a forum to discuss this
-
flow
+ the machinery around that source repo for linting, building and publishing those XEPs
-
flow
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
-
Link Mauve
flow, isn’t this “forum to discuss this” what standards@ is?
-
flow
Link Mauve, sure, and while I am subscribed to many mailing lists, I believe that discourse would be better
-
flow
and even if it's just because you can tag things. tags help a lot with grouping topics about the same complex
-
flow
and the obligatory reminder that you can use discourse just like a mailing list
-
moparisthebest
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
-
flow
yes, it will be a bit different than your "normal" mailman mailing list, but I think it combines the best of both worlds
-
flow
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
-
flow
so council should try to be aply its corrective factor to that, but it is certainly not able to decide how the protocol evolves✎ -
flow
so council should try to be apply its corrective factor to that, but it is certainly not able to decide how the protocol evolves ✏
-
flow
but what I really like to see is mechanisms that prevent that non-idomatic and/or (slightly)-flawed protocols get widely deployed
-
mdosch
How would you prevent people from implementing and deploying something?
-
flow
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
mdosch, don't, but we are hopefully able to convince them about better approaches (if there are any)
-
moparisthebest
Everyone should express their opinions, members and council alike
-
mdosch
> 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?
-
flow
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
-
wgreenhouse
> 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?
-
Link Mauve
flow, OMEMO the XEP allows you to encrypt arbitrary payloads, just that everyone implements the pre-standard in order to be compatible with everyone.
-
flow
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
-
flow
wgreenhouse, that is what we have now a XEP with a new namespace, but nobody(?) implements the current OMEMO version, only the old one
-
Link Mauve
moparisthebest, non-members as well.
-
flow
Link Mauve, per-standard?
-
wgreenhouse
flow: sure. that's how it goes :-|
-
Link Mauve
flow, pre-, aka XEP-0384 version 0.3.
-
flow
Link Mauve, how is that pre? IIRC it's simply experimental?
-
Link Mauve
Version 0.3 is basically the first draft, which got implemented in Conversations before being published as a XEP, and which everyone follows.
-
Link Mauve
0.2 already incorporated changes from the standardisation process, which made it incompatible with what was deployed in the wild.
-
Link Mauve
… or not? It seems to still be using the legacy namespace.
-
Link Mauve
Maybe I’m remembering the chronology wrong.
-
flow
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
-
Link Mauve
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.
-
flow
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
-
Link Mauve
So only 0.0.1, 0.2 or 0.3 correctly describe the current implementations.
-
Link Mauve
With the old issue that non-GPL implementations couldn’t use Axolotl back then, IIRC that changed at some point.
-
flow
yep, but that's a different discussion that brings back some painfull memories from that era✎ -
flow
yep, but that's a different discussion that brings back some painful memories from that era ✏
-
Link Mauve
^^'
-
msavoritias
> 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
-
Daniel
there is twomemo aka omemo:1 which uses SCE. and the spec was written very openly
-
Daniel
we had a two day meeting
-
Daniel
with lots of people
-
Link Mauve
flow, oh and 0.2 was already using the urn:xmpp:omemo:0 namespace, probably 0.1 as well.
-
pep.
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
-
Daniel
that's why the current XEP also has a billion authors
-
pep.
What I'd like to see is common patterns more documented
-
Daniel
but implementing twomemo is far, far more complex than siacs omemo
-
Link Mauve
Daniel, is the current omemo:2 named threememo? :D
-
flow
Daniel, right, omemo:2 was very openly developed, I was talking mostly about the OMEMO ProtoXEP
-
Daniel
no. the latest NS bump is BS and doesn’t really change anything
-
Daniel
it's still twomemo
-
pep.
It's not implemented anywhere anyway.. bump or not
-
flow
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
-
Daniel
pep., yes. but the protocol has become tremendously more complex
-
Link Mauve
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).
-
Link Mauve
No one implemented those AFAIK.
-
pep.
Daniel, you mean between :1 and :2?
-
Daniel
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
-
msavoritias
The only client having recent omemo is the UWXP or something in windows
-
pep.
Daniel, oh
-
msavoritias
And Kaidan in a bit supposedly
-
Link Mauve
pep., no, between encrypting the body only and encrypting arbitrary payloads.
-
pep.
Link Mauve, ?
-
flow
+ siacs omemo works good enough, so there is not much intrinsic incentive to switch
-
Link Mauve
flow, “good enough” for plain text messages and nothing else.
-
flow
good enough, given that is how we communicate right now :)
-
Daniel
plus we had two years of pandemic between the twomemo sprint and now
-
Link Mauve
We don’t use this right now.
-
pep.
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?
-
Link Mauve
Ah, you mean in general? Yeah perhaps, but that’s one of the reasons I don’t use OMEMO (at all).
-
flow
pep., I am sorry, I don't get the question? :?
-
pep.
flow, not a question, a comment. On being careful about stopping stuff because it's not idiomatic
-
flow
well you can't really stop stuff, council can probably deny their blessing
-
flow
then there is a chance that you end up with two protocols: an idealized one and a pragmatic one
-
pep.
Which is already a big blow and many projects actually care about this blessing
-
flow
I am not aware of any FOSS community projects that care *much* about council blessing
-
flow
my guess would be that only industrial certified project care about the wax seal on the document
-
flow
but I don't think this is a problem
-
Link Mauve
flow, there was this project, Pidgin, which refused to implement specification before they were final.
-
pep.
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
-
pep.
Ah Final, heh
-
flow
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
-
flow
Link Mauve, TIL, not sure if this contributed to the success of Pidgin
-
Link Mauve
When bookmarks or carbons were implemented for instance, they refused to merge the patches because the specifications were still draft and experimental resp.
-
Link Mauve
flow, this worked in the early days, when XEPs went through the process much faster than nowadays.
-
pep.
flow, have you seen there's a lemmy instance btw. Maybe you want to try it out
-
pep.
It's not discourse but it's still some sort of forum
-
flow
pep., yep, I've seen it
-
pep.
As I said above I think it would be useful to list/document common patterns and where/how they can be used
-
pep.
Maybe that can also be done by finally having that tagcloud for xeps
-
pep.
But I'd say slightly more explanation is required
-
moparisthebest
> then there is a chance that you end up with two protocols: an idealized one and a pragmatic one mix vs muc