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.
@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
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): 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.
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: 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.
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.
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.
Did not find AP mentioned in XR3ngine repo yet, so will wait to add. Very cool project, btw! I assume you are aware of Immers Space already?
In terms of advocacy I’ve spent a lot of time to get Solid and AP communities more aware of each other, with some limited success. The complementary nature of both has great untapped potential. Here at SocialHub the #fediversity:fediverse-futures ideation space is for posting ideas that would require to focus more on the Linked Data aspects of AS/AP and beyond the Microblogging domain. I invite you to use this space to brainstorm for both projects.
You might help bring Solid / AP closer together, by deliberately cross-reffing topics and/or crossposting. See the post above for some of my effort to make Solid community more active (there seems zero interest or time available from Inrupt for this, and tagged staff didn’t even respond).
Update: Life-server was already added to the watchlist by @strypey
@srosset81 just posted an exciting project: ActivityPods combines ActivityPub and Solid. I’ll cross-reference the corresponding topic on SocialHub community here:
Quite recently @djsf has been exploring a Solid and Mastodon integration, eventually arriving at the need to properly grok OIDC in order to progress further.
I’m also excited about the existence of ActivityPods, but I’ve yet to understand how it works with identity. The extent to which it wants to interoperate with OIDC is an open question.
In summary:
I want my root digital identity stored in a Solid pod.
I wanna log into all fediverse platforms via my Solid OAuth login.
In this Kitsune issue musing about minimal user agency, I’m trying to imagine how the fediverse model of identity could change if we relegate the fediverse instance to a second-order identity manager as opposed to first-order, primary identity manager.
Minimally owning ones content and contacts is just a matter of having these backed up in a third party storage (like Noosphere or Solid), right?
Powered by the likes of Rauthy for full-fledged OIDC capabilities, Solid could be that primary.
Here’s an approximation of what I’d like:
I’m running Rauthy on erlend.sh (actually hosted at id.erlend.sh or whatever) as my primary identity manager.
I sign up for joinkitsune.org to start microblogging.
I authenticate with my erlend.sh domain via IndieAuth. (Neither Mastodon nor Kitsune supports this yet, but it’s just an extension of OAuth.)
I start posting on a custom apub.erlend.sh domain.
All of my actions on the joinkitsune.org server/pipes are mediated through erlend.sh as the authorizer of each action.
joinkitsune.org is a trusted keeper of my follows and other meta-data, but I have my own copy in something like a rauthy-activitypub extension. This extension will also notify me if Kitsune has quietly removed some of my follow-connections as a result of defederation.
Should joinkitsune.org disappear in a puff of smoke one day, I can shift apub.erlend.sh to another Kitsune host (e.g. my own) without needing any kind of forwarding in place at joinkitsune.org .
The persistent granting of access might depend on DPoP:
The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token. This constrains the legitimate sender of the token to only the party with access to the private key and gives the server receiving the token added assurances that the sender is legitimately authorized to use it.
That, along with storage of data such as contacts, is what Solid is made for.
This could be a big deal for Solid. As a protocol it has struggled to find its footing in a mainstream use case. Unlike apub and Matrix, Solid doesn’t yet have a flagship use case. Nomadic Digital Identity (and just that, to start with) compatible with the fediverse could be it.
