jdev - 2023-11-21

Beherit, Yes

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.

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

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

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"

Either that or some sort of redirect.

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

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

> 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. ↺

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.

> 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 ↺

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

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.

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

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

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

Sounds like it can work with some and break in others

Maybe it's time for clients to handle redirects

> 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 🫠 ↺

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.

Redirect _after_ creation then?

Then you can still receive the room config form

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'"

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

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 :))

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

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

but no client will do that without being held just right

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

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.

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

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.

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?

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

Indeed

Tho a client could be aware of gateways?

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

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

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

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

xml order is precedence with ad hoc

Kev, did you get my email message?

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?

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

kinda like per-client offline messages, but deduplicated

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?

so if I use BIND2 today I'll lose messages

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

I think two weeks is much too short for that 😛

🙃️