So the Spaces are now merged in Movim main branch! 🎉 The official instance https://mov.im/ has been updated 😸!

Do you want to know how it was done? And how it is actually implemented in Movim? I wrote a very detailed blog post about it there: https://mov.im/community/pubsub.movim.eu/Movim/fb46d699-adc1-4fda-a76e-71ca1d246b80 👀

The upcoming days will now be spent on stabilizing and fixing all the bugs we can find 🐛

And as always, if you want to support me in this amazing journey https://movim.eu/#fund ✨ And don't forget to spread around the good news 📢!

#xmpp #discord #xmpp #spaces

@movim awesome start! a few questions though:
It's an XMPP URI where the first part is the XMPP service hosting the Space, and the node part is the Space's identifier.is it possible to change the invitation key/node of a space? the post seems to imply it's an ID for the entire space as opposed to just the invite itself, which makes me concerned that staff may not be able to kill any existing links and re-create them in case the links accidentally leak out or to just limit joins for some time (e.g. recovering from raids)
- Adds the Space bookmark
- Sends a subscription request to the PubSub node.is the possibility of one of these requests succeeding while the other fails handled appropriately? i assume this is an xmpp pattern that's been well-trodden but as an outsider it caught my eye and makes me wary of hard to debug bugs where you have a bookmark to a space that hasn't received your request, or not having a bookmark for a space that has already accepted your request, that may end up diminishing overall user experience