jdev - 2023-10-29

if someone knows C++ and wants to do some good in the XMPP eco system, check https://codeberg.org/poezio/biboumi/issues/3468

lovetox, could you write some text about that in the disco#info identities registry?

maybe we need some kind of list of little fixes to various clients and servers that can be done by non-experts with the codebase

I’d feel much better about that if it was actually vetted by the standards.

The second change though sounds perfectly sensible, I’m surprised it isn’t done yet.

you can be more than one thing pep. simply as that

and yes its definitly allowed and used

Is it possible to have more than one identity btw? How is it defined to mix identities together? Is it the sum of both, or is it that expectations for one of the two identities are changed? (one would be a modifier for the first) ✏

pep., yes, you can have as many identities as you want.

That doesn't answer my other question

So they're all to be taken separately?

no

you are the sum of your disco info

i see it like adding more detail

What I meant by sum is: You are identity1, so it's possible to issue operations that identity1 would/should support, and you are also identity2, so it's possible to issue operations that identity2 would support, and the two don't mix

And you're saying yes to both here :P

Which to me are somewhat exclusive

yes i think you can say that, every identity stands for its own and for caps that you have

but you get still value out of interpreting the sum of it

What are identites even? Doesn't features advertise what operations you support?

features are only for additional things

In practice I agree that identities may be used to display pretty images

not for one the base standard defines

hm no forget what i said, i think thats incorrect

for biboumi example its a good example to have multiple identities

And features do the rest ✏

its a MUC service, so spec says to have a identity of "conference"

but its also a gateway, so it needs that identity as well

I think with my question I wanted to make it clear wether this was gonna be a thing just for biboumi or a more generic thing for other IRC gateways (that may not have the same interface at all mind)

lovetox, in biboumi though it's not possible to create channels on irc.gateway.org though right? (unless fixed_server is set, but let's put this aside for a moment)

So having it being declared a MUC wouldn't help?

ircserver@irc.gateway.org is the MUC component

hm i have no opinion on that, but it cannot be both

we have to decide

either the domain is the component, or the server jid

Sorry what cannot be both?

and currently its both

Ah, sure maybe

last time people in the MUC came to the conclusion, that the domain should be the MUC service

Well when fixed_server is set, ircserver@gateway doesn't exist anymore

yeah, so makes sense that the domain is the service, because it always exists or?

Well if you use the muc identity to decide whether you can create channels and all, I find it weird to put it on irc.gateway.org when you actually can't (fixed_server not set)

Just like you'd ask for "account.org" to have a MUC identity because "muc.account.org" is a MUC service

They're different jids

yeah but both domains

Does it matter

and thats fine, account.org points in its disco items to muc.account.org

A component could host various components for all we know

Just on a single jid

the real problem which needs to be solved is that ircserver@gateway.org needs to make it clear that it is not a joinable MUC

thats what we try to solve

Yes indeed

To me that's where the muc identity should be. "I'm a component"

thats not possible

Why not?

if you define this JID as the MUC service, then the MUC spec says you MUST add the muc identity

meaning its impossible to know anymore its not a MUC

exactly where we are right now

Maybe that's an issue with 0045 then?

so the idea is, to say its *not* the MUC service

pep., of course its a initial issue with the MUC spec, but nobody else puts muc services on a JID with localpart

*only* biboumi does that

Until the next gateway

so instead of changing the whole world, how about we change just biboumi

yeah sure you can wait another decade, maybe a second gateway shows up

And then I come back to my first question, are disco identities supposed to influence on each other or are they just two separate identities

it does not matter for the biboumi fix, because the main fix is not putting gateway on the domain

its about the ircserver@domain.org jid

and there we dont need multiple identities

i propose a completely new identity for that one

So basically you're "fixing" MUC here, by having a "component" identity which doesn't exist

no, as said above im not of the opinion that the server jid is the component

the component for me is clearly gateway.org

Well I'm reading the issue and you suggest using <identity type='irc-server' name="ircserver" category='component'/> on the ircserver right?

right, but thats not fixing MUC, thats adding a identity which respects the IRC world

I disagree that it is IRC specific here

I mean it shouldn't be

It's just that the MUC service is on ircserver@

but i guess you cant name another gateway where this is the case

> It's just that the MUC service is on ircserver@ you are saying that like its a fact

Well it is?

i dont know, i guess if you are so sure about it, you can name the definition of a MUC service and tell why its not gateway.org

Whatever, do your changes as you like, it seems as usual this is going nowhere

? i asked for your reasoning, as you seem sure about it

im sure many are interested, as for all other people i talked to it, its not a clear cut case

i personally dont care much about the solution, i just want to know that ircserver@gateway.org is *not* a MUC

> When multiple identity elements are provided, the name attributes for each identity element SHOULD have the same value. Is seems that's the only thing I could find regarding multiple entities in 0030 fwiw.. §3.1

It doesn't say what should be expected from them, if/how both should interact

does it describe how multiple features interact with each other?

> This information helps requesting entities to determine the group or "bucket" of services into which the entity is most appropriately placed ^ I guess though judging by how an identity is defined, I'd argue the multiple identities probably shouldn't be related to each other. It's weird though because obviously if multiple identities are defined on an entity there is certainly some kind of relation. Unless.. economy of JIDs? :/

lovetox, reading

I guess features are defined in the specs they come from, and if they need to interact with each other I would also expect that to be defined there and not in 0030

and who defines that a identity of conference needs to be added to a muc service?

I guess for this issue I don't really mind how it's done. The only thing I'd be annoyed about is if in the end we had a pseudo-generic stuff that only applies to biboumi. We might as well have an <identity type='biboumi' category='biboumi' /> :x

lovetox, for muc I guess it's 0045. for type='irc'/category='conference', I don't know

the problem is biboumi violates the first requirement the XEP tries to solve

> Each room is identified as a "room JID" <room@service> (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.

this alone would prompt me to remove the conference identity from the server jid

Yeah I still think this requirement is unfortunate (to use kind words) ✏

why? because in some decades there is a single gateway that has in theory (not practically) a problem with that?

or are you aware of any gateways that were not realized because of this requirement?

Because I think this is an arbitrary constraint and that we could do without

How does it work with other gateways for protocols which also have a username/domain split?

I’m thinking of ActivityPub, Matrix, email, stuff like that.

lovetox, there could be a feature instead of this constraint, or an identity :)

Does it make sense to standardise type='irc-server', rather than type='legacy-service-server' for instance?

"Hey I'm a MUC service" "Hey you can create rooms here" "I'm a room, you can join me"

Atm all MUC rooms/services contain both the identity and the muc feature..

its not necessary pep. even without these features, its by the standard clear whats a room and what not

That's a great way to differenciate them (not)

its room@service by the standard

no need for identity

Yeah and I'm saying this restriction is dumb. I'd rather see an identity or a feature instead so there is no arbitrary jid restriction

i very muc like that its clear that after the @ is the service

As Link Mauve says it may work in the XMPP world but it certainly fails as soon as we bridge to other networks

Even for XMPP, if you have a j2j gateway you end up with the same issues.

Possibly even worse since you can chain those.

Right

Say I don't have control over my dns (sad, but still), and I'm given a single domain, how do I even have components spawning a whole subdomain

Your server doesn't use DNS for components, you can name them whatever you want (obviously only works for local users)

Yeah only locally

I don't know that any new identities are needed or whatever. The main issue is just that biboumi advertises that the server JIDs are joinable MUCs, which obviously they are not, so that just needs to be removed

singpolyma, no they can't just be removed because that's also a way to advertize that you're a muc service

Well if you're a muc service in 0045 you're also technically "just" a domain jid. But this rules out chat@dino.im and possibly many gateway'd addresses as mentioned earlier

pep., dont know what you mean chat@dino.im is perfectly fine with the XEP0045 spec

it's not, because dino.im is an account domain and not a muc service

thats an entirley different topic, and there is no spec that says a domain cannot be both

chat@dino.im is actually the muc service

? thats the support chat of dino

certainly not the mucservice

lovetox, I remember you vehemently arguing that a domain should not be both :P

lovetox, it's both. Prosody's muc component allows the muc service jid to be joined like other rooms ✏

pep., that's not exactly what happens there tho

i think you confuse a few things now

Zash, isn't it?

before the topic was ircservice@mucservice.org vs mucservice.org

lovetox, no I meant, a while back

it's a component that handles a single bare JID, but it's still a bare jid

no, it was always about that, the conversation started with me posting the biboumi issue, and thats exactly whats described there

the barely legal thing that should be a secret is a different case

> singpolyma, no they can't just be removed because that's also a way to advertize that you're a muc service They are not (cannot be) a MUC service so it is impossible for them to advertise that ↺

Isn't one of the problems here that there's no distinct identity/feature for "I am a chat room" vs "I have a list of chat rooms"

singpolyma, pep. is of the opinion that it is the mucservice

Yeah, prosody allows joining bare domain, but this is a spec violation technically

Zash, this yes

lovetox: well, it's not :)

singpolyma, it shouldn't be, but it's not really relevant here :)

Zash: I would ok with it not being a violation but we'd need to edit the xep for that and it barely seems worth it for such an edge case

And yes, irc.gateway.org isn't the MUC service, it's solely an interface to the gateway ✏

The only practical requirement for a MUC room or MUC service should be lack of resoure part.

singpolyma, "such an edge case" comes up a bit too often in the discussions imo

I don't remeber if having no MUC service is allowed, I don't think it technically is

Zash, I'm of the opinion that the only requirement should be a disco feature :P

To prepare for when we finally get rid of resources in MUC

pep., that's called MIX

nah

MIX is a different set of problems

You can maybe say that IRC.example.com isn't a MUC service. But you *can't* say that blah@irc.example.com *is*.

I don't see MUC without resources, I see MUC without nicknames encoded in resources

Zash, hmm, maybe. I'd hear you out :)

singpolyma, only because of this weird requirement of 0045?

pep., whereby we just swap places of occupant-id and nickname

That's really the only thing that's missing

Because of the definition of a MUC service, which is found in 0045 yes

Ok then I think this argument is dumbfunded and that we just need to change MUC

singpolyma: irc.example.com is a muc service--it just has some entities as well that aren't MUCs :P

Maybe we can change MUC, but until we do its simply the truth

Because really ircserver@gateway is the service.. ✏

Still praying for Someone™ to write that "how to discover a thing in XMPP" XEP

wgreenhouse: that's fine. I don't much care either way if it is or isn't

singpolyma, you underestimate the power of implementers

> Because really ircserver@gateway is the service.. It is factually not ↺

wgreenhouse, hey, that's not untrue ✏

singpolyma: also it sounds like single-instance biboumis remove the ambiguity? if I'm understanding the ambiguity?

I'd be fine to do away with the idea of "MUC service" entirely.

Ok I realize it can be seen this way too. A client doesn't need to know the relation between ircserver@ and #channel%ircserver@

(ones that are locked to one target irc network for the entire component)

multi-component-connection biboumi when? :)

wgreenhouse: they remove the bug in biboumi yes

> Ok I realize it can be seen this way too. A client doesn't need to know the relation between ircserver@ and #channel%ircserver@

halleluja :)

lovetox, that doesn't solve your issue

of course it does

Still I think what is being discussed here is really biboumi-specific and I still don't like it

Zash: similar to what slidge does?

biboumi shoud remove the identity and its fine

> biboumi shoud remove the identity and its fine Yes ↺

wgreenhouse, I don't know what slidge does

Zash: I think it publishes a separate component address for each foreign network the admin has chosen to allow, e.g. signal.example.org etc.

thats what is weird about the discussion, you propose to change the SPEC and the whole ecosystem when the only problem is that one irc service provider out there adds a illegal identity

Actually, I may still hold onto ircserver@gateway is the component, because otherwise you can't have a client create rooms from the domain jid

wgreenhouse, but does a single process handle all of them?

Because it lacks the info on what IRC server the room is to be created

Zash: not sure

s/component/service

and could it do that over a single connection? (no protocol for this I think)

pep., thats a solved problem, read XEP-0100

the gateway service can communicate the way an adress is build

Zash: component new xep. But no one implemented that yet

and thus the client can offer a user interface to the user

the client does not need to know what a IRC server is

or how the IRC network is build

lovetox, do you have an example somewhere for this?

singpolyma, 225? yeah nobody asked for it and there are no implementations afaik

Zash, I've been asking for it multiple times already :x

But 1 person probably isn't enough to care ✏

Zash: I keep meaning to, it would be very nice, but keep having other stuff to do heh

lovetox, isn't 100 for user login rather?

I see "user login" and "contact handling"

pep., must have been so long ago I don't remember it then.

It's been mentioned twice in my current logs.

https://xmpp.org/extensions/xep-0100.html#addressing

I want 225 for tls but also for the multiple domain delegation

pep.: the jabber:iq:gateway section

would be even better if this would allow a dataform, but a description field that tells the user to input #channel@irc.server.org

is fine enough

That's not defined for IRC? (gateway/irc)

The gateway can send an arbitrary form there then?

no, you the client offer the user a filed, and display the "desc" content

after the user puts in his legacy address

Ok so that's not enough for biboumi right?

You need to know the channel and the irc server

> would be even better if this would allow a dataform, but a description field that tells the user to input #channel@irc.server.org ↑ ↺

the legacy adress yes

Or the user, even

lovetox, alright

Biboumi implements this?

Nope

Great

no idea, i just show you this, to tell you that a xmpp client does not need to know about legacy network infrastructure

it provides a legacy address to the gateway, and the gateway sends me the legacy jid

maybe i should elaborate on the main problem with the identity

So what's the part about adding a @category='component' in the issue

the problem is not that user try to join the irc server

> would be even better if this would allow a dataform, but a description field that tells the user to input #channel@irc.server.org You _could_ take some inspiration from XEP-0077 and shove a dataform in there, or even invent a new XEP that's actually standards track instead of Informational :) ↺

biboumi offers a adhoc command interface on ircserver@gateway.org

users need to access this

but everytime they do in gajim, gajim tells them, this is a muc to join

the whole topic is a very very small annoyance in the grand scheme of things

nothing, absolutly nothing would break if biboumi simply removes the identity

Isn't "informational" our own way to say "the implementation was there already"? and standards track "this is designed by committee"

What's the tiping point between the two states even. When does one decide the implementation has been there long enough so that it's now informational :P

And not ready for standards track

pep. [14:08]: > Isn't "informational" our own way to say "the implementation was there already"? and standards track "this is designed by committee" That's 'historical'. 'Informational' is meant for specs that don't describe a protocol, but perhaps best practices, etc.

Historical was mainly used to document things that were implemented before the XEP process

MattJ, what's the difference between a protocol and best practices really, when it's as detailed as 0100

*XMPP Vision & Strategic Workshop* Join the upcoming XMPP #Vision & Strategic #Workshop to discuss and understand our #community better, but also ask for your input on different topics around our federated network and #technology. Date: Tue, 14th November 2023 Time: 6:00 - 9:00 pm UTC Online & in English Everyone welcome - spread the word! https://fosstodon.org/@xmpp/111319439579383047

It would make sense for a MUC not to reflect a self-ping to the device pinging right?

Be it for 410 or not

define 'reflect' ?

1. resource1 pings participant1, 2. muc forwards ping to participant1's devices, 3. resource1 replies to ping, 4. muc replies to ping.

That's the usual flow right?

In 2., muc can certainly skip resource1

And if that's the only device joined, reply directly

(assuming resource1 is joined as participant1, obviously)

the sensible thing today would be to do 410 and respond to the ping immediately

hah, also I read in 410 that the "2." I wrote isn't correct, the iq is forwarded to "any one" of participant1's device.. I had forgotten this "detail"

_one_ yes

no plural

tho it'd be some kind of interesting to send out multiple pings and merge the responses...

in the "hey we have promise.all(), wouldn't it be fun if" kind of way

Ok so all of this is moot in the context of 410. I had forgotten about it