I’ve been spending a bit of time catching up on this discussion and experimenting. I have successfully subscribed to remote ActivityPub actors and processed inbox activities. (My write-up: JG10 Solid devlog )
- I ended up using an architecture not yet mentioned here, in which the inbox and outbox are public append LDP containers that receive activities. Solid notifications are used to notify an external agent that reads the new activity and processes it. This works because Solid already supports Linked Data Notifications, and ActivityPub specialises LDN, as @srosset81 notes in the OP.
- Most requirements can be met on CSS by specifying the required content type when saving the resource.
- The client does need to be able to understand the activity+json content type, which rdflib.js does since 2.3.0 (thanks @aveltens !)
At the moment the only issue I have found to require server support is that an LDP container requires content negotiation to be delivered in activity+json , which would also likely need to omit LDP triples. Content negotiation is already the solution recommended by the Social Web Working Group. ActivityStreams collections · Issue #3 · solid-contrib/activitypub-interop · GitHub
However, this affects the inbox collection, which is only used by the client, and the outbox collection, which many ActivityPub implementations ignore (e.g. Mastodon just extracts the number of items), so I have proposed: Offer a Solid C2S profile that doesn't conform to application/activity+json · Issue #18 · solid-contrib/activitypub-interop · GitHub