The ActivityPub Panel

including Jessica Tallon, Amy Guy, Evan Prodromou, and Erin Shepherd
moderated by Christine Lemmer-Webber (@cwebber)

ActivityPub is now a widely adopted standard
… but how did it become a standard in the first place?

Hear about the process of getting ActivityPub all the way to W3C Recommendation status from the people who made it happen, as well as the history that lead to the decision to try and make ActivityPub a standard in the first place! This will be a panel of editors and authors of the ActivityPub protocol.

Questions & Answers available!

Q&A Session – Opening Keynote: The ActivityPub Panel
⬡ Hooray, the live Questions & Answers

4 Likes

Thank you for this opening keynote!

It’s a great moment to share and learn about the history behind the screens.

I was surprised about the passage about corporate memberships around ~21:15 that received no words of response. Yet I think it’s an important point: ActivityPub was made by the grassroots, was it not? This is the history of ActivityPub, and it shows in its main community of early adopters.

One other thing that becomes transparent is how much infighting there was going from a variety of different approaches to converge, get along, talk to each other, and finally come up with ActivityPub. But years of benevolent dialogue beat most – but not all – of it.

@cwebber briefly hinted at content-addressing – nudging @pukkamustard with the work on ERIS.

Finally my prime takeaway from this panel, that I deem very important: It may be time to focus on #activitypub:c2s, especially if we can make a single ID compose posts going to several server implementations (e.g., text goes to Mastodon, video to Peertube, image to PixelFed, sound to Funkwhale…) so that a completely different experience from proprietary platforms can arise. Chris concluded on a discussion he had with Evan regarding the “borrowed assumptions” from corporate platforms: indeed, free software is in a different position when it comes to its objectives, and some (or many) assumptions of surveillance capitalists simply do not match the requirements for freedom. I think it’s critical to think why we do things, and the ActivityPub community has been quite aware of this for a long time, e.g., with the demise of showing follower counts and other quantitative, addictive markers that do not participate in sociality but in keeping people separate from each other. Pursuing this self-awareness work may be key to continuous success of the Fediverse.


Hey @rhiaro and @cwebber: what’s up with the gloves? Do you both have carpal syndrome or is it some (C2S) secret society?

2 Likes

Very interesting discussion, thanks!

Several of you mentioned a desirable future where you could have one identity on a generic server that you use via many client apps that each do their specialized thing, which is a goal we share for #software:commonspub

My understanding is that a blocker to that has been the lack of adoption of AP C2S (with apps using more specialized APIs like Mastodon’s instead). We initially tried to address that in CommonsPub by structuring the database and AP library in a generic enough way so it can handle any types of activities and objects and by implementing a GraphQL API so that client apps would have very powerful and flexible capabilities to create custom features and experiences (without the complexity of implementing ActivityStreams or JSON-LD).

I think we made a breakthrough recently though, thanks to using LiveView which enables us to build realtime web apps in Elixir (a backend language) without any JavaScript or frameworks like React. With our new project Bonfire, what this means is that instead of client apps having to be something that runs in your browser or on your phone, the clients can be LiveView apps running on your device that’s plugged in at home next to your router, and the server hosting your identity is a generic AP-only service in the cloud which syncs with that device.

1 Like

Hey @rhiaro and @cwebber: what’s up with the gloves? Do you both have carpal syndrome or is it some (C2S) secret society?

I was struggling with RSI a few years ago and at a conference (maybe W3C TPAC?) @cwebber gave me those very gloves you see. They were Chris’s, so too big for my hands and not effective for the pressure needed, but the padding on the wrists makes long stretches of typing much more comfortable, and I remain grateful for them to this day :smile: One day I’ll get some that fit me properly…

1 Like

So that’s indeed a secret society of RSI victims :blush:

One thing that I think is key but maybe not obvious from the spec: The AP Client-to-Server API isn’t just aimed at mobile or desktop apps. That’s the obvious and straightforward use case, but not the only one.

What the C2S API gives you is delegation. It lets some other agent - which might be a mobile app, or might be a web app - act on your behalf. And, importantly, it gives those agents effectively equal power to the server itself has.

In the extreme, you could have a server which has no UI of its own - it only exposes ActivityStreams JSON. Maybe not the most user friendly, but permitted.

With the C2S spec you can build a PeerTube which acts as a true adjunct to your “primary” AP server - you upload videos to it, but they get posted to your main identity hosted elswhere. Thinking about things on-the-wire, you can envisage an entry in your outbox which might look like

{
    "id": "https://example.com/me/activity293048",
    "type": "Create",
    "actor": "https://example.com/me/",
    "object": {
        "id": "https://peertube.example.com/me/video/3",
        ...
    },
    ...
}

AP C2S allows an additional degree of federation and decentralisation. And it doesn’t involve e.g. PeerTube giving up features either - it can still give you a timeline and all of those sorts of things

Some of the difficulty comes from the world and mental models that exist. In the Q&A, Chris commented on the trouble he had convincing any of the existing social networks to come to the SocialWG, and commented on the interoperability troubles we might have had trying to bring the existing worlds (the “old guard” of federated social networks, almost) together.

In some ways, I think Mastodon is the “last of the old guard”. Mastodon’s data model isn’t (or wasn’t) ActivityStreams, and its’ worldview isn’t the same either. They’re building something which follows the same basica model as Twitter (With their own twist), and that’s fine, but it’s intentionally limited.

However, when that intentionally limited implementation is 90% of the population of your network, it can colour perceptions of it. ActivityPub can support things wildly different from Mastodon, but when people think ActivityPub they also think Mastodon-likes. Some of the functionality can cause interoperability issues also. However, just in terms of the major proprietary social networks, there shouldn’t be anything stopping you from building something in the model of Facebook or Google+, or any number of other designs on top of it. And in terms of something much older, you should totally be able to have an ActivityPub enabled blog and you should also be able to blend all of these things together into one cohesive whole.

Systems built since tend to target AP directly, and have data models which more directly correspond to AS2 and its functionality. It would be a lot easier for these to implement the AP C2S spec, and it would be a great world where things did.

(In case my comments above might be misinterpreted: I do think that Mastodon adopting AP is perhaps the best thing that has happened to the spec; without it, the AP fediverse would almost certainly be a lot smaller and less successful. So while I lament here some of the downsides of having Mastodon as the “de facto standard” AP implementation, I’m still thankful for it. If we’d have built the most elegant social networking protocol in the world but there had been nobody to talk to, it would have all been for naught)

3 Likes

A great post @erincandescent!

Love this!