Planning on federating via ActivityPub, reading about it and ActivityStreams, the protocols look pretty simple and elegant. What's your guys' take on and ?

the protocols look pretty simple and elegant

This is only first (and obviously wrong) impression. But you'll understand it later...
@nodetube you might want to check out #PeerTube, which your project could be compatible with!

@sean yeah I'm familiar with PeerTube. Actually based on my research I don't plan on doing ActivityPub for a while i'm not sold on it. Will focus on making a really great standalone instance when the dust is settled more on what decentralized protocol is going to make it I'll look into implementing it. I have a live instance up at if you want to contrast it with PeerTube

@mewmew @nodetube it's not a perfect protocol by any means. The biggest thing AP has going for it lies in its adoption. Currently, 8 major federated platforms support it, covering use-cases ranging from microblogging to music and photo sharing and more. As a network, it has about 3 million users, and most of the apps can interoperate in some way. For example, Mastodon can follow PeerTube, and Funkwhale (a music player) is working towards similar functionality so that the wider network can follow musicians.

There's room to grow, and the biggest challenge to tackle involves better privacy. That said, as a collaborative effort, we've gotten really far.
@sean @nodetube
> Funkwhale

I do agree that AP isn't perfect but I'd like to know what their specific concerns are.

@mewmew @sean


Here's a Reddit post I wrote with some of my ActivityPub concerns:

(Not quite the space to send it as a message here on Fosstodon sorry).

Interested in hearing your guys' response. Really I hope ActivityPub could be the thing that solves my question of how I'd like NodeTube instances to federate but at the moment I'm very skeptical as per the reasons in the Reddit post above.

@nodetube @sean ok, I can address this.

First, a lot of these issues are only in the implementation. For example, following an instance is definitely possible in ActivityPub, Mastodon simply does not have this supported.

The ugly redirect flow isn’t necessary either, you just search up their handle on your instance.

You can still use the protocol and have a more oAuth like flow for interactions - simply expose channels as Actor, videos as Video, audio as Audio, comments as Note, etc (and when someone follows a channel, send them Create Video, Like Video, Create Note etc).

As for your community concern, I think that’s more about the people who are interested in ActivityPub using ActivityPub, of course they’re not gonna be on Twitter - they’re here.

If you have further questions I can answer them.

@nodetube @sean for example, PeerTube allows instances to follow other instances so all of their videos federate to the instance. If you'd like an account on my instance for testing, I could make you one.

@mewmew @sean Okay you're definitely a great person to talk to in this regard. And yeah it's hard for me to decouple ActivityPub from Mastodon/PeerTube at times because there's not a lot of great documentation/tutorials I can find online so it's really like poking around with those apps and making assumptions in large part.

@mewmew @sean I have a PeerTube account that I've been doing some testing with. It was cool because I could look up another PeerTube account and then comment on the video from my identity which was awesome. But then when I actually went over to that instance I couldn't 'login' so the only way I could interact was through the redirect flow.

@nodetube @sean yeah... that's a bit of a harder thing to do, ideally you see the content on your own instance instead of having to login on the other one. I don't see how a well thought out redirect flow is any worse than oauth though, and it's a lot safer imo.

@mewmew @sean The oAuth flow is nice because it's one and done and you interact with that instance per your single identity. Trying to poke around another PeerTube instance and having to ridirect everytime you like, subscribe etc, it's maddening. Like trying to eat a taco with oven mits on or something lol. You'd just want to make your own account at that instance at that point, which means another password/email verification etc (ugh). Plus that doesn't scale. May as well just do normal auth

@nodetube @sean You could just as easily have it setup so an instance remembers where to redirect you to.

If you had your oAuth flow, you'd need to visit each instance you have subscriptions on to check your subscriptions. With the redirect flow, you only need to do that once, and if you find the account by browsing the timeline on your local instance, not even at all.

@mewmew @sean I mean, is it a limitation of ActivityPub the protocol or its implementation that disallows a "Login from another PeerTube instance" type functionality. If that could land then you have something that approximately 'one login for all instances' which is what I'm after. Even if you have to redirect to sign in (Like with 'login with your Stackexchange account') that would be perfect but I don't see that in the wild atm.

@nodetube @sean ActivityPub c2s allows that - the problem is for that method of login you need to give your keys to each instance.

@mewmew @sean Is it like a 'root key' which has all the privileges in one, or could you segment like oAuth so maybe the instance can comment/like on your behalf, but not post content or something along those lines? Like I would love to just read some authoritative textbook from Manning or something on ActivityPub so I can fully wrap my hands around it but it seems so new it's like everything just redirects to the W3C standard.

@mewmew @sean And then I went to go read the standard it was like "Oh it's based on Activity Streams 2.0" and I was like "okay cool", googled Activity Streams 2.0 and it was a veritable wasteland. Even on YouTube there's just the one video from 2014. Ideally there's like 5 tutorials so I can try a couple approaches and there's options if one doesn't work for me but everything is so new/undocumented it's a bit scary.

@mewmew @sean Even when I look up 'activitypub c2s' the top link is to this:

Which is a recent thread where people are having like a very philosophical conversation on whether Mastodon's API will end up becoming a de facto standard for ActivityPub lol. Very scary to think I have to tread through those waters to get my implementation up. That's why my take was to wait and let the dust settle a bit before choosing a decentralized protocol to implement.

@mewmew @sean Thanks a ton for your help btw really appreciate it

@nodetube @sean I think I'll just have to explain how ActivityPub works to you, gimme a bit of time, it's kinda complex.

@nodetube @sean (you should view this on my instance since doesn’t support Markdown formatting so it’ll look like a garbled mess on your instance)

there are a few things you need to understand to understand ActivityPub:

How ActivityPub servers actually implement the protocol (very different from the other three!)

so first, let’s start with ActivityStreams2. The general way this works is by having multiple types of Objects. An object can be anything, but there are three main categories: Object (catch-all category), Actor, and Activity. So while all Activities are Objects, not all Objects are Activities.

An example of an Activity is a Like. Another example is a Follow. Another example is a Create.

Here’s what a Pleroma (implementation of ActivityPub similar to Mastodon) Like looks like:

{ "cc":[ "", "" ], "id":"", "to":[ "", "" ], "type":"Like", "actor":"", "object":"", "context":"", "published":"2020-02-01T22:10:10.801412Z", "context_id":5619370 }

Let’s take a look at this. First, take a look at the “object” field. This is the ID of another Object (in this case, a Note). ActivityStreams2 uses JSON-LD, meaning that instead of having to embed the object, you can just put a URL for it instead.

Next, the “actor” field. This is the ID of the Actor (think: user) who did the activity (in this case, me).

The type is “Like” obviously.

“to” lists who the object is being sent to - in particular, it’s addressed to the actor, whose Note is being liked, and to the list of my followers: “cc” is for people who the object isn’t explicitly being sent to, but is visible to. is a URL to say “this is public”. Note: for normal posts, if that URL is part of the “to” field, then the post is listed on timelines, if it’s part of the “cc” field, it’s unlisted. However, this is not part of the spec and is instead how instances choose to implement it so you don’t need to implement things in a similar way.

Finally, “id” is the unique ID of the object. Every object, be it an actor, activity, note, etc, has a unique ID. If another object wanted to reference this object, it’d reference that ID instead of embedding the entire object.

Now, how do Actors work? Here’s an example of an actor (me):

{ "@context":[ "", "", { "@language":"und" } ], "attachment":[ { "name":"I set this using ", "type":"PropertyValue", "value":"Husky" }, { "name":"UwU?", "type":"PropertyValue", "value":"uwu" } ], "discoverable":false, "endpoints":{ "oauthAuthorizationEndpoint":"", "oauthRegistrationEndpoint":"", "oauthTokenEndpoint":"", "sharedInbox":"", "uploadMedia":"" }, "followers":"", "following":"", "icon":{ "type":"Image", "url":"" }, "id":"", "image":{ "type":"Image", "url":"" }, "inbox":"", "manuallyApprovesFollowers":false, "name":"Fridayblob :blobcat:", "outbox":"", "preferredUsername":"mewmew", "publicKey":{ "id":"", "owner":"", "publicKeyPem":"-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA38zn7CJV6qBMHrkealqC\n70l/WlSGcNC4PHx5HnOmw8cXqbmeFKkJuyXFiDsz8m2BwjeN/TEjeBsn/1LcQ5x1\nqvx5QQ+0XFvHuCXigjRhR7p54M1yPyxxiQF2BDe1dRMArfBh0ca48kvqzkzvfhrr\n5sFhXChy9+n8Y4FhAeZ39nTvmpkpEdZ/F/0PIjR5IdwrWKmJ510Tn0tBx5YWmQ7p\nj0K2mlVANJmLT/YiqCu25LX3D/UsEA69mWRDYNqj5EozyvAi1FA1SHisNWy8a6zg\nnoqk3/pQ5rU7A4upGCvASmParxAY54FZ05JeYee3FXzvwSmHG+zj6lMrirK1zI8T\nLQIDAQAB\n-----END PUBLIC KEY-----\n\n" }, "summary":"admin of <a href=\"\"></a> and, if you have any questions/concerns, or if you just wanna talk, dm me<br><br>please don&#39;t tag me in hellthreads though<br><br>if i&#39;m posting too much meta stuff please slap me or something don&#39;t just unfollow that makes me sad :blobcatglare: <br><br>mastodon alt: <span class=\"h-card\"><a data-user=\"9poBFzbtejsZg96wsa\" class=\"u-url mention\" href=\"\" rel=\"ugc\">@<span></span></a></span><br>private alt: <span class=\"h-card\"><a data-user=\"9phYcLTwGpaIFSikcK\" class=\"u-url mention\" href=\"\" rel=\"ugc\">@<span></span></a></span><br>xmpp account: (all local users here have it!)", "tag":[ { "icon":{ "type":"Image", "url":"" }, "name":":blobcatglare:", "type":"Emoji" }, { "icon":{ "type":"Image", "url":"" }, "name":":blobcat:", "type":"Emoji" } ], "type":"Person", "url":"" }

There’s a lot going on here. First, take a look at the “id”. This is and my id on this social network - I’ll explain how you get from that to @mewmew later.

“followers” and “following” are collections (a type of object) that list who I am following and who follows me.

“name” is what I have my nickname set to currently.

“type” is “Person” - there can also be automated actors such as relays (which is the way you’d follow an instance).

Most important: take a look at “inbox” (,"outbox” (, and under “endpoints”, “sharedInbox” ( These are the main way ActivityPub federation works. If you make a private post and want to send it to me, what you would do is POST it to my inbox, while signing the request with your key. You can see publicKeyPem listed in my profile - this is the key that all my posts are signed with, so if I send you a direct message, a message is POSTed to your inbox URL (probably, with an HTTP signature made using my private key (stored on server).

Now, this is inefficient for public posts - so for a post that’s public, you send it to the sharedInbox endpoint instead (so this post is only getting sent to, not to you individually).

Now, /outbox is another important endpoint. It allows you to iterate over an actor’s posts. Usually it only displays public ones, but if you sign your fetch with an HTTP signature, it’ll show all of the ones that that actor is allowed to access (so if you follow me and sign the request with your signature, you can load my followers-only posts). This is useful for backfilling posts to your instance when you first find an account for example.

NOW, for your intended functionality - what I would do is the following:

Allow oAuth for various scopes
On the remote instance, authenticate with oAuth
When you do something on the remote instance, send the object created back to your home instance to be federated out

(sorry if this didn’t make sense, kinda hard to explain it)

@mewmew @sean Awesome man thank you for this. I will have a good chance to dig into it and cross-reference it against some googling tomorrow. Highly appreciate it though I was hoping to run into someone who had a solid grasp of ActivityPub so they could point out where I was missing things, hopefully we can figure something out and have NodeTube in the Fediverse but also super-user friendly flow, that's the dream.

@nodetube @sean glad you came on here and reached out - it'd be awesome to have another video platform as part of the network! Feel free to ask me if you have more questions.
@nodetube @mewmew you might want to check out the SocialHub forum, it's run by the ActivityPub project and has a lot of contributors going through the semantics.

A few people that know a lot about the spec would probably be @lain @cwebber and perhaps @nightpool

@sean Thanks for the heads up I will definitely check that out!

@nodetube @sean yes please come make some posts about your project there. is exactly where alot of these discussions are happening.

Show more

@mewmew @sean Alright I had a chance to go over that today, and no don't worry it made perfect sense. So based on my flow where say I'm on but I'm already registered on, let's say there's a "Login with existing NodeTube account", where you enter the URL to your home instance and it redirects you there, at which point you login (or just accept the permissions if already logged in) and are redirected back to ..

@mewmew @sean

Theoretically you could post on, and have it show up with the credentials from your account, which is made possible by an oAuth scope which will allow you to do a PGP signature over HTTP , basically posting to . I guess I have to mete out in my mind where oAuth begins and ActivityPub ends, but does that flow I just laid out for you seem technically plausible in your opinion? Thx again much appreciated!

@nodetube @sean yes that is totally plausible! Basically the nodetube instances other than your home ones act as "clients" that authenticate for a limited set of actions over oauth (maybe something like, authenticate only for interactions with said instance).

@mewmew @sean I couldn't quite tell, it looked like but I'm not sure, is ActivityPub 'smart enough' to know about oAuth? Like is the capability to say "hey this is an instance which I want to be able to use my public key in certain regards but not in others", is that already baked in ActivityPub or would it have to built independently?

Show more
Sign in to participate in the conversation

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.