XSF Discussion - 2023-02-08

> Guus: > 2023-02-07 08:04 (GMT+01:00) > If (I'm not saying it is) we deem it important for XMPP to be well represented, maybe the XSF can consider funding people (eg: council and board members) to attend meetings like these. +1

> MattJ: > 2023-02-07 08:21 (GMT+01:00) > I'm not saying there isn't more we can do (there always will be), but it's not like we're doing nothing I used to claim we should move from the passive corner to the active one

in general, no saying folks are not invsting time. But for me it feels often limited to resources

Daniel: I think it will be moved by one week

emus: yes thank you. I saw the emails

Daniel: ok

I always assumed that the XSF not doing more which money is because there is no-one really taking care of financial stuff in the XSF (besides the absolute minimum that is required to keep the org going). has that changed or is my assumption wrong? ✏

My assumption is that these are two sides of the same coin.

I think our treasurer expressed quite explicitly that they're happy in using the money if we have good ideas how

(which are acceptable under the regulations the XSF is under)

Yeah, we don't need much money if we don't spend it. If people have concrete proposals (i.e. including amounts) then we can decide if that's something we want to allocate resources for. The only such proposal in my memory in recent years was paying someone to do social media and community management stuff, and that did not get approval.

thats too bad

xmpp could use more outreach

MattJ: did the XSF pay for you to go to IETF London? I'm honestly asking because I don't know. If they did I think this should have been communicated more clearly (as a good thing)

MattJ: Oh, I didn't know that. Do you remember what were the reasonings for both the ask, as for the disapproval?

Daniel, I got reimbursement for the remote IETF participation fwiw

jonas’: OK good to know. I know that it was discussed. But I wasn't sure if it had actually happened

Plus the XSF paid for the conference room for summit (although I'm also a bit confused on how and when that actually got decided)

So it's not like the XSF never pays for anything

If we want to attract sponsors in the future we should communicate more openly on what we spend our money

I think that better communication would be a good thing, but I don't think it'd matter much to potential sponsors. Most of them likely do not care, as long as we're not spending it on things like sponsoring the Taliban.

I fondly remember the days when there were regular blog posts about XSF income and expenses

any blog posts, really. The newsletter is most excellent, but it would be nice if that was not the lion share of the blog. I fully realize that I myself can help fix that by submitting blog post content...

I think emus and team have been doing a very good job wrt PR lately.

it's just the income+expenses that are missing and i don’t think that's the comm teams fault

I in no way want to suggest otherwise.

plus before Covid we had a sprint budget that I think we got to used once before the pandemic ruined everything

I don't agree that this is all that's missing. We used to do a lot more with the blog - post about elections, board goals, etc.

I'm a big fan of those sprints!

ah, board goals :) https://github.com/xsf/xmpp.org/issues/564

> I'm a big fan of those sprints! yes!

Daniel: it was agreed that the XSF would fund my IETF attendance, yes. Have I actually submitted the expenses yet? No... 😅

I am hoping the XSF will also cover at least some of the cost of the printing I did for FOSDEM

SCAM has a budget, but it was obviously exceeded this year due to the conference room

Assuming that the printing was all XSF-related and printing costs were within reasonable ranges (conforming to regular prices), I'd hope that you'd be 100% reimbursed.

when the scam budget was allocated we did not account having to pay for a the venues. the scam budget was/is for printing and maybe some snacks

Yeah

so i would hope that the conference room either doesn’t come out of the scam budget or the scam budget will get raised significantly

iirc the SCAM budget was 1000 euro / year. I truly have no idea what a conference room costs, but was it over that?

a little over 2k

wowza

The budget IIRC was set in USD, and the conference room was 2k EUR

oh, you are probably right.

At least we got a lot of entertainment out of the coffee machine and the proprietary app required for connecting to the projector.

I never did get my hot chocolate

Demand a refund!

I think the machine rejected the notion of it also having to deal with chocolate.

Guus [09:25]: > Assuming that the printing was all XSF-related and printing costs were within reasonable ranges (conforming to regular prices), I'd hope that you'd be 100% reimbursed. Some are clearly XSF (newsletter, etc.), but what about project-specific materials?

I actually think it would make sense to give summit it's own budget. because for normal sprints I think it is reasonable to have the sprint host organize some sort of venue. while summit needs it's own 'proper' venue ✏

MattJ: I'm not sure if there's precedent for project-specific materials. To me, it would be not out of the question to reimburse for that, but maybe there's an argument to be had there. As for XSF-specific stuff, that's a no-brainer to me: 100% reimbursement.

I’m sure the XSF benefited from the fact that there was marketing material at the XSF booth even if some of it was project specific.

so unless you want to get reimbursted for the life size plush snikket you had made I'd say it's probably fine

excuse me what there was a plush

No 😂

From what I could find from what I asked to be reimbursed and received from the XSF in the past, that excluded project-specific stuff, but did include things like the XMPP-logo sticker, the XMPP flags, taxis to/from the XSF dinner and some lunches at the summit.

I'm a bit ambivalent on reimbursement for project-specific stuff. Where do we draw a clear line?

or: do we offer something like this to all members / member projects?

I wasn’t at fosdem so I don’t know what MattJ is refering to. but what i meant to say that the 'newsletter' he made for example is fine

the 10ft banner "snikket is awesome" maybe not

generic stuff is fine to me. But Prosody stickers? hmm.

Yes, the newsletter, client comparison chart, some leaflets introducing/explaining XMPP

How do you see those as 'project-specific' ?

Alongside that I printed materials for Movim, Snikket and Cheogram

ah. :)

Also some stuff from freie-messenger.de

oh, I didn't realize that you printed project-specific stuff for many projects.

Did you volunteer that, or did those projects ask you? If the latter, maybe look at them first, for reimbursement?

Otherwise, I'd personally be more comfortable not getting this from the XSF (especially since this is an after-the-facts kind of thing). I would be willing to split the bill with you personally though, as bottom line, this helped the community.

So the background is that last year^Wtime, I printed some Snikket leaflets and brought them with me

There was almost nothing else at the stand

This year I didn't want that to happen, so I made some generic XMPP stuff, and I told folk that if they sent me materials I would get them printed at the same time when I went to the print shop

Thank you.

I'm with Guus, basically, including the "splitting the bill" part, the more the merrier.

I'm happy with the results, we had a range of materials available and it was significantly easier to explain XMPP and how it's an ecosystem of software and services

but I think it would also be good if board had a discussion how this can be improved for the next event; I think having materials there is a good thing™ and giving projects implementing XSF standards an opportunity to present themselves with a small budget supported by the XSF to improve the XSF stand, seems sensible.

but I get that a post-fact thing may be a bit irritating to onlookers

If I absolutely needed to know the XSF would cover the expenses I would have sought budget approval in advance, or just not done it, but TBH it's fine either way, I don't regret doing it and there wasn't a lot of time to spend discussing specifics ✏

In my mind when I planned it, there was the SCAM budget. But with the surprise last-minute expense of the conference room I understand that this year was a little different to usual with regards to cost.

Oh, and I also bought the leaflet holders, which are now packed in the XSF's FOSDEM boxes

That was because the year *before* 2020 we'd actually had quite limited space on the stand, with too many materials and demos taking up space on one table

Again, thank you. I definitely want you to be reimbursed, as I admire what you did and think it added a lot of value. I'd just prefer to not have the project-specific stuff be reimbursed through the XSF - but I'll help you cover those costs. That's maybe a bit more of a hassle with splitting bills, but will still get you what I hope you'll find fairly reimbursed.

Nah, I don't mind, we can call it a donation to the ecosystem :)

I don't see a clear way for the XSF to start funding project specific stuff without it becoming a minefield (wait until Isode want stuff printed... :) )

literal minefield, I see.

Haha

Just an example, that it's not only open-source projects in the ecosystem

Well, we could device some sort of 'budget-for-marketing-for-member-projects' scheme - that could be fair-ish, and beneficial to in particular the smaller projects.

In fact, I think that most of the XSF's money has come from non-OSS projects (or freemium OSS projects).

but lets get that in place _before_ spending the money :)

if it's just a few bucks for flyers and those are at the XSF stand, and are positive (i.e. no degarotary statements about competitors or so), I think I wouldn't have an issue with that.

Kev, and the people providing that money wanted it to support other non-OSS/freemium projects? :)

> , and the people providing that money wanted it to support other non-OSS/freemium projects? :) Oh, I doubt it. Just reminding folks.

Or, well, not *only* such projects.

A rising tide, all boats, floating, etc.

Is Kev going nautical on us?

Aye.

I'm not naughty, I'm a good boy.

I'm resisting an urge to comment.

let's just say that I think a blue/white striped shirt would look good on intosi.

🤨

The costs for FOSDEM/Summit generally include the van, taxis, and materials for the booth/lounge. That's what we allocated the SCAM budget for (among other events, of course). The costs for the venue were indeed new, and as we had a majority of board members in agreement that we should do that, knowing the costs, I went ahead. I don't consider it part of the SCAM budget. Some details were shared on the board mailing list, and Peter also requested to send in the invoices after event (as usual). So yes we didn't have an explicit board meeting on this, but I will definitely include it in our next meeting.

Everything about organizing this was not very well done, and I'm sure we'll do better next year.

Understandable, given the time since last time :)

As for funding things in general and the lack of attempts to get sponsors, is basically because not much happened that required additional funds. I think this will change dramatically this year.

In Stream Management, what is the expected behavior when a peer sends a 'h' value that is _lower_ than the value that it sent previously?

fatal stream error, disconnect

Technically there's rollover, but that would mean the server is acking 2**32-small_n stanzas, which should also lead to that stream error.

Lol

I hadn't thought of that

if a stream mangement participant acks more stanzas that where send then this should lead to a stream error

because either the acking participant counted wrong, or the participant that send the stanzas

There's a bug, it should be reported and fixed.

you could potentially implement a robust mode that simply deactivates/ignores further sm related actions, but that is rarely useful ✏

ignore the bug? then it'll never be fixed

and others will adopt the same bug!

I think the words in 6 Error Handling are clear that the right behaviour is to close the stream.

Zash, agreed ✏

pfff, words in specs

The peer acks not more, but less stanzas in my question

but yes, we are all on the same page that a stream error is the right thing to do™

Less than it acked earlier

No, it acks more, because rollover.

Guus, what intosi said

Right

you can not unack stanzas, the ack counter is only ever going forward, with the technicnal limitation that its a uint32 with defined overflow semantics

So if your rollover logic is working, the stream error should follow naturally.

Is anyone testing rollover? :)

Zash: we are :).

testing? dunno, but IIRC smack has code for it

We apparently have broken rollover code, because it did not catch this

I fear we might not have rollover handling at all 😱️

dos vector detected

it would take DoS levels of stanzas to reach it anyway, right? 🤷️

I didn't say "fast dos vector detected" :)

Or very long lived connections that keep resuming indefinitely. Reaching 2**32 stanzas will take a while though ;-).

connections -> sessions.

I'd expect either you get a stream error, or it continues until around 2⁵³ and experience Weirdness, or wrap around at 2⁶⁴. Mmmmm number types, so much fun.

Hm, are there error conditions for mis-count bugs?

We use `undefined-condition` with some text

Assuming your peer doesn't cut you off because you didn't send a u32.

Example 16 has an error for that.

(it's defined in the text right above it.)

Oh when did `handled-count-too-high` appear?

Didn't check, but "recent".

Guus committed that in 2018.

> The budget IIRC was set in USD, and the conference room was 2k EUR Luckily that's the same these days lol

Exchange rates are well on their way to be back to the old levels, I noticed when I last did my invoicing.

Guus: do you invoice in your customers currency?

Daniel: only for (some) Americans. Some stereotypes aren't pulled out of thin air...

*US Americans, I assume

Oh yes.

Dunno if it's been seen, I'll ask again. There are people in Asia around here right? Even if not an XSF member. That can be sent to an IETF meeting in Japan. It'd only be fair that the XSF makes an effort to encourage local people to go I feel, instead or in addition to volunteers from other places.

For some reason, the larger that the organisation is, the _less_ likely that they're aware that something exists outside of the USA.

Guus, is that a reflection of your customers, or a reply to pep.?

No argument here, pep.

a reflection of dealing with _some_ of my US-based customers.

pep.: I generally agree with you. For IETF though I feel like this should be somebody that is rather close to the XSF

I've had large orgs sent me a check. My local bank was amazed. :)

(also, home-made cookies. I did not forward those to my local bank though)

Like for normal conferences to staff booths or give talks we shouldn't fly someone to the other side of the world

Not just because money but also because of that thing called climate change

s/change/catastrophy/

Daniel, I don't know. I think that would also be best, but I think there needs some kind of bootstrapping happening. Something something chicken/egg

bootstrapping by throwing someone into an IETF meeting sounds harsh

:D

I've attended the MIMI session remotely and it was pretty arcane to me

and I *am* close to the XSF, or at least I'd think I'm above the median

And yeah, preferring local people for that thing called climate something

Zash: my invoicing system is a set of text files, Libreoffice to generate a PDF, and email. Takes me about 1.5 hours/month. I do not see automation pay for itself there.

We should find ways to encourage sprints and/or conference participation outside Europe. But I feel like IETF is the worst place to do that

I agree with sprints.

I don't know re IETF. I'm not going to die on this hill but I think it's important that we at least make an effort in this direction. And if it's not (yet?) possible then fine

someone™ could send a mail to members@

(not me, I'm not in there anymore :p)

I may have asked already, does anybody handle see-other-host?

Or gone, with a pointer to some other place

I know that see-other-host is used by tigase clustering

yes, Tigase is using see-other-host and our software is using it

also gone is used to communicate that cluster node is being shutdown

I would kind of see more of these redirects supported in clients. I should open issues here and there

just be careful to not introduce security issues with those…

Well they're in the protocol already..

e.g. following a <see-other-host/> before TLS is probably a bad idea

Probably

unless you enforce the same certificate name bindings on the destination as you would've on the source

Or is it. You can still check the certificate on the dest

:)

but a naive implementation wouldn't do that as you have to carry the information that you came from a redirect and which redirect you came from along

MIX-capable clients? Siskin and an old branch of Conversations?

It's probably a bit of a stretch to call that branch mix-capable

A bit of a stretch or a lot of stretch? Just having something capable of joining would be a start

Alternatively I may need to write a test client

kaidan also has a branch but not at working condition eiter

Joining (via direct join not PAM) receiving and sending basic messages and showing participants if a recall correctly.

But depending on when or where you want to play around with mix it might make more sense to start from scratch based on C3

Did we ever define a MUC style direct full resource join?

IIRC it was mentioned as a potential transition step for PAM-less servers

Depends on what you mean by muc style but IIRC Conversations only does that

Ah never mind. I'm wrong I think

Where is the PAM-less join specified?

So far I have only found text stating that PAM is required

I don't know if it made it into any of the specs yet. I'm fairly sure, without checking, it was just for the client to send to the room the same stanza (but full rather than bare JID) that the server would have sent on the user's behalf. ✏

My cursory reading suggests it isn't in the spec, indeed

does it even make a lot of sense to do backward compat that way? if MUC isn’t going anywhere for a while and you want legacy clients to still join your server via MUC then clients that support mix but have server that don’t use mix-pam can fall back to muc

i'm not saying don’t spec it but as a client developer having one way to join a mix room and if that doesn’t work fall back to muc seems simpler

Makes sense

It also makes sense if you have MUC code and want to bolt MIX protocol handling on top of it

So you can do full or bare JID joins, with MUC or MIX syntax .... mmmmm multiplication :S

Okay, I'm confused. What does the participant server need to implement?

You'd think this question would be answered, not raised, by "XEP-0405: Mediated Information eXchange (MIX): Participant Server Requirements"

With full JID joins, nothing

With bare JID joins, PAM?

I looked at PAM, but the syntax and namespace is different

Oh no

so I have to implement both?

It's not clear

Which namespaces are different? I can easily believe that splitting the specs has led to updates not propagating to all of them.

yes as someone who wants to join a mix room my server has to support 405

when i join a mix i sent a <client-join channel="room-on-other-domain"/> to my account

so there would probably be a mod_mix_pam and a mod_mix

For example: https://xmpp.org/extensions/xep-0405.html#example-4 has the client sending stuff to its own server in the 'urn:xmpp:mix:pam:2' namespace, but XEP-0376 only has 'urn:xmpp:pam:0'

i think it is relatively save to ignore pam

you only need mix-pam

376 and MIX are independent.

> In future, this specification MAY be incorporated into Pubsub Account Management (XEP-0376) [4] (PAM) which follows a similar model. MAY future...

You shouldn't* need anything from 376, just what's in 369 and related. [* But, of course ... ]

Aha

Okay, so when people talk about PAM they mean MIX-PAM and PAM is an attempt to make it generic that nobody actually uses right now

(correct me if I'm wrong)

well sometimes when people talk about PAM they mean PAM

but in the context of mix they mean mix-pam

PAM the idea came first, for use with 60 pubsub. When MIX the idea came along, using the same model seemed to make sense, so people used the same term.

As I recall.

yes

that's how i remember it too

So you could think of it as "60 PAM" and "MIX PAM" if you liked.

is PAM a thing in the UK by the way?

Clear as mud :)

I'm worried this will make sense to me one day

Pluggable authentication modules?

the cooking spray

mod_auth_pam_mix?

Not that I'm aware

Curious: does anyone happen to know if XMPP is used in the world of railways / rolling stock? I keep finding job offers that are not really specific for XMPP, but do mention it, from companies that seem operate in that business. Multiple countries, even, Italy, the UK.

oh, digging through the the layer of recruiters, this all seems to boil down to Hitachi Rail Limited.

XMPP on Rails?

Hah.

Aaaaaw https://www.hitachirail.com/search-results/?Q=xmpp

> Your search for 'xmpp' has returned 0 results: Did one expect results?

Ah, didn't read the above messages.

There's one mention in this paper - I'm not sure if it's related to Hitachi, but mentions real-time monitoring of rolling stock over XMPP, I think: https://www.researchgate.net/publication/326316004_The_railway_predictive_maintenance_and_the_enabling_role_of_the_Internet_of_Things

anyways, just curious.

dinnertime! byes!

disco#items rail car contents? mmmmmmmmmm

https://xmpp.org/extensions/xep-0309.html anybody using the 'urn:xmpp:public-server' NS defined in there? What does 'public' mean exactly?

I'd say that means not private

👏️

> The server is a public node on the XMPP network

Good question though, that's all I see

Yeah, it's defining a word by using that same word

wurstsalat, emus, where can we talk about providers.xmpp.net? https://codeberg.org/joinjabber/collective/issues/15

> MattJ: > 2023-02-08 09:47 (GMT+01:00) > Yeah, we don't need much money if we don't spend it. If people have concrete proposals (i.e. including amounts) then we can decide if that's something we want to allocate resources for. The only such proposal in my memory in recent years was paying someone to do social media and community management stuff, and that did not get approval. and one other certain topic 😊

pep.: in our repo? or what do you mean? I recommend to wait until we are done with automation and new parameters perhaps

I know of two topics where money has been proposed as a solution: infrastructure and editor tooling. Neither had concrete proposals :)

Maybe we should throw money on coming up with proposals?

> Daniel: > 2023-02-08 10:06 (GMT+01:00) > I think emus and team have been doing a very good job wrt PR lately. thanks Daniel 🧡

> MattJ: > 2023-02-08 07:20 (GMT+01:00) > I know of two topics where money has been proposed as a solution: infrastructure and editor tooling. Neither had concrete proposals :) We had tasks, effort and amount of money specified

MattJ, fwiw, questions concerning money I've had in the past have been shot down rather quickly, or left completely unanswered, so yeah there hasn't been much concrete stuff proposed.. :/

emus, okay, you're right. But you know I can't get into this topic again... :)

emus, I mean stuff that could be common to both our projects that we could help with

We'd help on the technical bits if there's a way we can reuse the list, or even just the tooling

Is there a place that isn't here maybe where we can discuss this?

> ralphm: > 2023-02-08 11:46 (GMT+01:00) > Everything about organizing this was not very well done, and I'm sure we'll do better next year. Yes! Certainly in!

"I would want servers that dont accept fascists and such." Yes only list servers where the admin has to interview the new user before allowing them to sign up 🤣

moparisthebest, ..

> MattJ: > 2023-02-08 07:24 (GMT+01:00) > emus, okay, you're right. But you know I can't get into this topic again... :) I know and cry :-)

The worst part about that site is users hear about this great XMPP thing and type joinxmpp.org and are immediately confused about what this jabber thing is

True

oh the xmpp vs jabber again XD

Yeah whatever. As long as we use either XMPP or Jabber there will be issues with that anyway

> pep.: > 2023-02-08 07:25 (GMT+01:00) > We'd help on the technical bits if there's a way we can reuse the list, or even just the tooling you can reuse the list already if you want

emus, I don't just want to reuse the list, we don't want to be passive about it

the interest is the gathered data from the server. and how to automate that said data

pep.: Why not host a copy of the website with s/jabber/XMPP/ on joinxmpp.org ? Then no one will be confused

Can be trivially automated, I'll do it if you want

So we're alternatively named JoinJabber and JoinXMPP? And we also bridge chatrooms? :)

Just hiding them behind appropriate links would be enough I think

meh

I know I'm quick to jump into bikeshed discussions, but this is too much

Type in jabber.org or jabber.com into a browser like a new user might

xmpp.org works

Jabber still exists as a Cisco product that isn't quite XMPP, it's past time to let it go, I can't in good conscience link people to joinjabber

Yes yes

Then don't

well you already dont like the CoC we have so

> pep.: > 2023-02-08 07:41 (GMT+01:00) > emus, I don't just want to reuse the list, we don't want to be passive about it Ok, but then propose in the gitlab repo, we dont have a channel yet

emus, ok

MSavoritias (fae,ve): no I have no problem with that, I just think "not allowing fascists to register" is an absurd and impossible task, it's perfectly fine to have not banning bad users as a reason for list removal in the CoC but wording it like that isn't helpful

Unless you have some suggestions for actually preventing fascists from registering in the first place I'm unaware of?

moparisthebest, where have you seen this btw?

pep.: The issue you linked

What does NG stand for in XEP-0409?

Next Generation

oh. thats in progress think. we havent decided on the exact wording yet

moparisthebest, so a random comment that isn't a concrete proposal?

Yes

moparisthebest, ok get lost please

And I'll leave it at this

Don't get me wrong I really like everything you all are doing over there *except* using the wrong name and holding joinxmpp.org hostage which could be easily remedied

If you don't want comments on your CoC proposals maybe don't bring it up in this room :)

You know you're just playing on words here and you seem happy about it

thats not the CoC even ><

so you are wrong on that too

moparisthebest, this isn't the right place to discuss this (if there even is one). I feel your comment is picking the least favourable interpretation. It's possible to have a policy and enforce that policy on a best-effort basis, even if it's not possible to vet every user and every message. Abuse reports are a thing.

As for Jabber/XMPP, we'll never settle that one either. Just let them be.

Right, I believe I said as much, at least I tried to

XMPP/Jabber is settled, search it on any search engine, the top result is Cisco jabber which last I heard wasn't even compatible with XMPP

That's just like.. your opinion

What part is opinion

Wikipedia doesn't even know what it is: https://en.wikipedia.org/wiki/Jabber

The part about Cisco Jabber appearing first is fact. The part about Jabber therefore being unusable is opinion.

Ah sorry you're the incarnation of neutrality and facts again, I forgot :) ✏

MattJ: fair

also Cisco Jabber appearing first is Google's opinion :-°

And ddg, and bing

Still an opinion

Differences of opinion are normal and okay. We don't need to fight it out. If you don't want to participate in the joinjabber project, that's totally fine. We don't need to know :)

I guess you have to ask yourself who you are trying to get on XMPP, people already here for decades who know what jabber is, or people who haven't heard of either jabber or XMPP

moparisthebest, we get it, you disagree

So what about my offer to automate changing the text at joinjabber.org to XMPP when viewed at joinxmpp.org ? Don't need to answer now it's a standing offer

There's xmpp:chat@joinjabber.org?join if you're serious about it and if it's not just a one-off. I'm not the only one to decide, but I already feel like it's going to be a pain

Got it, I'll work up a POC and propose it there, thanks

Great!

I think it's such a waste to focus on the name when the interest of this project is something else, but whatever

I like what you are doing with joinjabber. Website looks great

Thanks! That's a lot of work from Kris for the migration. And Line and Guillaume for the graphics :)

Hi XEP people! I'd like to hear your comments on this XEP lifecycle diagram:

https://spacecloud.one/upload/532f57e5-0e38-4f90-828b-8c689b1ce5f3/122011e3-2995-4567-a17d-7620bd71867d.png

any suggestions for improvements? is it correct?

Experimental ↔ Deferred

Yeah, if you can, I would amend that part

https://spacecloud.one/upload/f124f32a-f796-4ddc-a69b-27bbaa6366fa/8132ea5e-24b3-4275-8935-eff785a18aab.png

It looks like the normal transition would be Experimental -> Deferred -> Proposed

like this?

Deferred should be an exception state (although it's certainly a common one), the normal transition would be Experimental -> Proposed, if you're trying to explain the lifecycle to someone

So maybe just Experimental <---> Proposed, with Deferred to the side

Also there are some inconsistencies if you compare it to XEP-0001's diagram: https://xmpp.org/extensions/xep-0001.html#approval-std

Does Deferred serve a purpose?

For example, XEP-0001 shows that it can go directly from Experimental to Retracted, but yours does not allow that

XEP-0001 suggests it's also impossible to retract a deferred XEP :)

(unless you update or propose it first)

{ Experimental ↔ Deferred } → { Proposed Retracted Rejected } { Proposed → Stable → Final } → Deprecated → Obsolete ?

I need to add ↔ to my keyboard layout!

> Does Deferred serve a purpose? Very good question :)

yeah deferred seemed always a bit useless to me

basically the unpopular xeps are there

and they may be implemented and resurected

wurstsalat: thanks wurstsalat!!!!

It's Experimental + time without changes. You can find that by sorting the list by date.

yeah

I feel like it's good to have a "we're not actively working on this" status, but I think the "hasn't been updated for N months" has not turned out to be a good heuristic for that

yeah

I liked the idea I saw in the mailing list the other day

of having experimental xeps being added by default without votes

MattJ, agreed. If we kept using the same heuristic, I'd increase it to something like 3-4 years..

and just vote on the stable ones

something like experimental -> stable -> obsolete/retracted

https://spacecloud.one/upload/0403cf68-8c7e-4a4b-b47a-1809001c92ef/dbd0404a-edb4-4493-b9e8-31553d06ca82.png

how's this?

Does a Deferred XEP need to go through Experimental before going to Proposed again?

Council issued a last call for a deferred xep today ✏

wurstsalat, so you need a link from Deferred to Proposed as well :P

So no?!

I think I'd put it outside of the lifecycle box.. with dashed lines.

We can do whatever we want, these are not laws of physics :)

One could argue that the state transition through experimental is implicit

it doesn't have to be formally correct, but it should be guiding people who don't know anything about the process. I plan to show it here: https://xmpp.org/about/standards-process/

Deferred kinda sounds like it was an explicit decision to Defer the XEP, maybe it should be? Eligible if there doesn't seem to be any movement, either in discussion or implementation.

emus, wurstsalat, re providers', would you join xmpp:servers@joinjabber.org?join maybe to chat there?

For ... 25% of the age of Jabber. (Thus in like 2004, it would have been ~1 year, now more like 5)

pep.: Its not that I am unwilling to discuss, and we always have been, but see this: I haven't even managed to publish the newsletter. On the project we are really busy with automation, and reviews are pending. Maybe it would make sense to discuss after we have published, when I look at our current capacities

I prefer to spent my time there

but maybe one of the other want to

Still you can make proposals to the gitlab repo if you want

pep., I just joined there ;)

wurstsalat, ok thanks :)

https://spacecloud.one/upload/8f4b2976-c8c3-44a2-8109-a3e6179ea5a3/39d7fb88-7d90-44bf-88e6-55d84eeed9bc.png

so how about this?

emus, ok sure. we're just trying not to duplicate the whole thing again. But if cooperation isn't smooth it will certainly be easier for us to do our own thing. (Don't get me wrong I understand the lack of time/motivation)

wurstsalat, bidirectional arrows are not possible here?

Okay, then maybe state the differences you see and we can respond accordingly or tell what changes are up to come anyway so you dont need to do it

pep., it's mermaid syntax, they are possible. but I tried to be closer to https://xmpp.org/extensions/xep-0001.html#approval-std

Finally: https://xmpp.org/2023/02/the-xmpp-newsletter-december-2022-january-2023/

Matt, the people on twitter must love you, the post with your presentation got 2nd best view stats from all posts 🙂 Just the impressions from the Summit got more 😛

I have no access to the xmpp twitter account through twitterdeck - something changed?

Weren't third-party clients forbidden recently? I don't use Twitter though

Musk fucking things up 🤷

You mean centralized platforms fucking things up

It's technically not a third party client

Musk is just helping a bit here :)

^^ so this really dont work anymore?

They just disabled the API, or are going to shortly

They probably forgot that tweetdeck is their own product lol

Hehehe I would not be surprised

fun

moparisthebest: twitterdeck

https://burtrum.org/up/667c1917-e355-41b1-9b11-fdcbac2eed23/zb2rhnN7zgwvaTyp3zdM6HHPh3tCxvwqhDYWKkScYXaW9acw8.jpg

Here have an appropriate meme for this situation

Really, incel memes? :/

What

:D

^^ I'll apply for direct access