Some applications have many kinds of objects that you may wish to modify, or follow, or be followed by and so on. How to decide, which objects in a web application will be ActivityPub actors, and which won’t be?
What are the best-practice requirements for turning some object into its own actor?
- The object needs to have its own inbox? (is this ever required?)
- Needs to have its own list of followers? (for example to allow to follow a specific issue in an issue tracker)
- The object is conceptually an independent entity not strictly tied to an owner object by definition? For example, an issue/bug is tried to a specific software repo, but the repo itself usually isn’t tied to the user publishing it - a repo can change owner and still it’s the same software; who maintains the repo is a secondary detail
Cons of turning many object types into ActivityPub actors:
- If the actor needs to POST things (e.g. you follow an issue and the issue delivers a new comment or status update to you), it needs a cryptographic key for signing/verification of HTTP signatures. If you give each actor a separate key, that can mean many thousands of keys. In my implementation I have a little extension that allows actor keys to have instance scope, i.e. a key can sign activities for any actor on that server, and in that case having many actors is a smaller problem. But note that this is a problem only if the actual object needs to deliver stuff; usually objects that are software managed (such as projects, tickets, etc.) don’t actually initiate sending stuff, the actual actions etc. are initiated by the human user actors. And then, those non-human actors such as projects don’t need to have keys.
- Each actor has its own inbox URI. Unless you use
sharedInbox, that means lots of GETs and lots of storage just for the inbox URI of each tiny object. @cwebber said at FOSDEM that
sharedInboxwas a mistake: Why is that, and is there a good way to avoid GETing/storing the inbox URI of many tiny objects, even if they all use the same URI?
- Hmmm other cons?
Pros of turning many object types into ActivityPub actors:
- Activities are POSTed to URIs that correspond to the object being modified, so it’s closer to traditional RESTful APIs, there’s no single inbox URI to which everything is sent. Perhaps this is also good in some security sense? That separate URIs handle changes to separate objects.
- Objects can be followed using the plain regular Follow activity without any application-specific knowledge. Otherwise, if a project has 1000 issues, each one needs its own followers collection - how would that work? I admit I haven’t thoroughly checked yet.
I guess several points above are about scaling: Some objects are very small and trivially created (say, tickets and comments) while others are more significant entities that usually don’t come by the thousands. So, when considering scaling, and the “conceptually independent” intuition, we could e.g. say, let people and projects be actors, while tickets and smaller things aren’t actors.
That sounds fine and reasonable to me, as long as there’s a good way to handle the following of objects that aren’t actors, for example tickets. I’ll look into that. But for now, I’d love to hear what people think