XSF Discussion - 2023-05-16

Is it too late to add a urn:xmpp:blocking#muc that says "Can also be applied to MUC occupants by adding an @occupant containing an occupant-id to <item/>"? It's stable.

Is the intent that the user's server would track occupants in remote MUCs, or how would it work?

hmm. Maybe this should be stored on the MUC rather ✏

Different spec then? With a protocol somewhat similar to blocking?

Block command to the room?

Yeah

isnt that already there? or is conversations misusing the feature?

It's probably an implementation detail of servers that make this work

"work"

Blocking a nick isn't the same as blocking an occupant-id

ah right. occupant-id is only on the server?

It tracks JIDs in a room (pseudonymous, still)

right

Whereas just using nicks can lead to blocking someone that has nothing to do with the original person that was blocked

i wonder how you would do this on mix /thinking

need to read more of the docs ^^'

Would it make sense to reuse the 191 NS, or is it forever taken for the 1:1 case?

Probably a question for the current council members, as they would be the ones who would need to approve it

Big picture I would probably prefer if we find a way to put the occupant-id into the resource for everything that's coming from a muc (presence + messages). Then you can continue using regular blocking command

(not wearing a council hat)

Putting unstable Nicks into the resource was a mistake that needs fixing

Indeed, MIX changes that

PR is open for June release: https://github.com/xsf/xmpp.org/pull/1273 ✏

MattJ, it doesn't, does it? (humor I did not sense?)

Daniel, I think making the resource meaningful here is a mistake fwiw

whether for nicks or occupant-id

pep., it does. In MIX, the sending resource is the paricipant ID

Ah ok. Yeah it's still an issue to me but it's better than MUC ok

I think I'm the last person who really likes the design of MUC 😅

Can we not redo MUC/MIX after my question please :)

The nice thing about MUC's (currently implemented) approach is that it ensures participant names are unique. Back then it was considered a very desirable (if not essential) feature, to prevent nick spoofing.

Although people now find it weird that you can't have two people with the same name in a chat, you also see "modern" platforms struggle with the "unique name" vs "display name" thing

Except for using resourceprep, which is unsuitable for such things ;)

Discord's recent user renaming being an example of that

Of course we don't necessarily need this enforcement at the protocol level, and it may be better as a server feature, that could be toggled on/off depending on the deployment's requirements

There's nothing stopping us from switching to participant ids in MUC resources and using <nick> for display purposes, we'd just have to agree to do it

Though there are privacy implications to having durable participant IDs so it probably shouldn't become mandatory... I guess the durable part is optional even if the IDs become mandatory

Yeah I'd prefer using <nick> too

pep., so what's the plan to prevent impersonation?

Reservation?

Have the MUC do it?

Not sure I get the question

So the server enforces uniqueness of <nick> per occupant?

And enforces Nick only used by owning jid when reservation is present, as now

As it's currently ~done, that is with the mess that is MSN etc.

That doesn't change much, apart from MUC-PMs, which maybe we can rethink.. or retire, dunno :/

Even though MUC-PMs would also be best to occupant-ids / some kind of participant id anyway

We have basically the opposite problem with pubsub where nodes don't have JIDs at all. Trade offs everywhere

singpolyma, do you have an example use-case where participant IDs aren't needed? Or rather harmful?

pep.: Right now a user can leave the MUC and come back moments later and no one (outside of admin of course) can know it's the same person, especially if they change nick

With durable participant id that becomes not possible

Don't get me wrong, I get that usually this is a misfeature. I'm honesty pro non anon for most rooms. But there are definitely cases where people like the privacy properties of semi anon

Yeah, this is actually someting occupant-id "solves". I never know where to stand regarding privacy here.

This is often a misfeature indeed

is occupant-id specific to muc?

I personally prefer anon rooms and this helps

MSavoritias (fae,ve): yes

MSavoritias (fae,ve), yeah

I mean, it's up to the MUC, but that's the idea

They make the semi in semi anon much more

I'd even go as far as saying I'd like JIDs to disappear from MUC altogether, not even exposed to admins

Because they don't need it

JIDs can stay in the operator realm

i am interested in paving the way towards burner jids in groupchats too

like fully anon

MSavoritias (fae,ve), yeah that's an option I have on my list to study

yeah. of course it brings up questions of how do we handle abuse

And that would probably work ok with occupant-id, as changing the JID would renew the ID

MSavoritias (fae,ve): yes, that's my favourite point in the design space. Use non Anon and if people want/need they use burner jid for full Anon participation

so two seperate group chat types? on top of the non anon already?

sounds like too many

> yeah. of course it brings up questions of how do we handle abuse The trolls are pretty capable of making new JIDs whenever blocked already, so I'm not sure burners changes much ↺

true. better to make moderation better

> yeah. of course it brings up questions of how do we handle abuse The trolls are pretty capable of making new JIDs whenever blocked already, so I'm not sure burners changes much ↺

> I'd even go as far as saying I'd like JIDs to disappear from MUC altogether, not even exposed to admins That's definitely unpleasant in lots of cases, because when people open a chat to someone they have in their roster, they expect it to be the same chat, regardless of whether it's from a MUC or the roster.

MSavoritias (fae,ve): define 'better' what do you think we're missing?

Kev, that depends on "people"

I didn't say all people, but I know from non-trivial amounts of experience that there are people who do.

I know some who actually like the distinction 1:1/MUC-PM and.. :/

Kev: right, for sure, I'd never show my family a semi anon room. It's a unique feature to XMPP that's quite unfamiliar

> I know some who actually like the distinction 1:1/MUC-PM and.. :/ You mean you have users who *want* to have two chats between the same two people, and it's not just because of a lack of threading support? What's their use case?

Anyway there can be a way to negociate giving each other's JIDs

They just don't need to be exposed by default

> I know some who actually like the distinction 1:1/MUC-PM and.. :/ I do. But implemented differently ↺

Kev, different context, different discussions

Temporary rooms with burner jids that self destructed after a bit :)

I'm not one of these people, I don't know

> MSavoritias (fae,ve): define 'better' what do you think we're missing? In group chat context i would like to see more granural permissions implemented. Also a timeout both when a user joins and generally. Also a way to restrict what each user can send based on how much they have been in the chat. Also blocking to actually work. That started this whole discussion :P These aae some stuff of the top of my head ↺

Granted a lot of stuff is there just not implemented. Like hats

Or the accept the tos before you join

Dear XMPP folks, I know I have been criticized for my insisting concerns on the XEP Editorial situation (no blame on the folks taking efforts over since then). But I still believe that we still have a general ongoing problem here. I hope this statistic below can show a bit the trend. _Two annotations: Dec & January are joined information that explains for example the big 01 2023 spike. And remind Dep, Def and Obs are not included as they misguide actual activity I believe. Anyway the complete data can be accessed and edited yourself via those files:_

MSavoritias (fae,ve): for timeout you mean "grin permissions over time" kind of thing as an option?

For "what they can send" you mean restricting media or other things?

Blocking to "actually work" is a trade off vs anonymity but I agree there is a slider there

hmm the files got never sent by dino :-( ✏

https://jabbers.one:5281/file_share/2IrQxf3rlCeLVoce3UXZw5My/20230516_150419347_b914..jpg

hehe we go

I can sent the data files later

emus, sorry, but I don't see any problem (apart from the fact that a bunch of updates were batched together)

It is true that I'm not getting through stuff as quickly as I'd like, but I'm not sure what that graph is implied to be saying.

> Kev: > 2023-05-16 03:12 (GMT+02:00) > It is true that I'm not getting through stuff as quickly as I'd like, but I'm not sure what that graph is implied to be saying. Its not about your work or so

27 XEPs were published/updated in the first 4 months of this year, compared with 30 XEPs in the first 4 months of last year

a difference of 3 XEPs over a 4 month period with a graph this spiky, is just noise

emus, I don't think you're criticised (personally) it's more that you appear to be focusing on the thing you find easier to quantify, rather than the real reasons which are much less tangible; i.e. if the 'editor situation' were magically fixed, there wouldn't suddenly be a flurry of activity and new XEPs appearing

It's not clear to me that there's an Editor issue that's stopping e.g. new XEPs being published.

> theTedd: > 2023-05-16 03:14 (GMT+02:00) > emus, I don't think you're criticised (personally) it's more that you appear to be focusing on the thing you find easier to quantify, rather than the real reasons which are much less tangible; i.e. if the 'editor situation' were magically fixed, there wouldn't suddenly be a flurry of activity and new XEPs appearing Sure, but we did before in this time hit a month with 0 activity besides I need to fix the chart in the last two months

emus, there was not 0 activity, there were 0 emails sent out

Possibly 0 merges, but I don't think that was the case

And there have been compliants from others too. and its also a bit unclear if we manage to get a basic automated setup at some spot?

You just posted a graph that shows there has been no substantial change

Whether stuff is sufficiently automated is up to the people doing editor work

I'm not sure what more there is to discuss

there are countless reasons why people are otherwise busy or distracted, and it changes wildly over time; editing harder won't change that

I'm sure if there's a queue of people who're wanting to do Editor work that I'm not knowingly turning them away.

Kev: Its a general concern. I see that you jumped in and now trying to get it right. but I think thats not where we want to be with our core business, right? I should be fully backed in the organisation rather having more people or automation serving this? Besides jonas listed a lot of concerns to be adressed back in September, but I am not sure if we are out of risk that this cannot happen again, right?

(And if someone would like to take on the role entirely, I'd very much not be sad about not having that pressure)

> Kev: > 2023-05-16 03:25 (GMT+02:00) > (And if someone would like to take on the role entirely, I'd very much not be sad about not having that pressure) yes, this ^ for example

A reminder that our current application period ends soon, in case you need to reapply: https://wiki.xmpp.org/web/Membership_Applications_Q2_2023

Kev: I assume this is rather at the lower end of our resources. we shouldnt act there

Thanks alex

Re: Automation, moparisthebest (Please let me not have misremembered) wrote a triage checker for individual PRs. I have written on top of that a checker for the PR queue as a whole that works through each in turn running the script and telling me what to do - it doesn't get things 100% right (largely because of noisy data), so I don't think integrating it into the pipeline is right at the moment, but it's already being a significant help. I've also written scripts that wrap the PR queue script to manage the whole of a XEP Editor session, from PR checking through to sending mails (with the script I suspect Jonas originally wrote), uploading and deploying new images/containers. So things aren't perfect, but they're significantly better (in my view) than when Jonas retired.

But shouldnt we then try to get them into the pipeline and call for an "official" Editor (unless you & peter want to continue) to leave the "emergency staffing" (as I understood)

> theTedd: > 2023-05-16 03:14 (GMT+02:00) > rather than the real reasons which are much less tangible but what are the real reasons? sure I just pulled the data and see whats in there

> there are countless reasons why people are otherwise busy or distracted, and it changes wildly over time; editing harder won't change that

> MSavoritias (fae,ve): for timeout you mean "grin permissions over time" kind of thing as an option? Yeah. So a mod can "pause" a person from sending some specific type of thing and a person cant flood a roomwith stuff when they join. Instead you have a rule saying messages after 2 hours, images after 3 days and so on. ↺

Also for granular permission i meant that its only mod and no mod. But a more granural thing. So hats basically. But deployed.

eXtended Moderation Permissions Policy

but instead of trying to keep the status quo, shouldn't we aim to improve the situation even more? so that for example the backlog of PRs (40 atm) would get smaller over time?

Are those 40 PRs requiring editor attention?

Group by "needs $who" ?

are people other than the editor actually maintaining the PR list? ✏

Or make the tooling/architecture simpler and documented

Which from what i get is already a goal kind of

Editor Tooling Sprint!

XEP process sprint 😁

> XEP process sprint 😁 that, too. the oldest PR dates back to 2017, and there are several other old/abandoned PRs

> MSavoritias (fae,ve): > 2023-05-16 03:55 (GMT+02:00) > XEP process sprint 😁 actually why not

I said xep process because there were some ideas floating around to improve the xep submission process itself

One of them being not having to vote for experimental xeps and making tbe council gatekeepers in the process

Which i would be very much in favor

>> XEP process sprint 😁 > that, too. the oldest PR dates back to 2017, and there are several other old/abandoned PRs Yep. Good point ↺

sprints should be limited in scope, just to maintain focus

Well i see them connected. 🤷

there's no reason both couldn't be done, I just meant it's best not to try to do too much under one umbrella

XEPs should have some basic 'quality checks' but there's no reason that must necessarily be done by Counicl

*Council (but then who?)

Kev: I tried to clean up the noisy data here, can we get that merged? It's never going to pass CI https://github.com/xsf/xeps/pull/1265

(because ci requires things we don't wanna do there)

> XEPs should have some basic 'quality checks' but there's no reason that must necessarily be done by Counicl For experimental? Sure. But those are already done. Council doesnt need to intervene there ↺

With the github ci that is

> (because ci requires things we don't wanna do there) Could you leave that motivation on the PR so I'll see it next time I do a pass, please?

I'll remove 'needs changes' so I'll hopefully look at it again.

Kev: when I say "we don't want to do" I'm wildly assuming you don't want to actually release new versions for each of those just to add missing but implied data :D sure I'll write it down

Sure, that argument's compelling.

And thanks.

> Openfire has a very old plugin for Asterisk integration, but I'm not exactly sure if a) it's still functional and b) what exacty its features are. We could have a look at reviving it, if you're interested. The big problem with asterisk xmpp if I remember correctly is that it requires you have someone's jid/password which is obviously silly.

jjrh: how do you mean? We use the asterisk xmpp stuff

Last I looked you had to configure every account you want to support.

Like with gateways/transports?

So if you want to do something like map sipsimple to xmpp you need that extensions jid and password. When what you really want is asterisk acting as a component server.

I don't think jingle works at all for asterisk anymore at least not in a useful way.

jjrh: https://sip.cheogram.com/ ?

Oh neat. Are you trying to get that merged upstream?

That's a singpolyma question

You forked asterisk and wrote a module or are you just translating sip to jingle?

Asterisk does all the heavy lifting for sip to jingle

I wrote a wrapper to do things like JMI

and better JIDs, etc

So it's just using mod_jingle in asterisk?

There is a minor asterisk fork needed for DTLS also. We're not actively trying to merge it upstream due to the CLA

it's not called mod_jingle, but whatever the jingle module is called yeah, I forget the name

Cool, I'll have to take a closer look

Wow okay I didn't realize res_xmpp could act as a component!