XSF Discussion - 2020-10-04

Should a gateway that offers chatrooms have two identities? `<identity category="gateway" type="othernetwork" />` as well as `<identity category="conference" type="text or something" />` ?

That might confuse clients looking for a MUC service to creates room onto(?)

Also, what's the status of our registry?

pep.: Gajim refuses to join rooms that don't have a conference identity.

Maybe only the room should have a conference identity then?

hmm.

That'd be enough to me

No the server needs to have the identity too

why?

Having multiple identities is valid, albeit confusing sometimes.

That's how we Auto discover muc servers

Daniel: what if you can't create rooms on that service because it's a gateway?

that ^

I Filter that out

How?

you filter what out where?

Based on the gateway identity

So (gateway,$type) + (conference, text|???) would make sense?

Ge0rG, ooi, what gateway are you writing

eta: don't ask

(is it the matrix bridge)

I look for any service that has conference but not category gateway

For the group chat auto create feature

Ok that makes sense

Out of curiosity, what would happen if the base host advertised conference/text?

I mean tbf I don't care if a gateway advertises as conference. That has no benefit

But I catch the case when it does

Because historically a lot of gateways do

indeed also gajim does use conference/text on the component to find the muc server

lovetox: on the component?

the subdomain, or whatever

muc.domain.org

lovetox: btw, Gajim's error message is "Address does not belong to a group chat server", which is misleading given that it queries the room and not the domain

the disco info item that the server returns on a disco item

how do you call it?

lovetox: I was just confused on where you come from. I was trying to "Join Group Chat" by entering a room JID into the dialog

yeah and why is the error message confusing

or with what case could it be confused

lovetox: it implies that you are checking the domain JID and not the room JID. See https://mail.jabber.org/pipermail/standards/2020-October/037784.html for details

ok i forgot that you can run the muc service on a domain that can also host accounts

then this message makes no sense for some servers

lovetox: yup

thanks

lovetox: FYI, it was caused by https://github.com/matrix-org/matrix-bifrost/issues/131

Ge0rG, you write this like its a option

conference/text is a MUST on rooms

its not a "short-term" solution which implies that there is a different "long-term" solution

also i have the same issue open for months

there is no activity on this repo for > 6 months

and this is probably a one liner

lovetox: well it might also be conference/matrix instead of conference/text, right? 😉

no

then its not a MUC

lovetox: you might cross reference the issue then. The Bifröst developers have returned!

a bridge tries to emulate a MUC, then it has to respect every part of 0045

Good point

Talking about MUC, what's up with disco#info results having different names than MUC configuration? :/

It's quite confusing ✏

https://xmpp.org/extensions/xep-0045.html#registrar-discocat

thats the single way a MUC is discovered, everything that does not put conference/text, is by definition not a MUC

Also features being sent alongside a form (that seems to reuse MUC configuration names?), will a server always send one and not the other if it's also declared as a disco feature?

pep.: what, exactly?

lovetox: feel free to comment on standards@, BTW

Zash, for example muc#roomconfig_whois doesn't appear in disco#info, there's muc_nonanonymous and muc_semianonymous

lovetox: if that's the single way, why are you also checking for the MUC namespace feature?

(well not both at the same time)

When querying disco#info, do I have to be ready to parse all variations?

Ge0rG, i looked it up in Gajim code

acutally i check for conference + MUC Feature

which i should change

if i read this correctly

https://xmpp.org/registrar/disco-categories.html#conference

conference/text says its a text conferencing service, which could mean alot

so we should probably always check in addition for the MUC feature

So it's the right thing to check for both, on the room JID?

What will Gajim do if the room is item-not-found?

Any idea how the disco thing in MUC came to be? Somebody first added their feature for their one need and a few others got added bit by bit and then somebody said "fk it let's add all the form"?

Ge0rG, tell the user that the room does not exist?

pep., i dont understand the problem

what is the problem with muc#roomconfig_whois?

its a registered config option

Why is there conference/irc then? Is that not allowed to speak MUC?

lovetox, the problem is that roomconfig_whois never appears in disco#info

it appears as either muc_nonanonymous or muc_semianonymous

Well, I don't know about "never"

pep.: Why is that a problem?

Just confusing

So I have to parse all the possible variations, right?

Isn't the identity meant for users and the feature for clients?

The config option would enable one out of those flags

Zash, yes and when discovering I'm not sure if I'm gonna get the disco feature or if in the disco result I'll have a form with the muc configuration name

(With a value that's anyone or moderators)

pep.: disco features in disco results, config options in the config form.

Ok so why doesn't muc#roomconfig_changesubject have a disco feature as well

Why is that in the form in the disco result

Wait `muc#roomconfig_*` in the disco result? That might be a bug.

Unless the XEP says to do so

In which case it's an inconsistency

I think it does, and I find it confusing

yes

https://xmpp.org/extensions/xep-0045.html#example-10

Ugh

Half disco features half muc#

Well examples aren't normative!!!!!

:/

not helpful

its a bad example i think

pep.: note `muc#roominfo_` vs `muc#roomconfig_`

ouch

it just wants to show that roomconfig can be in disco info

even more inconsistencies

but they choose the one that has a feautre anyway

there others that dont have one

Check the form registration

in this case only check for the roominfo feature

why would the roomconfig feature say something different?

https://xmpp.org/extensions/xep-0045.html#registrar-formtype-roominfo doesn't have any `muc#roomconfig`

Bug in the example?

Zash read the text below example 10

it states that all roomconfig features can be included in the disco info

Uuuuuhu

and roomconfig has their own registry

so why would it in the roominfo registry

I'm not sure this is how field standardization is meant to work

So yeah that confirms I have to be able to parse and disco feature and form configuration and handle duplicates etc. in disco#info results

i agree its not very nice

pep.: at least it's roomconfig vs roominfo

no pep, just parse all roominfo attributes

lovetox, why?

and then the roomconfig features you are interested

and you dont need to handle duplicates

you are not a server stanza debugger

lovetox, not everything is sent as a roomconfig field

as i said, first you parse all "roominfo"

not even roominfo

then only the roomconfig fields you are interested in

<feature var='muc_nonanonymous'/>

It's `muc#roominfo_changesubject` in Prosody :(

Zash, :D

Zash, i think because i opened a issue and was confused :D

Indeed

Tho it didn't advertise that at all before

I feel like there's been a case where there was one of roominfo and roomconfig, which was changed to the other

whats with that feature pep?

of course you need also features parsing

ok lets formulate it different

first parse features, then parse roominfo

that is what you can depend on

roomconfig, in disco info is totally optional

so you dont need to parse it at all and everything should work

lovetox, well that means I can have both muc_nonanonymous and muc#roomconfig_whois to anyone and I need to parse both.

Or have one in a server implementation, the other in another server implementation

no pep.

Not that it's really an issue, just confusing / inconsistencies

the feature is not optional

what do you mean it's not optional

if a muc is nonanonymous

Ok so a server has to use the feature if it exists?

is MUST include <feature var='muc_nonanonymous'/>

server?

i thought we are talking about rooms

MUC service

Or rooms, whatever

server-side

if you query a *room*

we're talking about the same thing

the answer MUST include that feature

k

if it applys to the room

So muc#roominfo is a superset that includes muc#roomconfig :/

so there is no reason in the world why you ever search for roomconfig_whois

pep. i would say Gajim displays every important information of a muc in its muc join dialog

and the only time i check for roomconfig is for muc#roomconfig_roomname

im not sure why that is, but i probably had a reason

its muc#roomconfig_roomname > identity.name -> localpart

for naming a groupchat

lovetox, do you also have the mam config hack btw? :x

Servers didn't agree on a config value apparently

https://github.com/iNPUTmice/Conversations/blob/fa752b596d7fba41a0b62011cd91a11af84b1cd6/src/main/java/eu/siacs/conversations/generator/IqGenerator.java#L527

why is that a hack?

its a custom config option for prosody

and yes Gajim uses that

lovetox we can specify one in the XEP and simply the implementations to follow the standards

I wonder if they've read https://xmpp.org/extensions/xep-0100.html

I wonder if it's relevant

edhelas, yes we can, and it would be easier, but i would not conisder everything thats not in a standard a hack

Just that consistency is good, especially when it's the exact same feature :p

I wanna change it from a boolean to a timedelta of some sort, ie retention period.

with a "max"? :P

Zash: For MUC MAM specifically?

pep.: I guess a range from 'disabled' to a server-wide maximum.

Holger: Well, yes, but probably MAM too at some point..

(FWIW I tried to suggest standardizing a field name but failed.)

Somewhat related to me wanting to turn the 'persistent' boolean into a similar timedelta.

Holger, !! What failed

Zash: I see. Haven't seen demand for such a feature yet. (And would not be keen on implementing it.)

Zash, I guess currently it's a deployment policy anyway

Yeah

GC'd after t time of inactivity or sth

pep.: Room persistence? Yeah, instead of choosing between "room destroyed the moment your phone blips" and "exists forever", the room would be destroyed after n days of emptyness.

pep.: I think people disagreed on whether it needs a separate flag at all (as opposed to overloading the flag for public HTML logging). And those who agreed didn't agree on how to proceed (just add it to 0045 vs. tell 'the registrar' or something).

Maybe I should have another go.

Public HTML logging _is_ subtly different.

I guess that'd be yet another thing for the registrar

And yeah HTML logging is different

Zash: Absolutely.

Altho, if you allow anonymous MAM access without joining, it's very close

Zash: If.

I'd support such a PR ✏

There's something of a scale :)

Zash: 0313 says: > A MUC archive MUST check that the user requesting the archive has the right to enter it at the time of the query and only allow access if so.

Doesn't mean there can't be more checks?

Holger: But does it say that you can't restrict it further?

Maybe that should be made more explicit

Anything not forbidden is allowed! :D

I think limiting MAM access to current participants is a thing one might want.

And also limits based on affiliation, e.g. limit to members/admins or somesuch.

or <payment-required/>

I'd say in public channels I might want to restrict to joined participants :/

Mmmmmmmoar settings

Design guidelines

MAM actually explicitely says "In a members-only chat room, only owners, admins or members can query a room archive." right after that sentence

That's saying the same as "only those who can join has access", right?

"[..] a MUC archive MAY further limit access based on other criteria as part of the deployment policy."