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

Florian Schmaus flo at geekplace.eu
Wed Jul 11 07:15:17 UTC 2018

On 11.07.2018 07:52, Jonas Wielicki wrote:
> On Mittwoch, 11. Juli 2018 04:02:23 CEST Kim Alvefur 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?
> Is there a reason to not use a presence type="error"? I’d expect clients to 
> handle those already. 

Yep, Smack would handle an 'error'. I also lean towards 'error'. Any
reason why you choose 'unavailable'? IIRC 'error' presences are usually
send as a result of another presence, whereas 'unavailable' presences
are usually send independently of other prior presences. Hence 'error'
seems more suited in this case.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180711/847be9ed/attachment.sig>

More information about the Standards mailing list