jdev - 2023-11-21

  1. Schimon

    Beherit, Yes

  2. nicoco_

    If I want to create `a-cool-name@rooms.what.ever`, is there a standard mechanism for `rooms.what.ever` to tell my client: OK you can create a room, but its JID is going to be `SOMETHING@rooms.what.ever instead` of `a-cool-name`? The context is, drum rolls, gateways, where "room IDs" are generally (always?) something that the user cannot choose.

  3. Zash

    NAFAIK but we've had thoughts about creating rooms via some iq to the MUC host.

  4. Zash

    Probably looking like the create-and-configure stanza and have it return the JID

  5. nicoco_

    Thanks. So I guess the best way - without a new standard - is to implement room creation as adhoc commands, eg, "Create room" > "Choose config/members" > "Here's your JID: xmpp:gibberish@gateway?join"

  6. Zash

    Either that or some sort of redirect.

  7. Kev

    You *could* do something slightly unpleasant by having the room creation fail, but then the gateway send an invite to the new gatewayed room.

  8. nicoco_

    > Either that or some sort of redirect. Something like room creation, then the MUC service sends a "room destroyed, go here"?

  9. nicoco_

    > You *could* do something slightly unpleasant by having the room creation fail, but then the gateway send an invite to the new gatewayed room. Thanks, that's a neat idea. Because even if I go for the adhoc way, I can't prevent clients from trying to create rooms, and it sounds better to do that than to just fail. One thing I'm concerned about with this approach, is that I am not sure all legacy services allow room config to switch between being a "private group" and a "public channel", so we may need to decide that on room creation.

  10. Zash

    At the same time, you could twist the MIX channel creation flow into something suitable, then maybe it'll be easier to switch to MIX incrementally at some distant point in the future.

  11. edhelas

    > You *could* do something slightly unpleasant by having the room creation fail, but then the gateway send an invite to the new gatewayed room. Looks hacky indeed

  12. Zash

    If it's hacky and it works it's doomed to get entrenched in production forever!!

  13. nicoco_

    Hmmmmm frankenmixmuc monster sounds scary and bug prone, unless I did not understand what you meant? I think I'll do a combination of adhoc / creation fail->invite for a start, when I start actually coding something. That is probably something that should be covered by "gateway interaction 2.0", someday... Groups are basically not covered at all by XEP-0100 anyway.

  14. Kev

    You don't need the creation to really fail, just to end up with something that redirects.

  15. goffi

    nicoco_: can't you keep `a-cool-name` and internaly translate to whatever the legacy network is using?

  16. lovetox

    A redirect on creation, clients will not expect this ..

  17. lovetox

    Sounds like it can work with some and break in others

  18. pep.

    Maybe it's time for clients to handle redirects

  19. nicoco_

    > nicoco_: can't you keep `a-cool-name` and internaly translate to whatever the legacy network is using? I thought of that but less bookkeeping = happier dev 🫠

  20. nicoco_

    lovetox: I feared this indeed. A dedicated adhoc command sounds reasonable, especially with a "chatbot command" as a fallback for clients not supporting adhoc commands I think.

  21. Zash

    Redirect _after_ creation then?

  22. Zash

    Then you can still receive the room config form

  23. nicoco_

    I only see "owner destroys room" but I don't see "service destroys room", am I looking at the wrong place? Because the destroy flow is owner sends IQ, then gets IQ confirmation. Maybe it could just be "service sends presence unavailable/x/destroy/reason= 'go to jibberish@what.evs'"

  24. singpolyma

    I mean, are clients likely to try creating a muc on your service? More likely they'll make a MUC on a different service and try to invite you

  25. nicoco_

    Not sure I follow what you mean singpolyma. I'd like to allow users (ie, me) to create groups on the awful walled gardens. The way I see it, you create a group, then invite the legacy contacts into it, but this is the next part I need to read more specs about, I think affiliations are the mechanism I want to manage members of the group (let's put public channels aside for a start :))

  26. singpolyma

    Right, but you want them to create on @legacy.slidge.service.tld  yeah?

  27. singpolyma

    for the "error and/or redirect" flow that was being discussed

  28. singpolyma

    but no client will do that without being held just right

  29. Zash

    Should clients assume, or be told, that legacy.example.com is a kind of scope? If that makes sense. That you can create chats and invite contacts from that scope but not outside it

  30. nicoco_

    Oh I see singpolyma, in Cheogram for instance I cannot choose the domain part indeed. I suspect I can in gajim though? Anyway, all the more reason for the "main" flow to be through an adhoc command on the gateway component.

  31. singpolyma

    The natural flow people will try is to create a MUC that is *not* on your MUC service and invite their contacts there.  I'm not saying this is easy to make work, or even necessarily possible to make work, but probably should see if we can at least get them some kind of "no you're doing it wrong" feedback when they try that

  32. nicoco_

    Good point. Sending an invitation to join a MUC not on the bridge to a "legacy contact" should trigger a message from the gateway saying "nope, this does not work, XXX is trapped in WhatsApp!". I am not sure we can prevent making those contacts affiliated members of any MUC though.

  33. Zash

    Hm, given a legacy.example.com and rooms.example.com, both claiming to support MUC stuff, could you heuristically pick the former for legacy-contact@legacy.example.com over the other based on proximity?

  34. singpolyma

    normally I can't create on my contacts' MUC services

  35. Zash


  36. Zash

    Tho a client could be aware of gateways?

  37. singpolyma

    yes. if the gateway advertised a MUC service (or was one) then maybe. but then it wouldn't actually work anyway (the room creation) and the discussion was about how to work around that, so I'm not sure it's worth it vs better ad hoc support

  38. singpolyma

    nicoco_: if you end the ad hoc flow with one of the payloads being jabber:x:oob url xmpp:blah@blah.tld?join  then cheogram android will offer to join the room for the user

  39. nicoco_

    oh, that

  40. nicoco_

    interesting! outside the jabber:x:data form I guess?

  41. singpolyma

    yes, outside. as a sibling before it in the parent

  42. singpolyma

    xml order is precedence with ad hoc

  43. Schimon

    Kev, did you get my email message?

  44. singpolyma

    So, BIND2 says that the offline message queue should be purged and you use MAM instead.  Seems mostly sensible, except for what if I don't log in for 7 days (or whatever my host uses for MAM expiry) ... am I just going to lose messages now if I use BIND2?

  45. Zash

    singpolyma, I believe the plan is to use the client tracking enabled by {SASL,BIND}2 to know for sure whether you retrieved the messages

  46. Zash

    kinda like per-client offline messages, but deduplicated

  47. singpolyma

    so, to ignore the expiry time if no one has got the messages yet?  that seems fine, but I guess by "the plan" this hasn't happened yet?

  48. singpolyma

    so if I use BIND2 today I'll lose messages

  49. Zash

    Heh, I have a weird dream where if you don't sign in for two weeks, you lose your whole account ;)

  50. singpolyma

    I think two weeks is much too short for that 😛

  51. Zash