Activity Streams/Primer/Tombstone type

The Tombstone type represents a deleted object.

The Tombstone has the same id as the deleted object. In the Activity Streams 2.0 world, it is the deleted object, somewhat transformed.

Usage

Using a Tombstone object to represent deleted objects lets us retain the references to the deleted object without having them fail.

For example, in a collection of replies to a Note, the reference to a deleted object can be retained:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Collection",
  "id": "https://example.com/note/1/replies",
  "items": [
      {
         "type": "Note",
         "id": "https://example.org/note/17"
      },
      {
         "type": "Tombstone",
         "formerType": "Note",
         "id": "https://social.example/note/304"
      },
      {
         "type": "Note",
         "id": "https://example.org/note/19"
      }
  ]
}

Here, the Tombstone object is holding the place of the deleted Note. A user interface may represent this object with some placeholder, like the words "(deleted)", a grayed-out box, etc. It could also elide the object entirely.

The alternative is that when an object is deleted, the originating server must deliver that deletion activity to every single server that might have a reference to the original object, and all of those servers would need to remove the deleted object from their collections. The tombstone allows the reference to stay in the collections, without being treated as a fully valid object.

Properties

On deletion, the originating server should remove most of the properties of the original object from the Tombstone. This preserves the intention of the deleter, who wants to make the data unavailable.

The Tombstone type includes two properties not found in other AS2 object types:

formerType: Indication of the former type of the object.
deleted: timestamp when the object was deleted.

Note that there is a balance in user considerations between the deleter's needs and the reader's needs. The deleter wants the object to be forgotten, but the reader may want to know when the object was deleted, what type it used to have, etc.

Authorization model

Some properties are important to retain in order to represent the authorization model of AS2:

attributedTo or actor
addressing properties

Conversation trees

The inReplyTo and replies

inReplyTo
replies

Properties like inReplyTo and replies can maintain the connectedness of a reply tree.

context is also sometimes used for a collection of all objects in a conversation tree.

Removing the reply-tree properties cuts off any replies to the deleted object from the rest of the tree.

Server implementers may want to consider balancing the needs of these repliers (not to be cut off from the conversation) and the needs of the deleter (to remove themselves from the conversation).

For example, here is a Tombstone object with replies and inReplyTo intact:

{
   "@context": "https://www.w3.org/ns/activitystreams",
    "inReplyTo": "https://example.com/note/0",
    "id": "https://example.com/note/1",
    "type": "Tombstone",
    "replies": {
         "id": "https://example.com/note/1/replies",
         "type": "OrderedCollection",
         "items": [
            "https://example.com/note/2",
            "https://example.com/note/3"
         ]
     }
}

Here is one with the tree connectivity severed:

{
   "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://example.com/note/1",
    "type": "Tombstone"
}

Interactions

Deleted objects should not be shared, liked, replied to, or otherwise interactable.

The collection indicated by a Tombstone's replies property should not accept new replies. It may remove replies if they in turn are deleted.

The objects in the replies can be fully interacted with -- liked, shared, replied to, updated or deleted.