Discussion: Solid vs. ActivityPub

To keep people up to date who stumble across this post: there was a response in the chat by Sarven Capadisli (@csarven):

the short answer is that they are not “evolving separately”. Generally speaking, so far Solid focused on server-client arrangement and some of that is already compatible with AP or even possible with the use of AS2. For the server-server bits, that’s something possible and deemed to be within scope! So, interop with the fediverse is not that far off. We just need to identify exact requirements for interop… and that’s something carried out in solid/specification and the solid/notifications-panel (and others).

I’ll look into the thread that’s linked later today. Will follow-up with more details. By the way, some of which are already mentioned in this Gitter solid/chat … search for AP, AS2 etc… I wrote quite a bit about it. See also https://csarven.ca/linked-research-decentralised-web#relationship-with-activitypub

Edit: And he also commented on this here: https://github.com/solid/specification/issues/49#issuecomment-534749588


As mentioned on the SocialHub, some AP implementations are already moving away from interop with Solid by treating the data as pure JSON instead of JSON-LD:

@lanodan wrote:
In the ones used in production and that’s I’m aware of only Mastodon and Friendica are using JSON-LD, meanwhile Pleroma, Honk, PixelFed, … (listed the ones I’m sure about) are treating it as pure JSON (and just pass @context for compatibility). https://litepub.social/ is a group of implementers using ActivityPub in this way.

Some guidance from the Solid community might be useful!


Just a heads up that a SocialCG is being planned, possibly this Saturday, where Solid may be part of the agenda. More info: https://socialhub.activitypub.rocks/t/planning-the-next-socialcg-meeting-when/481/17

I’ll keep cross-posting for a bit, so you are aware of solid things on SocialHub…

strypey wrote:

The lack of smooth inter-op between projects trying to add federated event calendars/ meetup groups to the fediverse (Friendica, Hubzilla, GetTogether, Mobilizon, Gancio, Gath etc) is an example I often bring up. Can anyone with a technical understanding of Solid comment on whether it has a solution for this?

1 Like

Sure there is a lot of interest. Please keep cross-posting :+1:

I put my response to strypey here as i’m new to ActivityPub forum and can put more than 2 links :

Hi @strypey i’m not a backend dev of Solid but a user that build Apps that deal with Solid Pods.
And I’m not really aware of the problemeatics of ActivityPub

And here is a thing i’ve done (before reading ActivityPub concept and so i didn’t use all like outbox for example).

So I wanted to build a “social app” providing the user a way to post some data on his own space (his POD) and make a reference to it on a centralised POD.

So when I log to the app that you can find here
with my webId https://spoggy.solid.community/profile/card#me
and when I (or any authenticated user) post a “Spog”, the data is stored on my/his pod like here https://spoggy.solid.community/public/spoggy/activity.ttl using some activityStream vocabulary like https://www.w3.org/ns/activitystreams#actor .
there could also be attachement to deal with pic/vids, sounds

The post form as a checkbox option to push the post (or a reference to that post) on a “centralizing pod” https://agora.solid.community/public/spoggy/activity.ttl using some activitystreams vocabulary too. These are the post showed on the landing page of the app, and as you can see, there are post from differents people, that are stored on differents users pods.

This could be seen as a Node, I think ?

But there are no notion (for the moment ? ) of outbox, and pushing data from one POD to another, as I have seen with ActivityPub, if I remember.
A way to deal with it could perharps be something like the websockets that is provided by Solid : An activityPub server plugged to a websocket to https://agora.solid.community/public/spoggy/activity.ttl could make the link from Users POD to ActivityPub system but I’m not enough comfortable with activityPub to say more about it.

It is an example of what can be done on Solid., source can be found here https://github.com/scenaristeur/compagent-tuto
I’m working now on another version https://scenaristeur.github.io/salut/ , so If someone want to try some plug between Solid and ActivityPub, let me know, Iwould be happy to contribute.

PS : sorry for my frog eater english :wink:


Just added to the ActivityPub watchlist is this project:


Looks like an interesting candidate for Solid + ActivityPub co-op:

By embracing Linked Data ideas and using ActivityPub openEngiadina builds a network of knowledge that is created trough social interactions. We call this the Semantic Social Network.


Having read both this thread and the one on SocialHub, and some of the linked pages, I’m getting a clearer idea of what Solid is. I can imagine many of the existing ActivityPub apps being re-engineered to be compatible with Solid and vice-versa. In fact, I would go so far as to say that Solid might offer solutions to some of the unsolved problems in the activityverse, especially in areas like making user identity independent of instance, and facilitating user migration from one instance to another.

Since both standards are still fairly fresh and evolving, this will require a lot of trial-and-error, and good faith communication and collaboration between both communities. One project that would facilitate that, is federation between Discourse instances, so that forum threads can be shared between this forum and SocialHub, or between either of those and talk.feneas.org (or all three!). This is a work-in-progress already, but it could become a flagship demonstration of how to use both Solid and ActivityPub in one project.


@strypey I’d would be happy & certainely other here too to contribute to interoperability.
Here it’s how a chat works on Solid for the moment :

  • POD = a personnal storage on Solid
  • webId = the identifier / the login / the identity of the owner of a POD

Each one that has a POD can create as many chat as he wants on his POD, the only limit I know, is the 25Mo sized POD for the moment .

The creation of a chat can be done by the basic tool provided on each POD, the databrowser
and a chat example could be this one https://solidarity.inrupt.net/public/Solidarity/

A chat can be created in the public folder, or in a private, the owner of the POD can also change permission level (read, write) to allow everyone, webIds, groups or apps…

Chat channels on a POD can be found reading the publicTypeIndex of a but like this one
https://solidarity.inrupt.net/settings/publicTypeIndex.ttl where an instance points to https://solidarity.inrupt.net/public/Solidarity/index.ttl#this
Some preference or events can be stored here https://solidarity.inrupt.net/public/Solidarity/index.ttl

How chat is structured ?
When someone post on a chat, that data is stored in subfolders structured by dates
so if you post something today, your post will be stored at https://solidarity.inrupt.net/public/Solidarity/2020/03/27/chat.ttl and here is a most active day https://solidarity.inrupt.net/public/Solidarity/2020/03/25/chat.ttl

Here is the basics of the actual Solid Chat system as provided by the basic tools. But some have other implementation. Another way could be to store the data on user’s POD and share a place to reference this is the approach i’ve adopted for Agora https://scenaristeur.github.io/compagent-tuto/

I’m working now on Solidarity (could be stored on a POD or on gh-pages or in any website ) with @jules .
That is an example of implementation of an UI that read the data on https://solidarity.inrupt.net/public/Solidarity
As already said there is now outputbox system on Solid, but if you want it must not be really hard to send some data (ActivityPub formatted) when someone publish a post on https://solidarity.inrupt.net/public/Solidarity chat :wink: if you just give me an endpoint and what data could be interesting (user, date, …) And a reverse way could be an “activitypub app” that transfert data to the pod in a similar way…

Hope we could interoper’ :star_struck:

@aschrijver @strypey
Could this kind of inbox activities https://agora.solid.community/public/shighl_test/inbox/ could be considered activitypub compatible?

With as: for activitysreams vocab

For a as:Note created by userA, an object is created in his /outbox/objects/ with a content and name then an activity “Create” is created referencing this object in his /outbox/activities/ and a notification is send to the /inbox/ of the recipient ( Agora Pod for a public note, and a pod of userB if the note is a personal message)
Read Authorization for the object & activities created are in concordance with the recipient (public or userB webid)

1 Like

Hi @Smag0, Solidarity looks cool, and really great you are investigating AP/Solid interop. I’m not proficient enough with AP to answer, but have sent a heads up to Strypey on the Fediverse.

I would also post to SocialHub forum, so it gets the attention of all the AP experts there.

1 Like

Sadly, neither am I. SocialHub is definitely the place to find AP-proficient developers who could answer @Smag0 's questions.

One way to learn more about the fundamentals of AP is to listen to 3 episodes of the LibreLounge podcast, which is co-hosted by Chris Webber, one of the people involved in drafting AP. The first one is here:

The other two can be found in this list (part 2 on 19 April 2019, and part 3 on 17 May 2019):

(I can currently only post 2 links per post in this forum)

1 Like

There is also a wiki post on SocialHub, crowdsourcing developer documentation: https://socialhub.activitypub.rocks/t/draft-guide-for-new-activitypub-implementers/479

Is the Help enough clear ?https://scenaristeur.github.io/agora/

1 Like

Another good project might be the aforementioned openEngiadina.

Would be very cool to see a combined AP / Solid app appearing on Fediverse Party in the near future :slight_smile:

@Smag0, a new helpful devtool for ActivityPub is in the works, evolving rapidly. Created by @dansup@mastodon.social of PixelFed fame:


See also: SocialHub announcement


Hello, there seems to be much discussion but I thought the interoperability between Solid and AP was a matter of:

  • accepting HTTP signatures on Solid’s part: if we want to use it in a webapp, it needs some work in the fetch API so that we can request that the client sign it with a certificat from the certificate store (it needs to be cross-origin), but we could already use it for scripts and it would work with AP servers;
  • checking that LDP notifications come from where they say they come: this is more difficult, but we could require it be authenticated if there is an authorship triple, and require that the sender be the author, or have the server automatically add authorship information in the posted resource and have the app check that there is only one author;
  • agree on the vocabulary

Did I miss something?

1 Like

Yes, that may be on the short term for interoperability when federating. ActivityPub spec does not prescribe auth/authz methods but suggests to use either HTTP Signatures or Linked Data Signatures (see here). I don’t know if any fediverse apps support LDS at the moment, but HTTP signatures were mostly chosen for practical reasons (like also WebFinger for Mentions).

That is why Solid joining the SocialCG is so potentially interesting, as there is spec-level talk about the future of AP/fediverse, and maybe further diversification can be avoided.

This is what I’m most interested in. In openEngiadina @pukkamustard is investigating a bunch of ways to integrate Linked Data with AP. Ideally many, many vocabularies should be able to be adopted in various contexts. In AP it suggested to just ignore any message properties that are not understood.

Mechanisms for the support of all these vocabularies (e.g. modularity) and also any domain-specific extensions to AP message formats themselves are still to be further elaborated for the most part, AFAIK.

I don’t really like linked data signatures, because someone could take a private message and publicly publish it, and it would be proven that the sender sent this message. This would lead to a number of abuses that is currently not possible with HTTP signatures (or much more difficult). This is also why I dislike using append-only storage like IPFS.

1 Like