Sending activities

[jg10-mastodon-social]

Sending activities from a Solid-pod based actor can be performed from a server/CLI after uploading static documents for an actor and webfinger document (to enable discovery of the actor).
The remote server will send acknowledgements to the inbox endpoint.

No other server side support is needed.

• Actor type and predicates #9 (comment)
• Webfinger endpoint #6

Examples:

• https://datenwissen.de/2020/07/mit-solid-nach-mastodon-posten-geht-das
• https://blog.joinmastodon.org/2018/06/how-to-implement-a-basic-activitypub-server/
• https://gitlab.com/Vinnl/martin

[mrkvon]

Say I develop a social Solid+ActivityPub app. How would it work with this approach? E.g. how does my app sign and send out an activity? I suppose posting to outbox or triggering a custom API would be options, as @jg10-mastodon-social pointed out

[jg10-mastodon-social]

From the point of view of this spec, I think there would be no new normative statements for sending activities? The spec would describe the existing ActivityPub requirements, perhaps mention as examples the different options, and leave the rest as implementation detail?

Alternatively perhaps the recommendation should be that servers SHOULD implement the C2S outbox - encouraging interoperability?
https://w3c.github.io/activitypub/#client-to-server-interactions

[mrkvon]

Sending activities from a Solid-pod based actor can be performed from a server/CLI

In this context, I don't understand how a client interacts with the server/CLI when it wants to send a signed activity. I suppose it's valuable to have some defined API to be able to build interoperable apps. What are your thoughts on this @jg10-mastodon-social ?

[jg10-mastodon-social]

If the app is not conforming with the outbox spec, then how the client interacts with the activity sending code is an implementation detail.

We do know that CORS is often not available on remote servers, so sending activities wouldn't usually be done from the browser.

Each app could create its own API, generate its own key pair, create its own actor, and add it to the Webfinger document.
The app needs append access to the Webfinger document and an LDP container anywhere.
The basic level of app interoperability - that all data is stored on the same Solid server is therefore already possible.
If the actor doesn't need to be discovered then even access to the Webfinger document is not needed.

If multiple apps need to share a single actor, then they do need to have shared ability to sign with a private key.
I think I agree that the outbox is the best way to do this - the alternative being somehow storing the private key on the pod.

[jg10-mastodon-social]

Interoperable delivery of activities is summarised at https://www.w3.org/TR/social-web-protocols/#delivery-activities

Interoperable publishing of activities is summarised at https://www.w3.org/TR/social-web-protocols/#creating

[jg10-mastodon-social]

I've successfully implemented an outbox where a browser application makes a Solid-authenticated post to the LDP container, and an external processing agent then signs and sends the activity.

Works fine, though as an async model there's no immediate feedback to the sender.
The processing agent needs to implement side effects, and the browser application would need to check for the side effect to be complete, e.g. using web socket.

This is possible with the Solid spec, but an external endpoint might provide better devx, at the expense of defining new synchronous server APIS.