jdev - 2023-04-07

  1. lovetox


  2. lovetox

    the xmpp wiki does not mention xmpps records

  3. Zash

    lovetox, be the change you want to see in the world? ;)

  4. lovetox

    im on it

  5. Zash

    There's https://wiki.xmpp.org/web/Tech_pages/XEP-0368 it could link to

  6. Zash

    From the history, it looks like the SRV Records page hadn't been significantly altered since 2015 when XEP-0368 was published

  7. Zash

    While you're in there, wanna delete https://wiki.xmpp.org/web/SRV_Records#TURN_SRV_records since we use XEP-0215 for that now? (I can do it otherwise, tho later to avoid editing conflicts)

  8. Zash

    Oh, STUN and TURN? All that can go

  9. Zash

    The Securing DNS page seems to have been lost. Anyone got any strong opinions on whether to restore it or drop the link from the main page?

  10. Zash

    Seems it can be recovered at https://web.archive.org/web/20160507033641/http://wiki.xmpp.org/web/Securing_DNS

  11. Zash

    Not sure the XMPP Wiki really needs to have a bunch of BIND documentation, surely there's resources elsewhere for that.

  12. lovetox

    i added a link under external links

  13. lovetox

    and added some examples for xmpps

  14. lovetox

    i dont know what people usualy use as port for servers

  15. lovetox

    i dont know what people usualy use as port for xmpps-server

  16. lovetox

    i did only the bare minimum, Zash you can have a go if you want

  17. Zash

    I've seen 5270 in a few places, like ejabberd config examples

  18. Zash

    Poof, gone!

  19. Zash

    lovetox, https://xmpp.org/rfcs/rfc3920.html#rfc.section.D.1

  20. Squeaky Latex Folf

    Does anyone know whether it's possible to have a different vcard per muc?

  21. Zash

    In theory? Maybe. In practice. Noe.

  22. Zash

    Squeaky Latex Folf, personal vcard?

  23. techmetx11

    Squeaky Latex Folf: it could probably be the MUC's server, like in a semi-anonymous MUC, the MUC server is the one that relays the vcard

  24. MattJ

    If you're trying to separate identities, it's better (for many reasons) to use separate accounts for that

  25. Zash

    Not impossible at the protocol level, in fact, Prosody does it, but only in an all-or-nothing kinda thing.

  26. Zash

    As in, if you restrict your avatar / profile settings to contacts, non-contacts (including MUCs) will either see a limited vcard or an empty vcard.

  27. Squeaky Latex Folf

    Or what about avatars?

  28. Zash

    Separate accounts is far superior of course.

  29. Squeaky Latex Folf

    But having separate accounts just to have different avatars seems overkill for example

  30. Zash

    I don't think XEP-0153 makes sense in that case and it would be kinda complicated.

  31. MattJ

    Having a whole protocol around supporting multiple avatars (why?) seems overkill

  32. Squeaky Latex Folf

    It's cool tho

  33. singpolyma

    Don't really need any new protocol for it, just new code

  34. singpolyma


  35. Squeaky Latex Folf

    Yeah it's already theoretically possible

  36. singpolyma


  37. Zash

    You used the word "just", therefore your statement is invalid. Try again :)

  38. Zash

    If you're just after coolness factor, nothing stops you from implementing something yourself.

  39. singpolyma

    I want to do at least granular vcard permissions eventually. Matter of priorities / making the time to write the module

  40. Zash

    If you're after opsec properties, separate accounts is the way to go.

  41. singpolyma

    Yes, for sure, if it's for persona

  42. Zash

    I for one don't currently feel like finding out what edge cases would pop up

  43. Zash

    MUC doesn't even support avatars actually :)

  44. Zash

    only legacy "temporary" vcards

  45. techmetx11

    just modify the MUC server's software to hijack the vcard-temp

  46. techmetx11

    for a user

  47. Zash

    You mean the users server?

  48. Zash

    MUC just proxies the request

  49. techmetx11

    that's the point

  50. techmetx11

    the MUC proxies the request

  51. Zash

    and you must send a different xep-0153 hash per aaaaaaaaaAAAAAAAAAAAaah

  52. techmetx11

    the MUC can modify the response

  53. techmetx11

    so, you could make vcard per muc a thing

  54. Squeaky Latex Folf

    But how would you publish a vcard per muc?

  55. techmetx11

    Squeaky Latex Folf: since this is a non-standard, that's really up to the MUC sysadmin and client to implement that

  56. singpolyma

    techmetx11: vcard per muc better done at your server than at the MUC server, I should think

  57. techmetx11

    singpolyma: true

  58. singpolyma

    At hoc command to configure

  59. singpolyma

    Ad hoc command to configure

  60. Squeaky Latex Folf

    » [17:02:08] <singpolyma> techmetx11: vcard per muc better done at your server than at the MUC server, I should think Nah it could be done at both ends

  61. Squeaky Latex Folf

    although that's kinda ugly

  62. techmetx11

    Squeaky Latex Folf: yeah, thats ugly

  63. techmetx11 thinks of a vcard property (like <vCard FOR_JID="blahblah@blah.com/blah" ...>)

  64. techmetx11 thinks of a vcard property (like <vCard FOR_JID="blahblah@blah.com" ...>)

  65. techmetx11

    send multiple vcards in one stanza

  66. singpolyma

    Sure, one could define a new custom protocol, but then you need client implemetation too and a xep eventually

  67. singpolyma

    It rather build on what exists first

  68. Zash

    If it were me, I'd do some hacky thing like use the sender JID as PEP item id. Or something.

  69. Kev

    While not arguing for anyone putting the time in, there are non-opsec reasons to do per-community avatars too. Like e.g. having community avatar match the ingame avatar that goes with the game for that community.

  70. Kev

    That’s one that I would definitely use on Discord if I paid for nitro. And one *could* use many accounts to achieve the same thing on XMPP, but it does seem unnecessary.

  71. Zash

    MIX and having some way to attach arbitrary per-user data, instead of wonky IQ proxy things? I'm all for it. Not going to put in the time for that today tho, sorry :)