ActivityPub SocialCG reaching out to Solid

[aschrijver]

Look at this forum post: https://forum.solidproject.org/t/socialcg-meetup-on-solid-activitypub/3028

ActivityPub SocialCG has Solid on the agenda for a while, but so far no one from solid interested. This is spec level discussion and compat with the fediverse.

Next meeting is 2nd Saturday in June (all meetings on 2nd Sat each month).

[scenaristeur]

With some tests https://forum.solidproject.org/t/discussion-solid-vs-activitypub/2685/32

[csarven]

I hope an overview here can helpf to base things off because there wasn't much to the Social Community Group's agenda item beyond a mention of aligning efforts.

While the two projects may not have recently exchanged notes, there is respectable history of interest and work done to interop from early on eg. see the output of W3C Social Working Group (2014-2018): https://www.w3.org/wiki/Socialwg . As far as I know, not much has changed since the WG's output given the state of work in W3C Social and Solid Community Groups. As base:

• W3C Linked Data Notifications ( https://www.w3.org/TR/ldn/ ) was originally incubated in the Solid project and then published through the Social WG.
• W3C ActivityPub ( https://www.w3.org/TR/activitypub/ ) uses LDN's targeting and delivery mechanism with some specific constraints - using W3C Activity Vocabulary ( https://www.w3.org/TR/activitystreams-vocabulary/ ) in compact JSON-LD syntax for the notifications.
• W3C Social Web Protocols ( https://www.w3.org/TR/social-web-protocols/ ) describes how LDN is used in AP, as well as related specs like LDP (having commonality with Solid). Ensuring that LDN and AP can be interoperably combined is something that rhiaro, cwebber and I worked on ( see also: http://dr.amy.gy/chapter5#social-web-protocols , https://csarven.ca/linked-research-decentralised-web#relationship-with-activitypub and #additional-considerations )

As an example implementation, dokieli ( https://dokie.li/ , https://github.com/linkeddata/dokieli ) is a Solid application that also conforms to ActivityPub Client-to-Server Client ( https://activitypub.rocks/implementation-report/ ) requirements.

So far Solid specifications and implementations focused primarily on server-client and client-client (data interop for applications). Solid server-server interaction is within the scope of the project: solid/specification#36 , solid/specification#49 , nodeSolidServer/node-solid-server#621 , solid/solid#242 , https://github.com/solid/notifications-panel ... ActivityPub's fediverse is primarily (but not solely) on server-server communication. I think that's the general area to focus on for interop.

As well as other areas for interop eg. WebID enables loose coupling of identity, identification, authentication, authorization, and storage. AP servers share social activities on behalf of actors. Or even identifying relatively small areas to interop eg. a recent chat on CORS and using proxies in IRC #social ( https://chat.indieweb.org/social/2020-05-04 ) mentioning Solid's CORS requirement and use case requiring the discovery of user's preferred (or trusted) proxy endpoint(s): solid/vocab#26 - that is a shared UC within the scope of ActivityPub. See also: mastodon/mastodon#10400 .

So, dive in - join and contribute to the W3C Social and Solid Community Groups, panels, specifications, implement servers and applications touching both projects.

[aschrijver]

Thanks a lot for this extensive information @csarven it is really helpful! I'll be sure to inform on the SocialHub forum where the SociaCG meetings are planned about your comment.

Edit: Mentioned on 2020-05-09 SocialCG Meeting. I believe the next meeting is Sat 13 June.