FEP-fc48: Generic ActivityPub server

Standards Fediverse Enhancement Proposals
1

This is a discussion thread for FEP-fc48: Generic ActivityPub server.

Summary

Generic ActivityPub server is a server that implements standard ActivityPub client API or FEP-ae97 client API, and can process any activity (including activities those behavior is not defined in the ActivityPub specification).

2 Likes
2

Update: https://codeberg.org/fediverse/fep/pulls/851

I think the FEP now better explains why side effects must be explicit:

A generic server can only carry out the side effects of basic activities. Therefore, clients MUST specify the side effects of all other activities as additional activities. Clients can embed them into an activity using the result property, or send them separately.

1 Like
3

The FEP doesn’t currently point to this Discussion Thread (code).

4

My understanding is that a Generic ActivityPub Server would function similar to an ATProto PDS.

I’m curious on how this compares to projects like rdf-pub, Vocata, and ActivityPods.

1 Like
5

It points to the issue tracker, but this thread can be used too.

Yes, it is similar to ATProto PDSes and Nostr relays.

These projects rely on linked data processing. This FEP attempts to solve the problem with JSON only.

Unfortunately I don’t know enough about these implementations to provide a more detailed comparison.

6

Is there more than the list of 5 basic activities that can be considered generic, I wonder? Perhaps it might make sense to describe what a generic server supports, in the form of Use Cases, in a similar way as the motivational use cases in the ActivityStreams vocubulary spec. Then for each use case a consistent pattern can be specified that MUST be implemented (either refer to AP spec if robustly defined there and/or add additional info on format, behavior, msg exchange).

1 Like
7

I think the FEP should provide an example of following an actor. But I don’t know yet how the sequence should look like :laughing:

1 Like