Skip to content

Add formerType property to Tombstone #645

@dahlia

Description

@dahlia

Problem

Tombstone in the ActivityStreams vocabulary has a formerType property, which identifies what type the deleted object used to be (e.g., Person, Note). Implementations like Mastodon include this field when signaling account deletion, and remote servers use it to understand what kind of resource was removed.

Tombstone is already part of @fedify/vocab, but formerType is not yet implemented as a typed property on it. This means there is no way to set or read formerType through Fedify's API, which becomes more relevant now that #644 allows the actor dispatcher to return a Tombstone directly.

Proposed solution

Add formerType as a property on the Tombstone class in @fedify/vocab, following the same patterns used for other single- and multi-valued object properties elsewhere in the vocab package.

The property should accept one or more values, but the exact accepted type(s) need some discussion—see below.

Value format: a point of discussion

The Activity Streams 2.0 spec lists the range of formerType as Object, which suggests the value should be a full object reference. However, the spec itself uses a bare type name string in its own example:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Tombstone",
  "formerType": "Image",
  "url": "http://example.org/image/2"
}

Checking the AS2 JSON-LD context, formerType is defined as "@type": "@id", meaning the value is treated as an IRI. The bare string "Image" in the spec example is therefore a relative IRI, which is arguably imprecise—but it reflects how implementations actually use the property in practice (Mastodon, for instance, serializes formerType as a plain type name string).

There are two reasonable options for what Fedify's API should accept:

  1. Object | URL only—strict and type-safe, but inconvenient when the caller just wants to express a type name
  2. Object | URL | (new (...args: any[]) => Object), where a class constructor is accepted and Fedify extracts the corresponding type IRI automatically (e.g., Personhttps://www.w3.org/ns/activitystreams#Person)

Option 2 seems most practical: it is type-safe, matches how vocab classes are used throughout Fedify, and avoids the ambiguity of bare strings.

Usage example (assuming option 2)

return new Tombstone({
  id: ctx.getActorUri(identifier),
  formerType: Person,  // pass the class itself, not an instance
  deleted: account.deletedAt,
});

Or with a full object instance, if available:

return new Tombstone({
  id: ctx.getActorUri(identifier),
  formerType: new Person({}),
  deleted: account.deletedAt,
});

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions