XSF Discussion - 2022-01-09

The need of a product is more for users. For XMPP specification it would be helpful to have developers for XMPP libs. If you are going to develop a lib, you will look into the design and use cases.

I think that without appealing users with modern looking clients and/or solutions, it's like the Titanic still moving forward after it struck on the iceberg.. no offense.

Define "modern looking"

> I think that without appealing users with modern looking clients and/or solutions, it's like the Titanic still moving forward after it struck on the iceberg.. no offense. Conversations app looks perfect to me. clean and simple. I wouldn't use it if it looked as bloated as Facebook Messenger.

Although... If there was an xmpp Client app that also let you manage your SMS text messages it would add an extra level of convenience for the end user.

for this has nothing to do with users and if the use clients or not

i was speaking from a point of coherent protocol design

i have the opinion that devs can also build good clients with very bad specs

but it is much more work

lovetox: I think a lot of the misunderstanding stems from the fact that we give almost anything a number and giving it a number doesn't mean any andorsement whatsoever

Compliance suite and/or 'stable' are the endorsements

Kinda

I've personally voted a lot of xeps into experimental that I don't agree with

I don't think it's my job as council to put that kind of barrier up. not due to lazyness but because I think (thought?) we had some kind of consensus that this is how the process works

I fact I'm describing that in my council application

However I do see how it having a number can signal endorsement to the outside.

Especially because other standards bodies (the ietf for example) put much more scrutiny into an rfc before assigning it a number

I'm personally actually leaning more towards the ietf approach

But I can't start voting that way (blocking experimental xeps) if we don't have a consensus that this is how we want it to be

It would also be somewhat weird to change the process 20 years in with that many (sorry) garbage xeps already having a number

putting council aside I think the best quality XEPs are produced if a group of people work on solving the same problem at the same time. meaning having the need for and implementing a xep in the same ~6 month time span. that can spark great discussions and great informed feedback because they are all implementing it. for example I actually kinda like what we did with jingle message init. three people implemented it; basically ran into the same issues and collectively came up with solutions for those issues. implemented the solutions and modified the xep. only that this happened over 2 years+ in the case of jingle message init because we client developers aren't always working on the same issues

at least not at the same time

i think this apprach puts council in a corner

you publish a XEP, a number of clients implement it

after they want it stable

council looks at it, and says, this is horrible from a design perspective, it does not fit good into our other specs

but you cant say no, because many clients use and implement it and they tell you: for what is council good if you obviously dont want the things we implement and work

so the whole big picture of the xmpp protocol design, goes out of the window for a more pratical, if X people implement it its good enough

even if it violates design principles of XEPs that we have since X years

i dont have a concrete example, thats just what i would fear if i were a council member

It's not like council is constantly moving ~garbage~ xeps that don't fit The Vision to stable

but if i think about it i really talk about the subtle things of a XEP - do i put this element in its own namespace or not - do i add this data as attribute or as element - do i wrap this into a <query> or not etc.

i have the feeling such things are almost never a stopper

In fact council is very rarely moving stuff to stable. (maybe because there is only garbage in experimental)

Yes xeps that are written in a single voice

That's true. And somewhat said. But I'm not sure if that's the most pressing thing we need to focus on

I mean we we obviously get better results if council were five individuals who are both elected and employed full time by their respective companies to write the xeps

But that's just not the case

We can agree to change the process but we can't magically make good protocol designers appear

i whised it was more like code review

someone proposes a XEP, then some maintainer goes like, change this, this this this

ok now we have something we can merge

does not mean it gets adopted

but at least its consistent with other syntax and approaches we have in other xeps

im not sure we need someone fulltime for that, maybe just the consensus that someone has the power to tell people that

Maybe some kind of Mentor.

Well, stpeter filled this role in the past - whether it was technically part of the role of "Editor" or not, it's definitely not today. Peter wrote and maintained a vast number of XEPs, recording community consensus from the mailing list. These days writing XEPs is not considered anyone's job in particular. I think that's unfortunate.

lovetox, FWIW, nothing stops a XEP author to gather feedback from standards@ or the MUCs (jdev@, xsf@ or in some cases even editor@ would be a godo choice). ✏

it's just that virtually nobody does this for whatever reason.

because they dont need to, if you can get your merge request merged without conulting the maintainer you probably would also just do

i understand that its different because nobody does own XMPP

it would still need somebody that consider it his own, and acts like it

well, the XEP author "owns" the XEP in that regard

you cannot get patches to a XEP merged without author or council consensus

(or an editor mistake :))

That's different to "owning" XMPP though

true ✏

i mean i know i speak obvious things, and i know nobody can magically make someone appear who does that

Summits were a good way to get everyone on the same page, or at least a couple of pages

MattJ, though summits were, at least from my perspective, to considerable parts attended by folks who are only barely working on public XMPP impls.

Yeah, in some way sprints were a good counter to that :)

i thought about more why i feel that way right now, and its all the new XEPs, there seems to be many that use some kind of "apply-to" or "fasten" mechanism, and also what currently is discussed on the list with "compatibility fallbacks" and for me it began with the still kind of unresolved deprecation of XHTML and the two styling xeps that resultet from that. their seems much movement but nothing that guides that into a good channel. We recently added that moderation XEP, afterwards it didnt receive so good feedback on the list, design wise, of course it fullfills the use case perfectly fine. Im really hesitant to implement any of these new things, and without implementation there is no feedback, hence they can not actively developed ..

at the time moderation was accepted, fastening was new and it wasn't clear yet whether it'd be continued and take off, so basing things on it made sense. now it's two years later and nothing's going on with fastening so it's not as clear it should still be used.

(irrespective of the reasons for any of that)

lovetox, initially, the experimental phase was designed for design discussions, not for implementation, so your hesitance isn't completely surprising. this is mostly showing the divide between the "first code then spec" and "first spec then code" people, I think.

the former are often funded in one way or another.

though I note that some of the feedback to moderation et al. should've come during the acceptance

e.g. "make a requirements section" etc.

I am not sure that the idea was ever to perform design discussions without having, at least prototypical, implementations ✏

on the other hand, we tend to hold on to "good enough" implementations. I am not sure what the current state is, but at least in the past, OMEMO was, and maybe still is, a prime example

the initial omemo spec works good enough, even though it has significant drawbacks, so the current omemo spec does not see much adoption (again, not sure what the current state is)

to be fair, initially omemo probably gained so much adoption because it filled a large specification hole that people really wanted to see filled ✏

to be fair, the initial omemo spec probably gained so much adoption because it filled a large specification hole that people really wanted to see filled ✏

fwiw, the subscription count of r/xmpp: https://subredditstats.com/r/xmpp

feel free to compare to r/matrixdotorg ;)

https://xkcd.com/1034/

I think the whole apply-to/fasten/mam-fc/... problem is that this is actually more like a server feature but it needs to go in client XEPs and also no client is relying on this server feature or expecting it, so no server developer puts time in this. A single hand that develops both server and thin (web) client and ideally wants to add the new features (replies, reactions, etc) prototypical would be very helpful here, as they would actually know what they need. But we're not going to get someone to volunteer for this as it's a hell lot of work. BTW: I once built this concept [https://gist.github.com/mar-v-in/e5a6c7f551dab7c833829d604a825d63], but I felt it doesn't make a lot of sense to further write this into a full XEP without also designing a corresponding server XEP which I felt not to be the right person for.

<hat:prosody-developer> In Prosody, properly supporting generic apply/fasten/whatever seems to demand yet another low-level storage API re-design, which has lower priority than finishing 0.12 right now. The current API is split into a fairly simple key-value store and and an append-only thing for archives, which had to be extended a bit for '425. Even PEP barely makes sense currently, due to being one level deeper than the currently fixed depth / width of key-tuples or whatyoucallit. </hat>