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

Daniel Gultsch daniel at gultsch.de
Wed Jul 11 07:01:40 UTC 2018


Either include status code 110 in the unavailable presence or use an
error presence.

The XEP is a bit fuzzy on when to use what. But I won’t be able to
parse an unavailable w/o 110

So in your case (a join attempt to the tombstone) I have a slight
personal preference toward error; But I’m ok with both as long as the
unavailable has a 110.

2018-07-11 4:02 GMT+02:00 Kim Alvefur <zash at zash.se>:
> 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?
>
> --
> Kim "Zash" Alvefur
> Destroyer of rooms
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>


More information about the Standards mailing list