XSF Discussion - 2022-11-13


  1. emus

    Reminder Matt has made this tool: https://matthewwild.co.uk/projects/xep0392-web/

  2. mjk

    👍️

  3. mjk

    hmm. "green" produces 🟩 "blue" produces 🟦 "red" produces... 🟦

  4. emus

    MattJ

  5. mjk

    emus: I'm kidding, it's not a bug :)

  6. emus

    Ok, I don't get it 😀

  7. singpolyma

    mjk: if red made 🔴 I would have been beyond shocked

  8. mjk

    but regular reminder to add a <noscript> notice somewhere :3

  9. mjk

    singpolyma: sha2 was backdoo🟥 all along!!1

  10. edhelas

    https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/okLQs3nuZrjy/image.png

  11. edhelas

    Bringing banner images to XMPP profiles on Movim, it's a first experiment

  12. edhelas

    It's XEP-0084: User Avatar with a URL in the metadata and on another node, that's it

  13. singpolyma

    edhelas: how do you mean? A url in the avatar metadata pointing at another node?

  14. edhelas

    No, another metadata node

  15. singpolyma

    Oh I see, same as avatar but just different node name

  16. edhelas

    Yes, I am using some movim specific node for now, but I'll try to write a XEP

  17. edhelas

    It will be quite simple, same as 0084 but with a landscape/wide picture, prefered URL (because the picture can be quite large) and save the metadata on something like urn:xmpp:banner:metadata

  18. edhelas

    The rest is the same, and thanks to PEP magic it will be pushed on all the clients

  19. singpolyma

    Oh, so metadata node only because you expect it to be too large for base64?

  20. edhelas

    Yeah, I'm already doing that in Movim

  21. edhelas

    Movim can host pictures, so it's not a problem

  22. edhelas

    And 0084 support that

  23. singpolyma

    Are they really so big in practise? I guess we can do up to 128kb in base64

  24. edhelas

    Depends :p But it gives a bit more flexibility on my side, and I'm not blocking the socket

  25. singpolyma

    If it's to be URI based probably want to have multiple URI options and/or hashes, like sims has. (I'm just thinking out loud, don't think I'm not excited to see this!)

  26. edhelas

    Yeah, it's just a first experiment on Movim, I'll try to write a XEP when I'll have a bit of time and see what are the feedbacks :)

  27. edhelas

    But I think that having banners in XMPP clients can be kinda cool, brings some customization to the user profiles

  28. singpolyma

    Cool. I could see implementing this but I'll have to think about privacy stuff for the http URI case

  29. edhelas

    Sure

  30. singpolyma

    Can it work for MUC? I think MUC avatars aren't using pep avatar yet are they?

  31. edhelas

    Nope, but maybe it's time to have PEP for MUC :D

  32. edhelas

    I'd be happy to have PEP for XMPP services/components as well, then I can have vcards and avatars for them :3

  33. singpolyma

    Yeah, I do that for some of my components

  34. edhelas

    So basically you will receive a presence from muc.xmpp.org, also useful to know if the component has gone offline

  35. larma

    PEP/PubSub for MUC would be awesome. We could also use it to store user avatars of MUC members so they can be fetched even if the user went offline (which doesn't work right now because we're using the undefined IQ over MUC) and also have less privacy issues (can have different avatars for different MUCs)

  36. singpolyma

    larma: that doesn't sound related to pep on MUC per se. MUC service could cache user avatars already

  37. larma

    well not really

  38. larma

    because how would you even request the avatar for a specific user, if someone else can just join under their nickname

  39. Zash

    Only do it for users with reserved nicknames?

  40. singpolyma

    Right, you need reserved names for the concept to make sense

  41. larma

    we have occupant ids

  42. larma

    works even across nickname changes

  43. larma

    and also reserved nicknames aren't that popular in public MUCs, so would be weird to have avatars only work with them

  44. Zash

    true. so some occupant-id keyed cache for stuff then? I'd probably wanna reserve longer term persistence for affiliated users

  45. moparisthebest

    I think most public MUCs kind of assume reserved nicknames

  46. moparisthebest

    If someone were to come through "stealing" regular user's names I suspect it'd get popular real fast...

  47. Zash

    ´/kick moparisthebest /nick moparisthebest´ DISREGARD THAT

  48. singpolyma

    How most servers do reservation? For "members"?

  49. Zash

    How how? In Prosody it's stored among extra data attached to an affiliation.

  50. singpolyma

    I mean how would a MUC admin reserve a nickname. Is setting member affiliation enough or is something else needed?

  51. Zash

    Per XEP-0045 you can specify a nick when configuring affiliation.

  52. singpolyma

    Ah ok, so client needs special support for it

  53. singpolyma

    Reasonable, just more stuff to implement :)

  54. Zash

    Or a bug that makes it include nick instead of jid, in combination with some compatibility behavior for clients doing just that... and tada! everyone has their nicknames reserved!

  55. Zash

    https://xmpp.org/extensions/xep-0045.html#grantmember