activitypub icon indicating copy to clipboard operation
activitypub copied to clipboard

Actor that does not send activities

Open evanp opened this issue 1 year ago • 1 comments

Interesting idea from the fediverse today: can you implement a static actor that is poll-only, and does not deliver activities to subscribers?

https://toot.cafe/@potch/111921390435586597

I think the answer is yes. You'd need an Actor profile with all the required collections, of course.

You couldn't build up a social graph because you don't send Follow activities and you don't respond to them with Accept/Reject.

It would be optional, I guess, whether you also disable any incoming reaction activities (likes, replies, shares). You could definitely maintain the collections with inbound HTTP handlers.

Honestly, I think this is a really nice "first step" for implementers. I might write up a page in the Primer about it.

evanp avatar Feb 13 '24 01:02 evanp

I was able to set up an actor at https://evanp.github.io/actor.jsonld with static files hosted on GitHub Pages.

I added Webfinger support with a static file; [email protected] is discoverable via Webfinger in Mastodon.

I was happy to see that the user is discovered, but the single create activity in the outbox is not. Mastodon apparently doesn't pull the outbox collection when loading a remote actor.

I just finished the chapter on the ActivityPub federation protocol in my book for O'Reilly, and I hadn't really ordered the implementation in this kind of way, but I think this would be a good order to implement AP:

  • Static output -- actors, feeds, and objects should all be represented
  • Accept incoming activities to the inbox -- Handle the main activity types from the AP spec incoming, and update feeds like replies, likes, and shares
  • Deliver outgoing activities -- send outgoing activities to addressed actors
  • Accept incoming activities to the outbox -- let users create and send activities via the AP API

The first one only requires static hosting; the second requires dynamic processing -- like a serverless function or an API endpoint. The third requires (more or less) a queue and retry mechanisms. The fourth is similar to the second, but since you need to have delivery working first, probably needs to come after it.

I'll add a page at https://www.w3.org/wiki/ActivityPub/Primer/Actor_without_deliveries to show how this kind of actor can be set up.

evanp avatar Feb 13 '24 19:02 evanp