jdev - 2023-02-15

  1. nicoco

    is it useful for a muc service to include `<c ...>` (XEP-0115 (caps)) in participants presences? in other words, do clients care about participants disco features in MUCs?

  2. Zash

    Sometimes, e.g Swift used to warn if not everyone supported message corrections

  3. nicoco

    I see. I wonder if it's worth the extra complexity (OK it's not *that* complex in theory) and the extra bytes in the presence stanzas for me to add that. One good reason to add it though, is that in my MUCs, all participants are going to have the exact same disco features, so for clients that are interested in participants disco features, it sure would reduce traffic by a lot.

  4. pep.

    No client other than https://migrate.modernxmpp.org/ supports Moved (0283) atm right?

  5. MattJ

    Actually I think even that one doesn't 🤭

  6. pep.


  7. MattJ

    On the to-do list

  8. MattJ

    But as that client was written for a server that was shutting down imminently, Moved wasn't a priority

  9. pep.

    Technically it doesn't even do 0277, since there's nothing for a client to do atm :x

  10. MattJ


  11. MattJ

    It does do that, since it lets you download as a 227 XML file

  12. pep.

    Yeah 227

  13. MattJ

    But yes, 227 is not a protocol, but a data format

  14. pep.

    Ah ok, right, after getting vcard and roster the usual way

  15. pep.

    How does one go with a 227 file? Asks their new operator to import it manually?

  16. pep.

    How does one go with a 227 file? They ask their new operator to import it manually?

  17. MattJ

    Snikket allows importing a file as part of account creation (in the web UI)

  18. pep.

    Only for stuff that's replayable by a client right? As discussed in prosody@ the other day

  19. MattJ

    Would be nice to add that to migrate.modernxmpp.org too

  20. pep.

    (That is, not MAM, and maybe not PEP entirely)

  21. pep.

    Ah in the Web UI

  22. MattJ

    Yeah, the web migrator actually doesn't export MAM either currently (somewhat intentionally)

  23. pep.

    Snikket's web ui has server access so it's easier there

  24. pep.

    But yeah basically one needs to ask their operator

  25. MattJ

    Either the history is OMEMO-encrypted, in which case it is usually useless, or it's unencrypted and then I didn't want the liability of having chat history in plain text XML files

  26. MattJ

    Some people might be fine with that (even desire it), but most people probably wouldn't realize

  27. MattJ

    and then they might send it to some operator via email for import

  28. MattJ

    It's not even clear that MAM can be truly imported on JID change. It would require some hacking, and I know it wouldn't be compatible with some Prosody storage backends

  29. MattJ

    if you wanted to preserve ids, that is

  30. MattJ

    If you don't preserve ids, you'd potentially have other problems on your hands :)

  31. MattJ

    So yeah, I decided migration of MAM wasn't worth it to most people

  32. pep.

    Maybe there should be a note left in the spec? :/

  33. MattJ

    Yes, possibly

  34. MattJ

    about the id thing, for example

  35. pep.

    Re OMEMO, yeah most of the archived wouldn't be readable, expect maybe for the last few that haven't been decrypted yet

  36. pep.

    But then, would a client reuse keys from a different account..

  37. pep.

    Ok so no client implement 0283 so far?

  38. pep.

    And no client other than migrate.modernxmpp.org implements importing 227

  39. jonas’

    snikket web portal

  40. pep.


  41. jonas’

    kind of :-)

  42. pep.

    (It's been mentioned above)

  43. jonas’

    it is technically a client, albeit using REST for XMPP instead of an XML stream

  44. pep.

    Ok I thought it had access to server API somewhat directly (maybe with some auth token)

  45. jonas’

    no it doesn't

  46. jonas’

    we decided against that

  47. jonas’

    upon login (or registration) it obtains an auth token for your user and stores that in a cookie

  48. jonas’

    and it uses that to do things as your user, so basically it is an XMPP client

  49. pep.

    Go tell that to the Matrix People, you're using HTTP+JSON :P

  50. pep.

    Here, we can boot Matrix already

  51. jonas’

    no, it's HTTP+XML, mostly

  52. pep.


  53. jonas’

    like in the 00s, but dirtier ("without soap")

  54. jonas’

    https://github.com/snikket-im/snikket-web-portal/blob/master/snikket_web/xmpputil.py if you want to see all the glory of the XML stanza composition, or https://github.com/snikket-im/snikket-web-portal/blob/master/snikket_web/prosodyclient.py#L246 if you're more into the API interaction itself

  55. pep.

    And apart from Snikket and migrate.modernxmpp.org? Anybody else? :x

  56. pep.

    Client DOAPs say no..

  57. Link Mauve

    nicoco, please also include XEP-0390 caps, this isn’t used by most clients yet but will eventually.

  58. MattJ

    pep., none that I'm aware of

  59. pep.

    https://codeberg.org/joinjabber/support/issues/7 I just opened this re account migration

  60. pep.

    And now I can restart my browser.. that was the one tab preventing me to do so (hanging form)

  61. nicoco

    Link Mauve: well, I should make 0390 a slixmpp plugin then. I confess everything disco/caps related in slix is not very intuitive to me yet (it's a bit better than a few months ago though =))

  62. nicoco

    about the infamous room "avatar"s… from https://docs.ejabberd.im/tutorials/muc-vcard/ and https://modules.prosody.im/mod_vcard_muc I gather that vcard-temp (XEP0054) is the way to go. is there a reference document about how the protocol works *for room avatars*?

  63. Zash

    nicoco, what you linked and XEP-0054 is all there is

  64. Link Mauve

    I once wrote a XEP, but it got rejected.

  65. Link Mauve

    nicoco, https://github.com/xsf/xeps/pull/700

  66. Zash

    Oh, right, XEP-0153 too

  67. Zash

    Basically just the same procedure, but with the MUC JID instead of your account.

  68. Link Mauve

    Perhaps I should resubmit it as historical.

  69. jonas’

    Link Mauve, yeah, resubmit it

  70. jonas’

    I think the decision to reject it was among the worst

  71. jonas’

    right next to the XHTML-IM thing

  72. Link Mauve

    I think so too.

  73. nicoco

    OK lemme just shout my questions then :) 1.which entity should advertise support for 'vcard-temp' in their disco features? the muc service (whatevs.example.com)? the room (room@whatevs...)? both? 2.besides replying to iq/get/vcard, how does the room tell the clients 'hey, I have an avatar, you should fetch it because it's nice'? 3.about XEP-0153 `vcard-temp:x:update` when does the muc send a presence from its bare JID? on join, the muc send presences for participants, but for the room (ie, the bare JID) there is no presence to be sent, or is there?

  74. Zash

    And here I've been trying to move to XEP-0084 everywhere, but nope, vcard-temp is eternal and forever

  75. Zash

    nicoco, "yes", best of luck! :)

  76. Link Mauve

    Zash, at least if it was documented that would be less bad imo.

  77. Link Mauve

    Speaking of which, this list decision never happened: I thttps://github.com/xsf/xeps/pull/760

  78. Link Mauve

    The rationale for the rejection was that there are already too many XEPs about avatars. ^^'

  79. nicoco

    so, I'll just try to send ```xml <presence from='room@component'> <x xmlns='vcard-temp:x:update'> <photo>somehad</photo> </x> </presence> ``` along with the presences from participants, on join, is that the correct way to use XEP-0153 in this context!?

  80. nicoco

    it feels weird because AFAIK the room never sends presence with from=the-room-bare-jid, or does it? it feels like I'm missing something here

  81. nicoco


  82. Zash

    nicoco, yes, it's awkward, it even broke some clients that did not expect such presence

  83. Zash

    But users want room avatars!!!

  84. nicoco

    I am a user and can confirm this

  85. pep.

    Poezio still displays room presence in the InfoBuffer just like other users... We should fix that someday

  86. nicoco

    oh ok, it's akward but the way to go then. I'm a bit worried about annoucing support in disco#features because I moved to PEP Avatars for the contacts and hope that clients won't expect vcard-temp for contacts now… I'll do some testing I guess. thanks for the replies

  87. Link Mauve

    jonas’, Zash, nicoco, https://github.com/xsf/xeps/pull/1269

  88. nicoco

    looks less awkward than what I am hacking right now, I'm reacting with a thumbs up