# summary
From its conception, #Enigmatick has leaned heavily on the `inbox` and `outbox` endpoints for client operations. [...]

# content
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 is defined as the system Application user is important. That's 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.

# source.content
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` is defined as the system `Application` user is important. That's 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.

![The Enigmatick instances UI showing the most recently discovered instances from the enigmatick.social server](https://enigmatick.social/media/uploads/3c327280-2358-468a-bea9-b77d9f016ebb.png)

## 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.

```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.

# attachment[].name
The Enigmatick instances UI showing the most recently discovered instances from the enigmatick.social server