Enigmatick ActivityPub C2S

[jdt@enigmatick.social]

From its conception, #Enigmatick has leaned heavily on the /inbox and /outbox endpoints for client operations. There are some /api endpoints, but I avoid that were I can shoehorn operations into the #ActivityPub specification and #ActivityStreams vocabulary.

While typical operational activities are fairly well accounted for, administration is a weak point. For example: I haven't identified a clear way to use the currently described mechanisms for an administrative user to pull up and manage instances or actors on a server.

I've relied on CLI tools (e.g., ./enigmatick --help) to manage some of that. And in some cases, I know how to manipulate data in my database, so I haven't worried too much about building tooling. But I'd like to ship something that other folks can use to share in my efforts, so I've been thinking about how to model those activities in an ActivityPub-esque way to use in the Svelte UI.

ActivityPub Messages

To that end, I'm now using Block and Delete activities sent from the client to the server outbox to manage the blocking of instances and purging of data.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ek": "https://enigmatick.social/ns#",
      "Instance": "ek:Instance"
    }
  ],
  "id": "https://enigmatick.social/activities/550e8400-e29b-41d4-a716-446655440000",
  "type": "Block",
  "actor": "https://enigmatick.social/user/system",
  "object": {
    "type": "Instance",
    "id": "https://spammy-instance.example"
  }
}

In practice, my client does not generate the id, but that attribute is generated by the server and the Activity is stored alongside other typically federated activities. These local Block activities are not federated out to other servers; they are intended solely for local server management.

The Block activity is sent as a message signed at the client by a user with administrative privileges on the server. Enigmatick's user authentication is unique (i.e., I use a separate set of encryption keys for client-signing executed by a wasm module in the browser). That can be a topic for a future article.

That the actor as the system Application user is important. That is used by the server to establish the scope of this action as system-wide, not just for a single user. The system actor is discoverable in the nodeinfo metadata.

I'm using a typed object rather than just an id reference. This is so that I can use this same flow for blocking and purging Actor objects (i.e., the type would be Person, Service, or Application).

The purge action is similar, using the Delete activity.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "ek": "https://enigmatick.social/ns#",
      "Instance": "ek:Instance"
    }
  ],
  "id": "https://enigmatick.social/activities/550e8400-e29b-41d4-a716-446655440000",
  "type": "Delete",
  "actor": "https://enigmatick.social/user/system",
  "object": {
    "type": "Instance",
    "id": "https://spammy-instance.example"
  }
}

The term, "delete" is a bit of a misnomer in this case as it applies to the instance specifically. The instance will remain, but the objects, activities, and actors associated with that instance will be fully deleted (i.e., not set to Tombstone).

Collection Endpoints

To facilitate the UI operations, I've created two new collection endpoints on my server: /instances and /actors. These endpoints provide typical ActivityPub Collection objects.

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "Instance": "ek:Instance",
      "activitiesCount": "ek:activitiesCount",
      "actorsCount": "ek:actorsCount",
      "blocked": "ek:blocked",
      "ek": "https://enigmatick.social/ns#",
      "lastMessageAt": "ek:lastMessageAt",
      "objectsCount": "ek:objectsCount"
    }
  ],
  "type": "OrderedCollection",
  "id": "https://enigmatick.social/instances",
  "totalItems": 7702,
  "orderedItems": [
    {
      "type": "Instance",
      "id": "https://example-instance.name",
      "blocked": false,
      "created": "2025-12-16T16:56:33Z",
      "lastMessageAt": "2025-12-16T16:56:33Z",
      "actorsCount": 0,
      "objectsCount": 1,
      "activitiesCount": 0
    }
  ],
  "first": "https://enigmatick.social/instances?max=9223372036854775807",
  "last": "https://enigmatick.social/instances?min=0",
  "next": "https://enigmatick.social/instances?max=1765657395402834"
}

I've added some extensions in the @context to account for a few non-standard attributes.

That collection is used by the UI.

Collection Discovery

nodeinfo is a common protocol used for discovering information about ActivityPub-speaking servers. I've extended my use of that to facilitate client-discovery of these new endpoints using the metadata object contained in the nodeinfo JSON.

"metadata": {
  "actor": "https://enigmatick.social/user/system",
  "adminActors": "https://enigmatick.social/actors",
  "adminInstances": "https://enigmatick.social/instances",
  "domain": "enigmatick.social",
  "url": "https://enigmatick.social"
}

Final Thoughts

As I'm reading through this, I see some opportunities for refinement. I should probably be using OrderedCollectionPage instead of OrderedCollection for my collection endpoints. I'm sure there are other tweaks to be made.