How Solid and ActivityPub complement each other best

This is a follow-up to Which links between ActivityPub and Solid project?.

Solid (discussed on their community forum) and the Fediverse have a lot in common. For the future of the Decentralized Web it is very important for there to be convergance of initiatives, instead of fragmentation.

I’d like to dedicate this thread to investigate the ways in which Solid and Fediverse can complement each other.

First note that there are already ActivityPub + Solid combined applications, like openEngiadina (@pukkamustard), Agora (@Smag0), SemApps, life-server and other work, like @aveltens Solid Group App (see also Groups implementation) lend themselves well to become compatible.

To kick this off here are some points where each initiative imho could learn from the other:

Fediverse 2 Solid:

  • Communication / messaging patterns at scale in production environments
  • Lessons-learned in production environment (e.g. performance-wise)

Solid 2 Fediverse:

  • Data storage strategies that are private-by-default (i.e. POD’s)
  • Enjoying the full richness + benefits of linked data (semantics, ontologies, etc.)

Common concerns

  • Identity (SSO, roaming identity), auth / authz
  • Compatibility (specs, semantics, ontologies)
  • Encryption

You probably have many more, and more detailed, additions to this list, so fire away :slight_smile:

PS: I created this exact same topic on Solid forum (with some links changed in context).

Edit: Note that there is also Encrypted Data Vaults which seems to have much in common with Solid.


Cross post about Agora

@how, @cwebber the agenda point of Links between AP and Solid had been there for a while without anyone to discuss with, so I raised attention on the Solid forum and the External Interop Panel and just now received an extensive response from @csarven on github where he mentions potential areas of interop, and also ends with the invitation:

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

I am just the communicator between socialhub and solid and not the expert to drive this further, but I hope based on this you’ll find common touchpoints :slight_smile:

Here is the full response by @csarven mentioned in the previous post, so you don’t have to run out to GH:

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): . 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:

As an example implementation, dokieli ( , ) is a Solid application that also conforms to ActivityPub Client-to-Server Client ( ) 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 , solid/node-solid-server#621 , solid/solid#242 , … 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 ( ) 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: tootsuite/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.

1 Like

I linked an as:outbox from my Solid WebID Profile:

The outbox is both, a LDP container as well as a as:OrderedCollection and links to some pages containing some activities. I handcrafted the data, but I guess a Solid Server could easily implement native support for activity streams collections in addition to LDP.

1 Like

@aveltens nice work

So a major problem right now is that said outbox does not serve json-ld

curl -H “Accept: application/ld+json”
Error translating between RDF formats

Its unfortunately quite difficult to get fixes upstream at the moment. But local patches could be applied to create the interop that was promised

1 Like

In theory this should work, but I guess it is a Bug in NSS. After digging a bit deeper into ActivityPub I think it should be no big deal to make a Solid Server compatible.

I stumbled upon this post describing how to do a ActivityPub post manually and going to try it out some time next week using Solid.

I was reading that post too and I came to a similar conclusion

I’d like to see a server that works with both systems

Either NSS patched to work with AP and JSON-LD

Or, say, a mastodon server patched to work by giving JSON-LD in the profile page and also including public key material

There is a slight difference between how public keys are displayed in AP/Solid in that AP uses publicKeyPem and Solid uses modulus/exponent. But modulus/exponent failed to catch on and if I was starting again, I’d probalby align to the way the fediverse does it

I see great potential at the intersection of both worlds to have a server that can post activities to other servers. And to have a profile that can log in to any solid pod, use solid apps, use it for cloud storage etc.

1 Like

Also check out the wiki post on this forum Guide for new ActivityPub implementers