Is it correct to say the #Fediverse and #BlueSky are "federated" by protocol bridges?
General Discussion
3
Posts
2
Posters
0
Views
-
Is it correct to say the #Fediverse and #BlueSky are "federated" by protocol bridges? I have similar question related to #Nostr and #Threads and other bridged protocols. Given the #Fediverse is #ActivityPub, what this larger federated social web called?
-
Is it correct to say the #Fediverse and #BlueSky are "federated" by protocol bridges? I have similar question related to #Nostr and #Threads and other bridged protocols. Given the #Fediverse is #ActivityPub, what this larger federated social web called?
-
@reiver I'd consider interoperating social networks to be "federated", but I know it's not a precise term. There are similar ambiguities with other commonly used terms: decentralization, server, node, instance, and so on. We have our personal definitions but find that others have a different mental model than ours. It might be interesting to have a collaborative social web glossary that captures the variations of how these terms are used.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@reiver I'd consider interoperating social networks to be "federated", but I know it's not a precise term. There are similar ambiguities with other commonly used terms: decentralization, server, node, instance, and so on. We have our personal definitions but find that others have a different mental model than ours. It might be interesting to have a collaborative social web glossary that captures the variations of how these terms are used.
-
@rimu@mastodon.nzoss.nz Definitely. Offloading the static assets to nginx is a big win. Varnish adds a layer of serving from memory that takes it up a notch. Like having your own Fastly pop.
It does require some configuration nuance to be sure you aren't serving cached assets to the wrong connections (e.g., authenticated GET requests that shouldn't be shared beyond a specific session).
-
-
Is it correct to say the #Fediverse and #BlueSky are "federated" by protocol bridges? I have similar question related to #Nostr and #Threads and other bridged protocols. Given the #Fediverse is #ActivityPub, what this larger federated social web called?
-
@silverpill@mitra.social Thanks - that solves a number of issues I've been encountering. From the outset, I wanted to use the system actor to point at the relevant administrative collections, but couldn't think of a good way to identify the actor to the client (without hard-coding it). That webfinger adjustment solves that.
-
>nodeinfo is a common protocol used for discovering information about ActivityPub-speaking servers
NodeInfo is used primarily by sites like https://fediverse.observer, it is not intended to be used by clients. There is a similar entity in ActivityPub: server actor (instance actor). In your case it seems to be located at https://enigmatick.social/user/system ?
I prefer Webfinger discovery method, as described in this FEP: https://codeberg.org/fediverse/fep/src/branch/main/fep/d556/fep-d556.md.
-
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 MessagesTo 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 EndpointsTo 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 ThoughtsAs 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.
-
Agreed that forums are definitely needed, and the energy NodeBB has brought to the Fediverse has been very welcome indeed! The coexistence is often smooth but sometimes quite clunky (although of course that's true for ActivityPub platforms in general).
Specifically for the deletes, I had also run into problems where they weren't getting propagated everywhere. Not sure if there's a similar thing happening here; If I recall correctly, the issue I was experiencing related to unsigned fetches.
