I split my initial post in a number of issues on the new activitypub-interop repo, so that it will be easier to discuss the details. Feel free to create other issues, or comment the existing ones!
Only some testing and research. No meaningful code, yet. This is still high on my list, but I was busy with other work.
I looked at how json-ld looks when it’s produced by CSS, and if it looks anything like the simple format that e.g. Mastodon may expect. (it does not.) There could be a way - having the webId stored as json-ld; but it’s already causing issues - NSS doesn’t authenticate such agent (i suspect it doesn’t ask for text/turtle, and receives the default json-ld instead). CSS seems fine with webId stored in json-ld representation.
Also thought of a name for the project, came up with soap-opera
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
The first is more note/tutorial/primer like, because a large part of the content is just redescribing ActivityPub for a Solid audience.
The second assumes prior knowledge of ActivityPub and primarily describes what is needed to integrate ActivityPub with Solid, based on three architectures:
Server support
External processing
External endpoint
I’m happy to do some writing of a first rough draft if there is interest in either or both of these.
inbox and outbox are public append LDP containers that receive activities
Nice that it works! We should note though that exposing public append container without built-in authentication and validation is likely a security issue (it’s very easy to overwhelm the pod with junk data). Worthy experimental solution, but I have concerns it might not be suitable for production.
I think it’s worth revisiting some spec/primer writing.
Yesterday at Solid CG meeting, the topic of new Task Forces came up. Would you be up for starting one for this purpose? @jg10@thhck@srosset81
If we agree to do that, how do we go about that in relation to CG? @elf-pavlik
Authentication is actually just verification of the sender. It’s not a barrier to spam given that a spam sender can sign their messages with their own actor.
My understanding is that validation is mainly of content type + checking it’s well-formed (activity/ld) json.
Yes, data size is an issue. Some kind of quota should be in place, and this is a reason the inbox does need to be continually processed. CSS already has quotas.
I believe in a plurality of solutions - there’s always an engineering tradeoff. I’m not suggesting that external processing be used on an inbox where DOS is a major concern. It’s a simple architecture that scales well on top of existing pods - it can enable 1000s of actors across servers with a single webhook. Perhaps implementing external endpoints can be done in a way that is similarly simple and this advantage would be diminished?
I’m happy to do some draft writing. I’m not sure about joining a task force.
