Toly Menn wrote: > Wouldn’t you have the same problems with the actual messages that > come from the MUC, i.e., they would be blocked by the client? I am > not familiar with how block list work, but no matter where the invite > comes from, once the client joined the meeting, the client will need > to unblock the room.
I think the service would need to be smart about adding the chatroom address to the user's allow list when they join the room. > Would it not be easier to send a “set” iq to the client telling it to > expect an invite from a MUC of the specified name. The client, > having you on its contact list, would get the IQ. The new client > would then unblock the MUC JID for some time (1 minute), reply with > “result” IQ indicating success, and then process the invite as > normal. The old clients will fail as before, but the inviting client > will get an “error” IQ from the old client that it does not recognize > the “set”, and will be able to revert to the “social” technique. Yes, that's another way to do it. Not sure if it makes much difference. Using IQ would require you to know which resource you want to invite, and that seems potentially sub-optimal. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
