jdev - 2020-01-17

  1. debacle

    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?

  2. jonas’

    debacle, how does gajim learn about your component?

  3. debacle

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

  4. jonas’


  5. jonas’

    no idea then

  6. debacle

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

  7. Kev

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

  8. Kev

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

  9. Kev

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

  10. debacle

    Kev, I am not on that server, though.

  11. debacle

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

  12. debacle

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

  13. debacle

    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.

  14. Kev

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

  15. flow

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

  16. jonas’

    flow, in your server’s docs

  17. flow

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

  18. Kev

    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).

  19. flow

    which is maybe coupled to the external components protocol

  20. jonas’

    flow, there isn’t

  21. jonas’

    Kev, prosody has that, fwiw

  22. jonas’

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

  23. flow

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

  24. jonas’

    we don’t need one

  25. jonas’


  26. jonas’

    server config is fine

  27. flow

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

  28. flow

    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

  29. jonas’

    flow, I don’t think he did

  30. jonas’

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

  31. flow

    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

  32. jonas’

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

  33. flow

    jonas’, I don't think so

  34. jonas’

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

  35. flow

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

  36. jonas’

    to which domains?

  37. jonas’

    my prosody has about five

  38. jonas’

    plus about seven more component domains

  39. flow

    well, per default probably to all vhosts of the server

  40. jonas’

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

  41. flow

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

  42. flow

    probably server-side default

  43. jonas’

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

  44. Kev

    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.

  45. jonas’

    Kev, indeed

  46. jonas’

    but it seemed more like a protocol suggestion to me

  47. Kev

    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 :)

  48. flow

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

  49. jonas’

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

  50. jonas’

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

  51. flow

    but that is outside of the scope of xep114 obviously

  52. flow

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

  53. flow

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

  54. Kev

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

  55. MattJ

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

  56. flow

    Kev, good question, probably "allowing authorised entities"

  57. Kev

    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.

  58. Kev

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

  59. flow

    > 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"? :)

  60. Zash

    Admin ad-hoc command for adding disco items?

  61. debacle

    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.

  62. flow

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

  63. debacle

    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.

  64. debacle

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

  65. debacle

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