Avviso contenuto: There's an effort on the network to connect the Fediverse's federation powers to Solid's data storage and access capabilities.
The post ActivityPods: Federated Solid Pods appeared first on We Distribute.
https://wedistribute.org/2024/04/activitypods-fed
One of the Fediverse’s most-repeated selling points is the following premise: YOU OWN YOUR DATA. It’s a wonderful sentiment, the idea that you can pack up everything and take it with you. The problem is, most platforms on the network can, at best, redirect your followers to a new account.
What if we had an easier way to represent data ownership and give users total control of it? Buckle up, because we’re diving into some big ideas.
ActivityPods is a combination of two W3C standards: ActivityPub, and the Solid specification. The first standard is for data federation and networks, the second is for data storage and access. The ideals of both projects put together create a compelling vision: data control, across user applications, in service to communication across the web.
How does Solid work?
When I first came across Solid’s W3C spec many years ago, I really struggled to understand it. The document is full of extremely dry language, and was too intangible for me to understand at the time.
After messing with my own Solid pod and playing with some demos, though, something clicked for me. Here’s my best attempt to keep things simple.
What are Solid Pods?
In Solid’s world, everyone’s personal data lives in a Pod. This is your personal data locker, where your media, files, and personal data all live together. One Solid Pod belongs to one person.
Conceptually, your Solid Pod looks and works very similarly to Google Drive, iCloud, or Nextcloud: to the user, it just feels like a big folder with your stuff in it. In fact, using a Pod that way is not out of the question, but the technology serves a much bigger purpose.
User Data and Solid
Like I said earlier, data in a Solid pod can take a few different forms:
What’s interesting about this involves how Solid apps can work with these things. Instead of relying on a relational database like PostgreSQL or MySQL to store data, these apps read data straight from files in your pod. The data is specifically formatted in such a way that Solid apps can read it.
A recipe for Homemade Pizza in Umai, a cookbook app.
Noel De Martin made a really great demo app called Umai that demonstrates how a basic Solid App works. This app is relatively simple: look up a recipe online, copy and paste the URL, and save it to your pod. On the application side, your saved recipes show up right away. The cookbook folder. Metadata for the Pizza recipe. On the Solid pod, the data for each recipe resides in a folder, with a little bit of data for each entry. The application side knows to look for these, and is able to use that data natively. In a nutshell, all Solid apps store this kind of data in your Pod. The user gets to decide which apps, if any, can access that data, and can take away that access at any time.
So, that’s basically it. It’s a fancy data storage system that lets you connect documents and data with applications that can read or manipulate them, and you get the final say of which resources can be accessed by whom. ActivityPods then adds another layer: federation.
How does ActivityPods work?
ActivityPods extends the concept of a Solid Pod to include a few new things: an inbox, an outbox, methods for digitally signing posts, a SPARQL endpoint for querying RDF metadata, and a dispatch system.
Each pod has a singular WebID / Identity to begin with, and ActivityPods marries that WebID to a Fediverse Actor. A user then logs in to their social application through their Solid Pod, and grants permissions for the very first time.
Source: ActivityPods blog
What ActivityPods effectively provides are automated mechanisms. They constantly check the contents of the Solid pod, and are notified whenever a change gets made.
Let’s say you’ve just made a post with your Fediverse app: a document representing a post is written in the Pod, then a dispatch mechanism acts as the user’s outbox and sends the activity out. Meanwhile, the corresponding inbox mechanism waits for replies.
What this could mean in practice is that editing a Fediverse post may be as simple as editing a corresponding file, while a mechanism pushes out an Update activity through your Outbox to make changes on the network.
ActivityPods App Experience
So far, the app experience for ActivityPods is pretty limited: the mypod.store instance only allows users to use one of three apps: a meetup app, a mutual aid app, and Mastopod. Mastopod is basically a proof-of-concept app capable of rendering a basic timeline, dispatching posts, liking statuses, and following people. What’s remarkable is that it was hacked together in less than a week with the existing framework that ActivityPods apps use, SemApps.
The Future?
The developers behind ActivityPods are hard at work on their 2.0 release, and a big part of the work involves making this new platform fit into ActivityPub’s world. The goal is to provide everything a developer needs to build a Fediverse app, with the backend doing all the heavy lifting.
It’s an exciting time, and we may soon start seeing apps that bring entirely new experiences on top of this technology: apps that respect user privacy, and give them total control of everything in their Pods.
One of the Fediverse’s most-repeated selling points is the following premise: YOU OWN YOUR DATA. It’s a wonderful sentiment, the idea that you can pack up everything and take it with you. The problem is, most platforms on the network can, at best, redirect your followers to a new account.
What if we had an easier way to represent data ownership and give users total control of it? Buckle up, because we’re diving into some big ideas.
ActivityPods is a combination of two W3C standards: ActivityPub, and the Solid specification. The first standard is for data federation and networks, the second is for data storage and access. The ideals of both projects put together create a compelling vision: data control, across user applications, in service to communication across the web.
How does Solid work?
When I first came across Solid’s W3C spec many years ago, I really struggled to understand it. The document is full of extremely dry language, and was too intangible for me to understand at the time.
After messing with my own Solid pod and playing with some demos, though, something clicked for me. Here’s my best attempt to keep things simple.
What are Solid Pods?
In Solid’s world, everyone’s personal data lives in a Pod. This is your personal data locker, where your media, files, and personal data all live together. One Solid Pod belongs to one person.
Conceptually, your Solid Pod looks and works very similarly to Google Drive, iCloud, or Nextcloud: to the user, it just feels like a big folder with your stuff in it. In fact, using a Pod that way is not out of the question, but the technology serves a much bigger purpose.
User Data and Solid
Like I said earlier, data in a Solid pod can take a few different forms:
What’s interesting about this involves how Solid apps can work with these things. Instead of relying on a relational database like PostgreSQL or MySQL to store data, these apps read data straight from files in your pod. The data is specifically formatted in such a way that Solid apps can read it.
A recipe for Homemade Pizza in Umai, a cookbook app.
Noel De Martin made a really great demo app called Umai that demonstrates how a basic Solid App works. This app is relatively simple: look up a recipe online, copy and paste the URL, and save it to your pod. On the application side, your saved recipes show up right away. The cookbook folder.Metadata for the Pizza recipe. On the Solid pod, the data for each recipe resides in a folder, with a little bit of data for each entry. The application side knows to look for these, and is able to use that data natively. In a nutshell, all Solid apps store this kind of data in your Pod. The user gets to decide which apps, if any, can access that data, and can take away that access at any time.
So, that’s basically it. It’s a fancy data storage system that lets you connect documents and data with applications that can read or manipulate them, and you get the final say of which resources can be accessed by whom. ActivityPods then adds another layer: federation.
How does ActivityPods work?
ActivityPods extends the concept of a Solid to bring in federation, which lets Solid Pods talk to each other. This isn’t just a Solid Pod with ActivityPub on top of it: the entire system marries the two concepts together, from the ground up.
The Pieces
The platform brings all of the standard pieces you would expect from an ActivityPub system: it has an inbox / outbox dispatching system, methods for digitally signing posts, support for collections, a way of parsing activities, and also support for the Client-to-Server portion of the ActivityPub spec. The ultimate goal here is to provide seamless compatibility with the Fediverse, along with the support for apps that leverage the C2S API.
The Solid side is equally robust: the project is striving for compliance with the Solid specs, and brings in support for RDF, the data format that Solid uses, along with LinkedData. Because of Solid’s architecture, ActivityPods transforms RDF data in your Pod to corresponding ActivityPub data for the Fediverse.
Understanding the Flow
Each pod has a singular WebID / Identity to begin with, and ActivityPods marries that WebID to a Fediverse Actor. A user then logs in to their social application through their Solid Pod, and grants permissions for the very first time.
Source: ActivityPods blog
What ActivityPods effectively provides are automated mechanisms. They constantly check the contents of the Solid pod, and are notified whenever an update happens. On the app side, this is all seamless, and works like any Fediverse app.
Let’s say you’ve just made a post: a document representing a post is written in the Pod, then a dispatch mechanism acts as the user’s outbox and sends the activity out. Meanwhile, the corresponding inbox mechanism waits for replies, and notifies you when one comes in.
On the Pod backend, all of your posts are RDF data that sits in secure storage. A SPARQL endpoint effectively turns that into a database, and your app is able to use that for posting, search, and everything you’ve come to expect from a standard social platform.
ActivityPods App Experience
So far, the app experience for ActivityPods is pretty limited: the mypod.store instance only allows users to use one of three apps: a meetup app, a mutual aid app, and Mastopod. Mastopod is basically a proof-of-concept app capable of rendering a basic timeline, dispatching posts, liking statuses, and following people. What’s remarkable is that it was hacked together in less than a week with the existing framework that ActivityPods apps use, SemApps.
Even with a limited app right now, though, this feels like a huge breakthrough. MastoPods totally works, and you don’t have to even think about your Solid Pod.
The Future?
The developers behind ActivityPods are hard at work on their 2.0 release, and a big part of the work involves making this new platform fit into ActivityPub’s world. The goal is to provide everything a developer needs to build a Fediverse app, with the backend doing all the heavy lifting.
It’s an exciting time, and we may soon start seeing apps that bring entirely new experiences on top of this technology: apps that respect user privacy, and give them total control of everything in their Pods.
