jdev - 2023-02-22


  1. nicoco

    according to xep0045, when a muc service receives a stanza from a resource that is not joined, it should reply with error=not-acceptable. is that enough, or should it send a 'kick-like' presence too?

  2. MattJ

    That should be enough

  3. nicoco

    thanks MattJ!

  4. nicoco

    About participants' avatars in non-anonymous MUCs, am I right in understanding that the consensus is: Participants presences should include a `vcard-temp:x:update`, even if the MUC is non anonymous and that client can fetch the avatar via XEP-0084?

  5. nicoco

    About participants' avatars in non-anonymous MUCs, am I right in understanding that the consensus is: Participants presences should include a `vcard-temp:x:update`, even if the MUC is non anonymous and that clients can fetch the avatar via XEP-0084?

  6. Zash

    XEP-0153 is the current thing, XEP-0084 in MUC is ... weird

  7. Zash

    Dunno if it works with anything but Prosody

  8. nicoco

    I thinking XEP-0084 not mediated by the MUC, since I'm talking about non anonymous MUCs

  9. nicoco

    I was thinking about XEP-0084 not mediated by the MUC, since I'm talking about non anonymous MUCs

  10. nicoco

    so technically, client can send the request directly to the known "real" JID of the participant, or maybe they cannot for some reason?

  11. Zash

    Subject to the access model of the pubsub node(s)

  12. Zash

    So, users can choose who can see their avatar and other details

  13. Zash

    While vcard-temp has nothing like that

  14. Zash

    this is (one reason) why I want vcard-temp to go away

  15. nicoco

    indeed. I was happy to ditch it and switch to 0084 for slidge, but I've now reintroduced it to have Room avatars, so I figured, alright, let's do participants too =)

  16. pep.

    You can provide a 0153 interface to 0084 like prosody does

  17. pep.

    If access is restricted then there's no avatar

  18. Zash

    true 🙂

  19. nicoco

    No legacy service I support have the notion of 'channel', basically every group is a modernxmpp 'group'. Some clients seem to be "smart" about non anonymous mucs, they use the avatar they know for the "real" JID (maybe even try to fetch it if the user is not in the roster? not sure about that part). But some seem to expect XEP-0153 and nothing else in MUCs.

  20. techmetx11

    Zash: is vcard4 a good alternative to vcard-temp?

  21. nicoco

    techmetx11: for avatars specifically, xep0084 is the way to go I think. for the rest of the vcard, I don't know, but I know that movim uses vcard4 over xmpp, yes (but not for the avatar)

  22. Zash

    yes

  23. techmetx11

    alright

  24. techmetx11

    i mean i've only implemented vcard-temp because my server only supported that at the moment when i wrote it

  25. MattJ

    The nice thing is that vcard4 doesn't actually require server support, other than PEP

  26. Zash

    It's also a standard developed elsewhere

  27. Zash

    while vcard-temp is our hacky fork of some unfinished vcard3-xml format that went nowhere

  28. nicoco

    hence the "-temp" part I guess?

  29. Zash

    https://xkcd.com/2730/

  30. singpolyma

    Next step beyond permissions: ad hoc command to set different vcard field values or different avatar depending on who is asking ;)

  31. pep.

    Upload the avatar on the MUC?

  32. nicoco

    singpolyma: different avatars per MUC is already possible, right now, isn't it? but no client implement a UI for that =). I thought about that recently because I have a MUC for IRL RPG meetups and I would have been happy to use my very intelligent and beautiful elve as an avatar in this MUC ^^

  33. Zash

    singpolyma, do you by chance remember OneSocialWeb? I think they had a proposal for that.

  34. singpolyma

    nicoco: yes, the protocol allows for it now just need a server module with an ad hoc command to allow setting it up

  35. singpolyma

    Zash: the name rings a bell I think

  36. nicoco

    is there a convention/XEP to encode "pseudo"-case-sensitive JID localparts? I was about to make my own convention for signal groups (since they have case-sensitive IDs...), but maybe I should not reinvent the wheel?

  37. Zash

    NAFAIK, closest is https://xmpp.org/extensions/xep-0106.html

  38. nicoco

    yes, I was looking at that, and this: https://xmpp.org/extensions/xep-0106.html#example-5

  39. Zash

    you could cry and use base32 and hope nobody sees the actual JIDs

  40. singpolyma

    Or use extended jid\20escaping only for capitals

  41. Zash

    singpolyma, that seems to be explicitly forbidden by 106?

  42. nicoco

    Zash: well, right now I use an internal mapping lowercase→CaseSentitive, and JIDs are already pretty damn ugly, eg xmpp:10sshgv8382qwrib%2Blsdoezigzzw%5C2furxzxjnpihag1y%3D@signal.slidge.im?join

  43. nicoco

    singpolyma: I already need XEP-0106 since it's case sensitive AND contains forbidden chars in jid localparts :)

  44. nicoco

    Zash: thanks for the base32 suggestion, I'll have a look :)

  45. Zash

    or if there's some internal ID that makes sense to use

  46. nicoco

    keeping a map is nice but much more annoying than having "stateless conversions" if that makes sense

  47. nicoco

    nice to have good looking JIDs I mean

  48. Zash

    For private chats they're already often just random strings that are sorta hidden from the UI

  49. Zash

    like in Conversations & forks

  50. nicoco

    yes indeed. maybe later™ I'll try to have nicer looking bridged JIDs for mucs/contacts by ugly is very fine, as long as it works.

  51. pep.

    nicoco, something like https://github.com/moby/moby/blob/master/pkg/namesgenerator/names-generator.go ? for the mapping :P

  52. pep.

    If there ever is a mapping

  53. nicoco

    pep. these are fun indeed :) but for context, I have some annoying race conditions on startup where my mapping is not filled yet and it messes things up, and although fixing would be the right thing to do, I'm actually going for "no mapping, stateless conversion" right now because 1.make it work and then 2.make it right =)

  54. Zash

    Mercurial has a thing where uppercase is internally prefixed with `_`, so `README` → `_r_e_a_d_m_e`

  55. qy

    yikes?

  56. Zash

    The things people do for Windows :/

  57. Zash

    or otherwise case insensitive file systems.

  58. nicoco

    problem is, I am not sure about what's allowed in a signal group ID. base32+JID escaping sounds like it might just work for me. base64.b32encode(b"10SSHGv8382QWrib+lSDoezIGZzw/urxZxJNPIhaG1Y=") b'GEYFGU2II53DQMZYGJIVO4TJMIVWYU2EN5SXUSKHLJ5HOL3VOJ4FU6CKJZIES2DBI4YVSPI='

  59. Zash

    As long as it doesn't reach 1023 octets, you should be fine

  60. Zash

    ... hold on, is that base64?

  61. nicoco

    nah, but python's base64 from the std lib actually holds the b32encode func: https://docs.python.org/3.9/library/base64.html#base64.b32encode

  62. Zash

    The input, I mean

  63. nicoco

    oh...

  64. nicoco

    I don't think so

  65. Zash

    It seems to be valid base64 tho, decodes to a 32 bit random looking binary string

  66. Zash

    It seems to be valid base64 tho, decodes to a 32 octet* random looking binary string

  67. nicoco

    be a hacker, find a way to convert that a to signal group invite URL, create a signal account, join my "slidge test" signal group, and then become rich!

  68. selurvedu

    > create a signal account you're in the wrong chat m8 🙃️

  69. nicoco

    wait, do I need to JID escape, or does base32 already output valid localparts for JIDs?

  70. Zash

    base32 encodes arbitrary binary and is case insensitive

  71. nicoco

    selurvedu: of right, it's not sdev@??? ;)

  72. selurvedu

    i mean, there's no way anybody here would do that, amirite :)

  73. nicoco

    it's question day for me! as soon as my MUC service tries to send a message to a client and receives an "error" in reply, it should consider that this client is not "joined" anymore and stop trying to send stuff to it. is that OK or are there other stuff to look for?

  74. pep.

    If the MUC sends them an error they kick them in the process no?

  75. nicoco

    mmm I was not clear. I am the MUC, and I tried to send a message to a "joined resource", and received an error.

  76. nicoco

    or do you mean when that happens, I should send 'kick' presences?

  77. pep.

    hmm I was talking about the other way around yeah. I don't know here.

  78. nicoco

    I AM THE MUC, SKYLER

  79. nicoco

    (sorry)

  80. MattJ

    nicoco, these are the errors a MUC should kick an occupant for sending: https://hg.prosody.im/trunk/file/tip/plugins/muc/util.lib.lua#l27

  81. pep.

    (BB?)

  82. pep.

    The thing about all these rules is that they're too many and it's hard to remember all of them.. and they're also often encoding in fancy wording in the spec or it's a combination of 50 different things ><

  83. pep.

    Kicked on gone/redirected?

  84. nicoco

    MattJ: oh OK, so not all errors then. does prosody also send a presence with some status codes when happens or does "kicking" just means "I'm not going to send you anything from now on"?

  85. MattJ

    I think we don't send anything to the leaving occupant - the assumption being that 1) we are unable to reach them, 2) it could cause an error loop (generally responding to an error is not something you should do)

  86. nicoco

    Thanks a lot! This is what I was going for, without even thinking of the possible loop problem (d'oh!). So I was "accidentally right".