Which links between ActivityPub and Solid project?

Community
#4

Hi Alice!

I really think the ActivityPub and Solid projects are very complementary and we should work together.

Yes! I agree completely.

Is there anyone in the ActivityPub community following Solid or interested in doing so?

I am! I am also working on an ActivityPub server that implements a Linked Data Platform: https://gitlab.com/openengiadina/cpub

There is another project working on similar ideas: https://www.virtual-assembly.org/semapps/ (cc @srosset81).

I agree that the Solid specifications are very much work in progress. There is however the Linked Data Platform specification that is released: https://www.w3.org/TR/ldp/. The Solid specifications are extensions to this.

As an interesting note. ActivityPub uses LDP. The inbox property is the same as the LDP inbox. From the ActivityStreams JSON-LD context:

    "inbox": {
      "@id": "ldp:inbox",
      "@type": "@id"
    },

Linked Data can seem scary and it has become complicated by the years of academization, but the core ideas are pretty simple and neat. I think it is a very good data model for decentralized systems.

Shameless plug: I wrote an small introduction to Linked Data and the Semantic Web which I hope would make the whole topic a bit more approachable: https://inqlab.net/2019-11-19-a-primer-on-the-semantic-web-and-linked-data.html

6 Likes
#5

@pukkamustard made a presentation at the first APConf in Prague about ActivityPub and Linked Data:

1 Like
#6

Cool discussion.

Funny, to me there is no real difference in nature between Solid and ActivityPub. I’ll have to read the ActivityPub spec again to be more assertive in this conversation, but I believe ActivityPub is actually a subset on Solid, both based on Linked Data Platform.

It feels to me Solid tries to standardize any kind of web interaction, whereas ActivityPub basically standardizes Twitter (I hope I’m not insulting anyone here, I love ActivityPub).

Both initiatives aims to break free from data silos and feel very much compatible with one another to me. I’ll read the specs again this weekend to make sure I’m not saying something totally wrong.

#7

[2020-02-25 12:01:01+0000] Alex Bourlier via SocialHub:

Funny, to me there is no real difference in nature between Solid and ActivityPub. I’ll have to read the ActivityPub spec again to be more assertive in this conversation, but I believe ActivityPub is actually a subset on Solid, both based on Linked Data Platform.

Yeah, there is some theory/spec vs. practice/implementations there.

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.

One of the main reason was that there is a lack of good (secure and failsafe) backend librairies for JSON-LD, if there was even one in the first place (when pleroma started there was none for Elixir). One issue which was quite ironic for decentralised software was that if the W3C would go down, Mastodon would loose federation, which is something that pleroma avoided in it’s own data by having the namespace registrations stored on the instance rather than on the namespace’s domain itself.

1 Like
#8

I think you are right that ActivityPub functionality is a subset of what the intended functionality of Solid is.

But I feel the emphasis of Solid is to be used as a WebDAV/NextCloud replacement. You store your data on your own Pod and can give fine-grained access to other people.

ActivityPub is more like Email for structured data. You send data and objects to recipients, but there is no (real) notion of storing and organizing data for yourself.

Solid can do ActivityPub pushing of data with Linked Data Notifications (https://www.w3.org/TR/ldn/). And as I understand, Linked Data Platform should be able to receive ActivityPub messages (https://www.w3.org/TR/social-web-protocols/#how-do-the-specs-relate-to-each-other).

These are very good arguments against JSON-LD. Maybe to recap:

  1. JSON-LD is unbelievably complicated. Try implementing the processing algorithms. This enormous complexity is the reason why there are hardly any complete implementations to work with it.
  2. Reliance on external contexts. To completely understand a JSON-LD document you need to expand it by using the context defined in the document. The context may be a remote document. So you have to rely on external things to understand your JSON-LD document.

Side note: There has been some work towards finding a subset of JSON-LD that solves these problems (https://stephank.nl/p/2018-10-20-a-proposal-for-standardising-a-subset-of-json-ld.html).

Still, I think it would be a shame to throw out all of the ideas and visions of the Semantic Web because of JSON-LD.

That’s my feeling as well. I think it is very worthwhile to understand what both initiatives are trying to do and how they are going about it. Learn from both. Mix and match the ideas.

1 Like
#9

Very interesting. I had never thought of that… :slight_smile:
Thank you for sharing that idea. I like it.
I wonder how we can build a decentralized web without relying on centralized ontologies. I’ll ask around…

I agree, but it is very much Inrupt’s vision, or Tim Berners-Lee’s vision of the topic, which I love, but is science fiction today IMHO. I realize that I didn’t create much, and he created the web, so maybe I just lack vision and Solid is what you’ve just said it was : some fancy NextCloud.
My conviction though is that there is an intermediary step to it where Solid is actually a way to standardizing the APIs. Having done that allows any Solid compatible app to connect to any Solid compatible server. In theory, we can federate anything then, any kind of app : a chat, a Q&A, a directory of profile, a car sharing booking, you name it.
I think the POD version of Solid is futuristic, inspiring, but not happening in the next 5 years whereas we already put federated apps based on Solid in production today, responding to concrete needs some companies have to bridge their IT together, to collaborate more easily with other companies for instance.

This conversation is a gold mine. Thank you so much.

Amen to that

1 Like
#10

FYI I created a topic on Solid forum mentioning this thread (and Fediverse was discussed before)

2 Likes
Discourse Invented Spaghetti Forums!
#11

I think content addressing might be a way to go. I.e. address an object (or ontology) by the hash of its content. One could use a special URN namespace (https://tools.ietf.org/html/draft-thiemann-hash-urn-01) so that the URI would be something like urn:hash:abcdefffabcdeabf.

The problem is how to normalize data in a sensible way that it can be hashed consistently. InfoCentral is an interesting project working on this and related issues.

1 Like
#12

Thanks! I’ll dig into it.

#13

[2020-02-25 14:37:45+0000] pukkamustard via SocialHub:

These are very good arguments against JSON-LD. Maybe to recap:

  1. JSON-LD is unbelievably complicated. Try implementing the processing algorithms. This enormous complexity is the reason why there are hardly any complete implementations to work with it.
  2. Reliance on external contexts. To completely understand a JSON-LD document you need to expand it by using the context defined in the document. The context may be a remote document. So you have to rely on external things to understand your JSON-LD document.

Side note: There has been some work towards finding a subset of JSON-LD that solves these problems (https://stephank.nl/p/2018-10-20-a-proposal-for-standardising-a-subset-of-json-ld.html).

Still, I think it would be a shame to throw out all of the ideas and visions of the Semantic Web because of JSON-LD.

Well, JSON-LD to me feels like trying to fit some properties of XML into JSON (which is already a huge warning flag to me), and we lost some important ones like the ability to have a fallback when the namespace is unknown. (some data is important, it’s better if you understand the semantics but otherwise it’s better to still be able to render it.)
Meanwhile XML implementations have been there for ages and they are well-known, so it’s pretty much battle-tested and there is multiple audits of them. Sure, it might not be shiny and new but to me it would be better than something which is quite too young and still feels like a hack after working next to it for 2 years.

#14

I understand that feeling. But I think it is more like trying to fit some properties of RDF into JSON.

Important to understand that RDF (Ressource Description Framework - a data model for Linked Data) is not attached to a single serialization format. JSON-LD can be seen as a serialization of RDF. As can RDF/XML - the attempt to fit RDF into XML.

There used to be a website with quotes from people working in Semantic Web on why RDF/XML is so horrible. I reuploaded the site here. I think we could replace pretty much everything said about in XML on that site with JSON and JSON-LD.

For example:

I like to say that there are two categories of people who don’t like RDF/XML: RDF people and XML people.

Would become:

I like to say that there are two categories of people who don’t like JSON-LD: RDF people and JSON people.

I believe that we need data interoperability beyond Pleroma and Mastodon, beyond services for Microblogging and posting Videos. We want to be able to interact with much more complicated and diverse sets of data. We want to be able to use the data of public transport stops, of academic publications and version control systems. We want to be able to interact with such datasets and datasets that haven’t even been conceived yet and discuss them on our social networks, curate them and extend them via social interactions.

It might be possible to find consensus for how to describe things for a restricted set of use-cases (such as Microblogging) and create interoperability between them by agreeing on some types of data. To make the data understandable beyond the initially intended audience we need to encode the meaning of the data into the data itself. And that is something RDF tries to do. And that is why I think it is important not to throw out all the visions and ideas of Linked Data just because JSON-LD is not so nice.

I very much welcome the idea of using something else than JSON. But I don’t think going back and using XML is the right way. There must be something simple to use instead of using something that is complicated but at least well tested.

Maybe, we should have a look at what Solid project is using: Turtle.

An ActivityPub Activity may be encoded in Turtle as such:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix as: <https://www.w3.org/ns/activitystreams#> .

<http://localhost:4000/activities/bc014788-a99a-456a-a6a9-aa23e56cbef0>
    a as:Create ;
    as:actor <http://localhost:4000/users/alice> ;
    as:object <http://localhost:4000/objects/428128f5-1bb5-475f-8de8-bac8e1736925> ;
    as:published "2020-02-21T19:39:32"^^xsd:dateTime ;
    as:to <http://localhost:4000/users/bob> .

<http://localhost:4000/objects/428128f5-1bb5-475f-8de8-bac8e1736925>
    a as:Note ;
    as:content "Guten Tag!"@de, "Good day!"@en, "Grüezi"@gsw, "Bun di!"@roh .

It’s not JSON and it does require a slight mind shift to parse this. But it is way simpler than JSON or XML. Parsers and sterilizers exist for most languages and if not it can be implemented quite easily (compared to JSON-LD).

Plus it has nice things like encoding of the type (^^xsd:dateTime) and in-built support for language tags.

2 Likes
#15

Sounds like the path forward is something like:

Given: an RDF based ontology (ActivityStreams) and a linked-data-sharing protocol (ActivityPub) lets us build a data graph that is federated between machines…

1) Enable the ActivityPub community to adopt ontologies beyond ActivityStreams
Develop a technical process and the community culture that allows extending ActivityStreams in a meaningful way to the ActivityPub community, so existing applications can adopt (like Pleroma Article typed) or ignore (like Mastodon’s rich text) them. Right now, it is ad-hoc custom additions that are not readily discoverable and leads to broken cross-app experiences with no culture for recourse.

This means each application is only providing a “limited view” into the whole federated graph and cannot hope to render every RDF type to a user.

2) Shift towards adopting the C2S model
This aligns with a “pod” idea: each person at home has a big dumb S2S brick to simply federated and uses C2S native or web apps to actually manipulate the graph.

Now! Having said all that…

Do I think Solid will actually, fundamentally, change the nature of the web? No.

Instead of semantically meaningful markup (HTML) shared federatively (via HTTP) with links to other markup (literally, links) amongst a connected group of nodes (web servers today), we have semantically meaningful markup (JSON-LD) shared federatively (via ActivityPub) with links to other markup (the LD in JSON-LD) amongst a connected group of nodes (Fediverse servers) but now with someone telling you how to design and build your app: having data at your home.

I’m not convinced corporations will listen: it fundamentally is competing alongside offerings by corporations that show how easy it is to build apps on their platform. It will take some kind of force (populism, regulation, economic) to truly make a difference – but it won’t be because of the technology.

I know we no longer have a loud voice in our community caring about security and privacy, and I don’t have it in me to be that person. So I’ll just say that the vaporic pitch of Solid means there’s nothing materially there to assuage my fear that Solid simply isn’t ambitious enough to fundamentally change the privacy/security concerns of today’s internet.

Instead, I would rather efforts include the decentralized and distributed nature of linked data - and I do mean including solutions like “someone else has my data (but they can’t ever read it or know what it is)”, which is already at odds with Solid’s pitch. Prematurely excluding solutions that are OCAP and decentralized+distributed is a mistake, one I’m happy to be in a minority complaining about.

Don’t let me stop y’all from progress, and thanks for hearing my objection. (Typed on a phone, which autocorrects to create a lot of grammar errors, sorry)

2 Likes
#16

How does @cwebber 's work on Datashards fit into any potential overlaps between AP and Solid?

1 Like
#17

It is “emacsen” + “cwebber” 's work and it would be more an alternative I guess.
Author of datashardsJS here

I doubt that SOLID would support the secure architecture and e.g. would support the reassembling of the 32 kilobytes shards …
Currently Serge refines the datashards specification and next time talk to emacsen I’ll make him aware of this question.

#18

A little bit of a tangent from the main topic of this thread (AP and Solid), but …

Isn’t that what we’re working towards by moving this forum under the umbrella of activitypub.rocks? Totally agree that something akin to the XMPP community’s XEP process is needed.

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
#19

hi @strypey @aschrijver don’t know if this could help but here is my experience as Solid dev dealing with some activitypub vocab https://forum.solidproject.org/t/discussion-solid-vs-activitypub/2685/7?u=smag0 . (Could not post here as i’m new and can’t post more than 2 links)

1 Like
#20

There are also

https://scenaristeur.github.io/agora/

and

2 Likes
#21

More on my Agora app https://forum.solidproject.org/t/discussion-solid-vs-activitypub/2685/32

#22

Hi All

Solid developer here. @aschrijver directed me to this thread. So perhaps I can offer some help.

First of all, there are some very valid criticisms raised. I do share some of those concerns, but I’d like try to be largely constructive in this initial response and stay on topic and explore some of the common ground.

Solid is predicated on the notion that your profile page is your identity. Your profile page contains a bunch of data such as your name, your friends, your inbox and outbox, and also your public key. With your public key, you are able to log into any number of servers (these days are called Pods = Personal Online Data Storage) and it gives you a WebDAV interface on those files. Solid then adds a layer of access control on top of that WebDAV store.

So to share your identity with someone, more or less you share the profile URL. That’s it. To expose a file in your Pod you just share that URL etc.

Two things are slightly different but I would support more alignment.

  1. Data is stored AT THE URL in Solid, so the discovery process does not have the extra step of webfinger or link following etc.

  2. The formats solid support are a range of Linked Data formats such as, Turtle, JSON-LD (which is a bit buggy unfortunately) and others.

So given that. How can the two projects interact? I personally like to build things incrementally. So I would start with SSO and Identity. Because that seems to me to be the tool that other things are built on.

One thing that could be nice would be for AP users that opt in, to be able to log in to any solid pod, use any solid app, such as a chat app or a shared nodepad (yes, these things exist, and were built by timbl) and use your AP profile to do so.

What would that require?

  1. Allowing AP users to use their profile page as an identity.

  2. Adding some markup to that page to make it machine readable

IMHO the easiest and more sensible way to do this would be to reuse the technologies that AP are already using. Namely JSON-LD and the publicKeyPEM key (aka predicate)

What I would favour is the “data island” approach that is popular with SEO folks.

Add a script tag in the head with:

<script type="application/json+ld">
... profile info here ...
</script>

I dont think it would be all that hard to do.

A solid server would need to understand how to parse that and eventually log you in, which would mean adding a patch to one or more servers.

Nice thing is that it could be opt in to start with, and have people play around. If it catches on, perhaps the patches can go upstream etc.

Hope that gives some food for thought on how the two projects could, possibly, maybe, interact!

2 Likes
SocialCG Meeting
#23

Thank you, @melvincarvalho! I find this very informative.