jdev - 2020-01-17

Can someone enlighten me in respect to disco, please? I hacked together a component. My client, Gajim, does not perform a disco "get" to that component, when connected. It does so, however, with other components, such as Biboumi or Cheogram. I assume, I'm missing something in the protocol, so that my component is considered worthwhile by Gajim to perform a "get". But what would that be?

debacle, how does gajim learn about your component?

jonas’ I added it to the roster with JID = mycomponent.myserver.com.

fun

no idea then

In Gajim it appears under "Transports" then, which seems to be correct.

Gajim is almost certainly doing what most clients do, and starting with a disco#items on your server's JID, and then walking those.

I don't know, but that's the usual thing to do.

So if your component isn't listed in your server's disco#items, that might be an explanation.

Kev, I am not on that server, though.

Gajim asks my own server, but not that remote component.

To make things more fun: remote server name == remote component name.

But that is the same with Cheogram, which is also on a remote server and (if I'm not mistaken) has server name == component name.

I guess things to look for then are subscription state, and whether either of the other transports is using caps.

I always wondered about the mechanism which makes (external) components appear in the disco#items response. Is that documented/specified somewhere?

flow, in your server’s docs

I'd expect there to be a generic implementation-independent mechanism

It's entirely down to your server. I keep getting tempted for M-Link to make it able to list arbitrary entries in its disco#items (so if there are common remote MUC services, it could list those for discoverability, for example).

which is maybe coupled to the external components protocol

flow, there isn’t

Kev, prosody has that, fwiw

it’s useful because my HTTP upload service lives on a different domain which would typically not be associated with the user domains

is there none because we do not need one, or nobody bothered to write something down?

we don’t need one

(IMO)

server config is fine

I think debacle just demonstrated that one mechanism would be nice to have

users/admin expect that their extenral component appears in clients once they configured it, not that an additional configuration step being required to do so

flow, I don’t think he did

flow, there would still be configuration required in any but the most trivial cases

well, he wrote a component, was obviously be able to connect it with his server, but wondered why gajim did not discover it. AFAIKT the answer gajim did not discover it, is because it is not in the disco#items response

flow, you’d have to tell the component or the server for which domains to allow/attempt additions to disco#items

jonas’, I don't think so

how’s biboumi knowing which domains to add itself to disco#items wise?

I do not know biboumi, but the trival case is that component.example.org is added as item

to which domains?

my prosody has about five

plus about seven more component domains

well, per default probably to all vhosts of the server

is that a server-side default or a component-side default?

I don't argue that there are cases where manual configuration may be needed, but there could be sensible defaults

probably server-side default

prosody already adds components which share the same domain suffix to a vhost

I think that if Flow is proposing a line in XEP-0114 that says "You probably want to add this to your disco#items too" (if there isn't one - I've not looked), then it seems sensible enough to me.

Kev, indeed

but it seemed more like a protocol suggestion to me

It wasn't clear to me, I'm skimming in and out. But I think that line would be sensible (if not present already), whether it was Flow's suggestion or not :)

Kev, I am actually also propose a standardized protocol allowing components to add themselves to the disco#items of the server

agreed, though I’d probably suggest to limit it to vhosts which are a suffix of the components domain name

you wouldn’t want your various domain-specific MUC services to appear on all domains for example

but that is outside of the scope of xep114 obviously

and a hint about a typical action you want to perform when using a xep sure is sensible

however that action has to be performed (manual changes to the server configuration, automatically via stanardized protocol)

Would it be "allowing components to add " in that case, or "allowing authorised entities to add "?

e.g. the admin, by editing a config file

Kev, good question, probably "allowing authorised entities"

I suspect this is one of those nice things whose value isn't great enough to be worth the effort, but I might just be being unimaginative.

(We seem to have lasted this long with the current behaviour, although making that behaviour documented if it's not seems sensible to me)

> jonas’> agreed, though I’d probably suggest to limit it to vhosts which are a suffix of the components domain name how about "add only under the one vhosts if the suffix matches, otherwise add to all vhosts"? :)

Admin ad-hoc command for adding disco items?

Kev, caps is a difference, indeed. Gajim sends disco get to the components with caps in the presence (or whatever it was), my component does not.

debacle, I am curious: why did you subscribe to your components presence in the first place?

flow I'm not sure why I did :-) I wanted to see the component, because it is not only a transport, but also offers an adhoc command.

I believe, that the component also appears in Gajim under Transports, if I do not subsribe, but send/receive something over that transport. ✏