jdev - 2022-09-20

  1. dpes

    how can we query chat history between two user from react.

  2. Link Mauve

    dpes, are you a client, connected as one of these two users? If so, have a look at XEP-0313, or a library which implements that.

  3. pep.

    So what is is there in the “MUC reliability kit“ apart form.. resyncs? 0410?

  4. pep.

    Ah 0045 says MUCs may also ping participants sometimes to ensure they're still there. So.. it goes both ways? :-°

  5. Ge0rG

    A MUC could probably do that after a while of not forwarding stanzas. Otherwise, whenever I start typing in a large but calm room, I see dozens of users get kicked due to s2s errors from delivering my typing notification ;)

  6. pep.

    Also for 410, I still need to check whether the requestor is joined or would be able to, to answer anything useful. So I actually know if they're joined and I could reply something more useful than <item-not-found/> if they've pinging the wrong nick because another resource changed it

  7. pep.

    But I also don't know if that ping was meant to check if they're still connected because there's nothing to indicate intent..

  8. Link Mauve

    Ge0rG, well, it’d increase resource consumption by a lot for mobile users who are in many MUCs, especially at night.

  9. pep.

    Except 410 gladly overwrites the behaviour of pinging participants (even for non-supporting clients) so it might make sense just to return a prsence from another occupant with a successful pong

  10. Link Mauve

    Is it an issue to see them get kicked on a chatstate?

  11. nicoco_

    I am trying to use xep-0172 (user nicknames) and I can't seem to get it right. the context is that I want "puppet JIDs" for a bridge component to be able to set and update their nicknames. how should this be implemented? should I rely on the xmpp server's pubsub component? or should my bridge component act as a pubsub component itself?

  12. Link Mauve

    nicoco_, the component should.

  13. nicoco_

    thanks Link Mauve. Does that look good like a good "new nickname" stanza https://paste.sr.ht/~nicoco/fa6310b495528200b667522c132a986f6c179ffd ? clients don't seem to receive anything. I'm having trouble understading the PEP basics

  14. nicoco_

    I basically just used slixmpp's `xmpp.plugin["xep_0172"].publish_nick(n, ifrom=some_puppet_jid)` but I am probably missing something, probably trivial, to wrap my head around how this all works.

  15. Link Mauve

    nicoco_, you should remove the @to.

  16. Link Mauve

    Currently it’s the client sending to itself.

  17. Link Mauve

    It should send to its account instead.

  18. Link Mauve

    As that’s where the PEP service “resides”.

  19. Link Mauve

    Ah, but that’s for publishing your own nickname, while you’re actually interested in broadcasting said node’s content to other people.

  20. Link Mauve

    Is your component already handling presence subscription properly?

  21. Link Mauve

    If so, you should be receiving caps in the presence of users subscribed to your fake accounts. You then query their disco#info from the caps node, and if they have the http://jabber.org/protocol/nick+notify feature in there you send them a PubSub event containing your nickname.

  22. nicoco_

    I force push puppet jids item into the xmpp user's roster with "subscription": "both", that should work, shouldn't it?

  23. Link Mauve

    See example 6 of the XEP (without addresses, no one uses that nowadays).

  24. Link Mauve

    nicoco_, if you receive presences from the XMPP user, then yes.

  25. nicoco_

    this works, yes

  26. nicoco_

    so, example 6, but isn't that something that pubsub.localhost is supposed to send? what the bridge component must "forge and send" is Example 5 isn't it?

  27. Link Mauve

    No, it’s the account JID of your fake user which should implement PEP.

  28. Link Mauve

    PEP is basically PubSub on a user’s account.

  29. Link Mauve

    (It originally was a small subset of PubSub, but implementations kept adding stuff until it required basically full PubSub support.)

  30. nicoco_

    hum ok, so prosody's pubsub.localhost never comes into play?

  31. Link Mauve

    No, it doesn’t.

  32. nicoco_

    oh ok I misunderstood your first answer then.

  33. Link Mauve

    My first answer was based on that I thought you wanted to publish the nick, as you originally asked about.

  34. Link Mauve

    I didn’t notice you actually want to be a PubSub implementation.

  35. Link Mauve

    Possibly just for events for now, so that’s quite simple.

  36. nicoco_

    great, it seems to work! https://paste.sr.ht/~nicoco/eb3d02e0abe2e3890cd70ae8cc5ba1abeac312cc → gajim and movim both update the puppet nickname. thanks a lot

  37. Link Mauve


  38. Link Mauve

    You probably want to make it type="headline" though.

  39. nicoco_

    oh OK, good to now

  40. nicoco_

    oh OK, good to know

  41. nicoco_

    is it going to be similar for xep0084 (avatars), again, nothing to do with the prosody's pubsub component?

  42. nicoco_

    is it going to be similar for xep0084 (avatars), again, nothing to do with prosody's pubsub component?

  43. Link Mauve


  44. Link Mauve

    Except you’re going to have to also handle requests for avatar:data, not just notifications to avatar:metadata+notify.

  45. nicoco_

    thanks for the clarification, I was reading the XEP again and it seems like it is going to be substiantially more work than the nickname thing. notably I should make sure to base64 encode a png version of the image if I read it correctly.

  46. nicoco_

    so if I understood correctly, I should send events just like the nickname thing for the avatar hash, and then respond to avatar:data requests with the actual image data

  47. Link Mauve

    nicoco_, correct.

  48. Link Mauve

    Avatar hash, format, width, height, etc.

  49. nicoco_

    thanks for your help Link Mauve! slidge migration from 'vcard-temp' to 'user avatar' is not going to happen tonight I fear, but at least now I understand the basics.

  50. Link Mauve


  51. Link Mauve

    Die vCard-temp, die!