Rework room destruction handling
There are two issues, three maybe.
See https://xmpp.org/extensions/xep-0045.html\#destroyroom
The destroy tag in 0045 takes an optional JID parameter that will be used as a redirect, a replacement for the destroyed room. Our current /destroy_room
command takes an optional Jid, that is the room to destroy, and it uses the current room when that one is not specified. How do we reconcile both.. Being able to specify a redirect is actually quite handy.
Some server implementations also add tombstones in stead of the destroyed rooms. That looks like the following:
C:
<presence to='a@muc.example.com/Alice' id='CSi8x-1540' type='unavailable'></presence>
<presence to='a@muc.example.com/Alice' id='CSi8x-1541'>
<status/>
<priority>0</priority>
<x xmlns='http://jabber.org/protocol/muc'>
<password/>
<history maxstanzas='250'/>
</x>
<c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://www.igniterealtime.org/projects/smack' ver='yUzUyrQ+S1qbhHsRIdx/NNHUBtM='/>
</presence>
S:
<presence type='error' from='a@muc.example.com/Alice' id='CSi8x-1541'>
<error type='cancel'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>xmpp:b@muc.example.com?join</gone>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>I grow tired of this place</text>
</error>
</presence>
(Thanks Zash)
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information