Cross-server Interactions in ActivityPub
General Discussion
9
Posts
7
Posters
0
Views
-
Cross-server Interactions in ActivityPub
So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!
ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.
We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:
Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.
Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.
This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.
This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.
-
Cross-server Interactions in ActivityPub
So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!
ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.
We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:
Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.
Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.
This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.
This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.
-
Cross-server Interactions in ActivityPub
So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!
ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.
We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:
Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.
Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.
This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.
This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.
-
@evan @evanprodromou Thanks Evan, it sounds compelling and I look forward to reading more! Re “It makes your own ActivityPub server your real home on the Web” -> is the idea that you would host your own AP server (e.g. for me it could be at ricmac.org), or do you think managed services will emerge that offer this as a service? Or is it something you can do with your Mastodon account potentially?
-
@evan @evanprodromou Thanks Evan, it sounds compelling and I look forward to reading more! Re “It makes your own ActivityPub server your real home on the Web” -> is the idea that you would host your own AP server (e.g. for me it could be at ricmac.org), or do you think managed services will emerge that offer this as a service? Or is it something you can do with your Mastodon account potentially?
@ricmac
ActivityPub servers capable of hosting your identity at a domain of your choice, rather than the servers' own domain, are going to be a thing. Mastodon today doesn't do that. One of the few that does is @takahe - but it'll become more common for a general purpose "social" server.And then there are going to be the special purpose apps, which will also speak ActivityPub - in their domains, or yours, depending on their ops model.
@evan @evanprodromou -
@ricmac
ActivityPub servers capable of hosting your identity at a domain of your choice, rather than the servers' own domain, are going to be a thing. Mastodon today doesn't do that. One of the few that does is @takahe - but it'll become more common for a general purpose "social" server.And then there are going to be the special purpose apps, which will also speak ActivityPub - in their domains, or yours, depending on their ops model.
@evan @evanprodromou@osma @ricmac @takahe @evan @evanprodromou i'd add that @gotosocial is a really good option for own-domain activitypub server, too.
-
@ricmac
ActivityPub servers capable of hosting your identity at a domain of your choice, rather than the servers' own domain, are going to be a thing. Mastodon today doesn't do that. One of the few that does is @takahe - but it'll become more common for a general purpose "social" server.And then there are going to be the special purpose apps, which will also speak ActivityPub - in their domains, or yours, depending on their ops model.
@evan @evanprodromou@osma @takahe @evan @evanprodromou
Osma, just to note that @evanprodromou replied to you and I on his blog: https://evanp.me/2024/04/22/cross-server-interactions-in-activitypub/#comment-942 (and the fact those comments didn't flow through to Mastodon shows some of the practical issues we're dealing with!)
-
@osma @ricmac @takahe @evan @evanprodromou @gotosocial huh, interesting idea...my assumption was that takahe maintained a separate "federated timeline" for each domain it was configured with.
-
Cross-server Interactions in ActivityPub
So, Richard McManus asked me about how ActivityPub supports cross-server usage. As an example use case, let’s say a user with the account eric@social.example wants to comment on a photo by dionne@photos.example. In this scenario, Eric would go to the page https://photos.example/users/dionne/photos/1 and enter a comment. How would that work? I can talk about how it would work using the ActivityPub API. But I’m going to have to explain a lot about the API first!
ActivityPub’s API is how client applications interact with the data on a user’s main account server. It lets the user read data on the same or other servers, and it lets them create activities and other kinds of objects on that server that get shared (under the user’s control) with the rest of the world.
We can all kind of imagine this working for the general-purpose social apps we use — things like an Android social app. But what if we think about more special-purpose apps — applications that provide particular functionality not found in most general-purpose social clients? Let’s consider an ActivityPub enabled photo-editing tool that lets you change lighting, add cartoon characters, change your appearance, or other modifications that are often seen in “filters” on Instagram or Snap:
Two neat things to note: first, yes, there are control mechanisms so that remote apps can’t do just anything they want behind your back; you get control. The other thing that’s neat is that because ActivityPub is very extensible, you can have all kinds of cool apps interacting with your ActivityPub account. Games, dating, ecommerce, all kinds of stuff.
Now, what does all this have to do with cross-server interactions? Here’s the idea: when a user from social.example is browsing the web site for photos.example and wants to interact with the people or the photos, they log in and treat that remote server as if it was an ActivityPub client. Then, the ActivityPub server reports the activities back to the remote server using the ActivityPub federation protocol.
This is actually a good model that works fairly well. It makes your own ActivityPub server your real home on the social web, where all your activities go through. It’s still in development and unfolding in the ActivityPub world — not everyone supports the ActivityPub API fully, so it’s hard to see these benefits today.
This is a topic I cover in my book ActivityPub: Programming for the Social Web, so if you’re interested in more detail, please check out the book.
@evanprodromou I wish we'd also had a url handle to deal with everything. like web+ap:// but supported by everyone and used for everything, not just links.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@benpate @maikel IMO, the "shipping stuff is hard", while true, isn't the issue. If you had created Emissary 8 years ago and stopped updating it after the first release (even with massive user feedback about UX and technical issues), your project would either be dead or massively forked (if there was enough interest). Even if you had a small release to fix a few serious bugs after eight years, that wouldn't be sufficient. If it weren't for Mastodon, AP would effectively be a dead protocol.
-
@maikel@vmst.io not surprising in the slightest considering ChatGPT is trained on public discourse, and most AP development discussions involve how much Mastodon fails at x y and z. Being the big fish means everybody takes pot shots at you.
So it's just a reflection of the training data. Us.
@benpate@mastodon.social you're just feeding the AI machine! 😱
-
@mat talk of purity can only make all other platforms connect better among themselves. Yet every time someone implements Activity Pub the first burden they find is "ooops, this gives an error from Mastodon side".
Standards exist for this very reason.
I agree with you with meeting in the middle, but Msatodon has been up since 2016, Activity Pub since 2018, we're on 2026. Mastodon migrated in late 2017 early 2018 before the spec was even fully ratified. It's been more than 8 years.
If at-the-very-least it didn't have the "huge undocumented behaviours", it wouldn't be stalling all other AP implementers.
-
@benpate @maikel That doesn't sound right. Mastodon came first, ActivityPub came later. Surely that's enough of an explanation? AP was a retro-fit to an existing social media site. Of course it was a bodge job.
To me, that's the true purpose of AP. It works best for connecting existing communities. We should reject the idea of tearing apart and rebuilding what exists today. Instead we should grow the network by meeting people where they are. Talk of "purity" can only be destructive.
-
@maikel I also wish Mastodon followed the specs closer.
At the risk of sounding like an apologist, real-world constraints and deadlines were probably a factor. Shipping stuff is *hard* and there are always difficult tradeoffs to be made.
C2S API is a good example. They NEEDED a mobile client, but the standard wasn’t enough.
However we got here, it’s on the standards community to build a spec that will work in the real world, then make incentives for the market leader to follow.
-
JESUS when even the stochastic parrot throws shade at Msatodon implementation of Activity Pub.
I'm honestly starting to wonder what is the point of people putting years in creating a standard if the main platform using such standard is spitting on it.
-
Tor: here is a list https://fedilist.com/instance?q=&ip=&software=®istrations=&onion=only
I2P: http://mastodon.i2p is currently online
Yggdrasil: there was a few, but I can't find them now
-
Are there #activitypub networks inside non-clearnet networks
