[Standards] XEP-0045: How to signal tombstones for destroyed rooms?

Kevin Smith kevin.smith at isode.com
Wed Jul 11 08:10:34 UTC 2018


On 11 Jul 2018, at 03:02, Kim Alvefur <zash at zash.se> wrote:
> 
> Hello list,
> 
> I have implemented tombstones for destroyed MUC rooms. My reading of the
> sacred texts did not give me enlightenment as how to inform someone
> who's attempting to enter the remains of such a place. I've so far opted
> to return an <presence type=unavailable> with the same <destroyed> child
> that was in the inital announcement of the rooms destruction.
> 
> Of the clients I’ve tested so far, only Gajim seems to understand this.
> Swift says something unspecific about failure to enter the room, while
> Pidgin and poezio say nothing.
> 
> So basically, this is the reply one gets to a MUC join:
> 
> ``` xml
> <presence type="unavailable" id="" to="me at localhost/r" from="a at gc.localhost/n">
>  <x xmlns="http://jabber.org/protocol/muc#user">
>    <item affiliation="none" role="none"/>
>    <destroy>You see only a crater.</destroy>
>  </x>
> </presence>
> 
> ```
> 
> Does this make sense?

I’d go slightly differently from the other replies - if you want it to be clear that the room is destroyed and tombstoned, I would send an artificial join success followed immediately by room destruction, as we *do* have a way to signal destruction once you’re in the room.

I would expect all clients to be happy with that and it’s clear that the room is destroyed. I think any other mechanism and you’re either sacrificing knowledge of the tombstone or knowledge the join failed, depending on implementations.

/K


More information about the Standards mailing list