jdev - 2020-04-10

  1. Guus

    jonas’ aioxmpp output now part of the Openfire Travis build: https://travis-ci.org/github/igniterealtime/Openfire/jobs/673309693

  2. Guus

    loads of output - would love to get guidance on a) how to run only integration tests, b) how to interpret output

  3. lovetox

    so what is the suggested way of using priority right now

  4. lovetox

    Gajim allows the user to set his own priority if he wants

  5. lovetox

    per default i would use 0

  6. lovetox

    then Gajim adjusts automatically the priority according to show value

  7. lovetox

    means away = 50, dnd = 100

  8. lovetox

    does this still make sense in todays enviorment?

  9. Zash

    Carbons kinda obsoleted priority.

  10. lovetox

    yeah i thought so, but it maybe still can be useful?

  11. lovetox

    so you would suggest always use 0, expect user for some reason override

  12. wurstsalat

    lovetox, for optional priority there is a recommendation as well https://docs.modernxmpp.org/client/design/#deprecated-options

  13. lovetox

    yeah thanks

  14. Holger

    lovetox, either way increasing the prio for away and dnd looks wrong way round, no?

  15. lovetox

    did not look it up in the code

  16. lovetox

    i just wanted to give an example

  17. Holger


  18. Holger

    Anyway I would think the advantage of setting prio depending on status might be interop with old-school (non-carbons) use cases. OTOH the advantage of everyone sticking to prio=0 will usually emulate carbon behavior for incoming messages (if they're sent to the bare JID).

  19. Holger

    The advantage of producing correct English sentences exists does not.

  20. lovetox

    but is that something you would add as opt-in (shwo prio adjustments)

  21. lovetox

    or would it be the default to do tat

  22. lovetox

    or would it be the default to do that

  23. lovetox

    actually you are online with 3 resources, all have prio 0 :D

  24. Holger

    I tried to explain why I'm unsure. Not very helpful I know 🙂 In the end I'd probably stick to prio=0 by default as that's what everyone recommends for modern clients. Probably due to the "emulate carbons" idea.

  25. lovetox

    i guess i keep the feature, but default to prio 0

  26. Holger

    And for normal end-user clients I'd definitely not expose prio knobs to users, but I guess Gajim is still also a power-user client.

  27. Holger

    So yeah "keep feature but default to 0" sounds sensible to me.

  28. jonas’

    Guus, so, the output is roughly like this: ERROR: […] followed by an (often not immediately useful) traceback, followed by a debug log which includes the verbatim bytes sent and received over the XML stream

  29. jonas’

    best to be read from bottom to top, since the top part often contains pre-test negotiation

  30. jonas’

    in the first case, aioxmpp receives <item-not-found/> in response to a disco#info query, which is at least wierd

  31. jonas’

    aioxmpp.e2etest.provision.client14.XMLStream: DEBUG: RECV b'<iq type="error" id=":rnZ16HksNXwLMrtNoyAx" from="1dphv93k5z@example.org" to="1dphv93k5z@example.org/1dphv93k5z"><query xmlns="http://jabber.org/protocol/disco#info"></query><error code="404" type="cancel"><item-not-found xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></iq>'

  32. jonas’

    as to running only e2e tests … that’s a good question, I don’t think that’s supported. I’m also not sure it’s immediately useful, since the normal tests should pass too (and are orders of magnitude faster than the e2etests, so they are often neglegible in runtime). The advantage of running all tests is that if another test fails, it may be an indicator that something is broken in the environment which may cause false-positives in the e2etests

  33. jonas’

    Guus, more detailed discussion we probably better take into some 1:1 chat

  34. jonas’

    but this should already be useful; item-not-found in response to a disco#info without a node is at least weird

  35. Guus

    jonas’ sure - or in open_chat - we're currently doing more aioxmpp ci setup there.

  36. lovetox

    https://xmpp.org/extensions/xep-0100.html#addressing is there something more elaborate

  37. lovetox

    this simply does not work for IRC transports

  38. lovetox

    its very hard for a client to provide some good UI how a user can join a irc channel

  39. lovetox

    what i would want is the server returns a form with fields server and channel

  40. Zash

    Hold on why is an Informational XEP specifying protocol?

  41. lovetox

    user puts it in, and server returns a JID that i can join or add to the roster

  42. Zash

    lovetox, isn't that https://xmpp.org/extensions/xep-0100.html#addressing-iqgateway ?

  43. Zash

    Oh, only one field?

  44. lovetox

    yes exactly

  45. lovetox

    very extendable !!

  46. Zash

    Should at least be fine in single-server-mode, but then you probably don't need more than standard MUC UI

  47. jonas’

    lovetox, tbh, for jabbercat I simply intended to implement the biboumi syntax.

  48. jonas’

    there is no other IRC gateway anyways nowadays

  49. jonas’


  50. Zash

    maybe you and the biboumi folks could conspire to write a XEP?

  51. jonas’

    that’d be good

  52. jonas’

    advertise single vs. multi-server mode, specify the addressing format

  53. lovetox

    i think irc could be really nice integrated into a client

  54. jonas’


  55. jonas’

    only with a good gateway though

  56. jonas’

    (hence, basing on biboumi)

  57. lovetox

    the only thing thats a bit clunky now is joining a channel

  58. lovetox

    normal user has no way of discoverying the syntax, i could of course hardcode it

  59. lovetox

    but meh

  60. Zash

    I guess the Matrix bridge has the same problem

  61. lovetox

    i just wanted to write that

  62. lovetox

    and basically every federated protocol that has groupchat caps

  63. pep.

    lovetox, there are more clunky things than just joining a channel tbh

  64. Zash

    From something like `<feature var="urn:xmpp:gateways:muc-like-using-percent-to-separate-hostname-from-channel"/>` to some dataform-in-disco to something like that XEP-0100 protocol but better.

  65. pep.

    NickServ for one..

  66. pep.

    I wouldn't want to impose that on a user who isn't experienced with IRC

  67. Zash

    How's that managed by biboumi? (So long since I set it up I've forgotten)

  68. pep.

    And then maybe it's a biboumi thing, the persistency stuff. it's nice but it's also confusing. Users leaving channels and not getting why they're still getting messages from the IRC server

  69. Zash


  70. pep.

    "but I'm not joined on any channels on this server anymore!" ("yes.. you are..")

  71. pulkomandy

    ircv3.net standardises sasl to identify with an irc network. But maybe not for creating an account

  72. Zash

    Or you mean some bug where biboumi gets out of sync with your resources?

  73. pep.

    Zash, no yeah notices

  74. pep.

    Or reconnections, I think that also generates noise. While it's good to know, that will confuse people

  75. pep.

    pulkomandy, yeah biboumi is missing sasl support. But not every IRC server supports that either tbh..

  76. pep.

    And I don't know about account creation indeed

  77. pep.

    Also ghosting etc.

  78. pep.

    You can't really escape the NickServ!!

  79. Zash

    Is "NickServ" standardized or discoverable?

  80. Zash

    Could you map it to ad-hoc or something?

  81. pep.

    Implementation detail?

  82. pep.

    I think it's just the most common nick out there? Unsure

  83. pulkomandy

    There has to be an irc server somewhere that goes otherwise, probably...

  84. lovetox

    of course for a full integrated bridge there would be more to do

  85. pep.

    sasl seems to be the way(tm), all implementation "just" need support

  86. Zash

    this is the way

  87. pep.

    Was QuakeNet also using NickServ? I seem to remember something different

  88. pep.

    Or maybe it was just the Ops bots?

  89. pep.

    channel bots etc.

  90. jonas’


  91. pep.

    Which were named Q, L

  92. pep.


  93. pulkomandy

    But if it was me working on this I'd go with ircv3 specs as the things I expect from servers. For other servers maybe have a degraded/failsafe mode?

  94. pep.

    Well here you go

  95. pep.

    pulkomandy, is there a discovery mechanism to know if the sasl you're attempting will work?

  96. pep.

    I guess you negociate sasl anyway

  97. pulkomandy

    They have a "capability negociation" thing in the ircv3 spec. But I didn't read it

  98. pulkomandy

    sasl seems to be listed there

  99. ali

    pulkomandy, > (١٠.٠٤.٢٠٢٠ ١٧:١٤:٤٥) pulkomandy: But if it was me working on this I'd go with ircv3 specs as the things I expect from servers. For other servers maybe have a degraded/failsafe mode?