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.

Looking at my Solid Pod data in Solid Filemanager

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:

• Documents: Notes, Spreadsheets, Manuscript files, Presentations
• Media: Pictures, Video, Audio
• Data: Metadata in various formats

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.

The post ActivityPods: Federated Solid Pods appeared first on We Distribute.

There were some really cool demos at FediForum last month, but the one that really opened my eyes was Emissary. It’s a newer project developed by Ben Pate, and it does something totally new: composable interfaces.

spectra.video/videos/embed/73e…
Emissary FediForum demo
The secret sauce behind Emissary as a project is brilliant in its simplicity: it gives you a server and a bunch of tools, and gives you the power to build whatever interface you want on top of it. It’s very reminiscent of Hubzilla, but it makes customization a first-class citizen.

Deep Customization

There’s a lot of moving parts here, but it’s pretty easy to summarize: instead of simply giving you the power to customize how Emissary looks, you’re also given the power to customize how it works.
Examples from the FediForum demo. Left to right: a social reader view, a to-do list view, and a social profile view. All of these were developed using Emissary’s powerful templating system.
Emissary offers comprehensive documentation, and a bunch of different template types that can assist in building whatever app comes to mind. From the layout and widgets to the timelines and data types.

By following this method, is possible to turn Emissary into whatever platform you want. It uses a special JSON templating system, and the frontend processes everything with a toolkit based on HTMX. For developers, this means that you don’t need to write a frontend in a special custom framework – instead, Emissary uses the principles of HTML for development.

Contrary to other attempts to build this kind of thing in the past, Emissary lets developers write timelines and activity data as templates. Here’s how you can define a simple to-do list item:

Template Definitions

This part exists at the top of the template, and simply defines what it is, and provides some instructions for how it’s used by Emissary.
templateId:"test-todo-item"
templateRole:"todo-item"
socialRole:"Note"
model:"stream"
containedBy: ["todo"]
label:"To Do Item"
description:"A single item in a to-do list"
icon:"check-badge"

Schema

This part defines the actual fields of the object itself. Every single property is defined as a type, with additional fields nested in the actual data itself. Here, the data property includes dueDate and complete.
schema: {
type:"object"
properties: {
label: {type:"string", maxlength: 64}
summary: {type:"string", maxlength: 256}
data: {type:"object", properties: {
dueDate: {type:"string", format:"date"}
complete: {type:"boolean"}
}}
}

Actions

Here, the allowed actions are defined. Each action is built up of multiple steps, which are tasks that can be mixed and matched to make something happen. Let’s look through it.
actions: {
create: {
steps: [
{do:"as-modal", "steps": [
{do:"edit", "form": {
type:"layout-vertical"
label:"Add Task"
children: [
{type:"text", label:"Name", path:"label"}
{type:"textarea", label:"Details", path:"summary"}
{type:"text", label:"Due Date", path:"data.dueDate"}
]
}}
{do:"publish", outbox:true}
{do:"trigger-event", "event":"refreshPage"}
]}
]
}
view: {
steps:[
{do:"include", "action":"edit"}
]
}
edit: {
steps: [
{do:"as-modal", "steps": [
{
do:"edit"
form: {
type:"layout-vertical"
label:"Edit Task"
children: [
{type:"text", label:"Name", path:"label"}
{type:"textarea", label:"Details", path:"summary"}
{type:"text", label:"Due Date", path:"data.dueDate"}
{type:"toggle", path:"data.complete", options:{true-text:"Complete", false-text:"Not Complete"}}
]
}
options: ["delete: /{{.StreamID}}/delete"]
}
{do:"publish", outbox:true}
{do:"trigger-event", "event":"refreshPage"}
]}
]
}
delete: {
"steps": [
{do:"unpublish", outbox:true}
{do:"delete", "title":"Delete Task?"}
{do:"trigger-event", "event":"refreshPage"}
]
}

discuss: {
steps: [
{do:"as-modal", "steps": [
{do:"view-html"}
]}
]
}
}
The Create action adds a popup modal as a step, which then has the Name, Details, and dueDate values. After it’s filled out, the activity gets published to an outbox, which is the standard method for dispatching in ActivityPub. The page refreshes, and now it’s possible to edit or delete the item, or add a comment.

When we put it all together, we get something that defines what data is available, what actions are taken in processing that data, how it all looks, and what interactions are available to users. As someone who had messed around with PHP, Rails, and Node apps over the years, I cannot begin to tell you how wild this is.

Federated Music Demo

The latest demo Ben showcased is an attempt to create an alternative to Bandcamp. It’s called Arcadium, and is designed around letting artists customize the look and feel of their band pages. It includes support for streaming audio, links to other services, a custom home page, and events.

kumi.tube/videos/embed/bd1c321…

It’s an incredible example, and as of this writing, has a little over two weeks of active development time. The idea that this kind of thing is possible so quickly is nothing short of astonishing.

Ben continues to work on Arcadium, but is also seeking insight from Fediverse musicians looking for another Bandcamp alternative. Tapping into an existing community and building for their needs would be a great idea, as we’ve already seen Bonfire do with Open Science Network.

Who is this for?

It could be argued that Emissary is for power users and developers, but I think that’s only part of the picture. Emissary is based on IndieWeb principles, and a big motivation for the project involves giving people the power to shape their Web environment into whatever they want. It’s a powerful, intoxicating idea, and I can’t stop thinking about it.

I’m going to download Emissary and tinker with it. Should my efforts bear fruit, I hope to write some guides in the near future!

The post Emissary is Whatever You Want It To Be appeared first on We Distribute.