My friend Evan Henshaw-Plath wrote recently about some concerns with ActivityPub. I want to go over his concerns one by one and give some assessment of how accurate and important I think they are. Rabble’s words in italics; my responses in just normal text.
- User identities are tied to a server. This is only partially true; your user identity is tied to a domain, not a server. But most servers only handle one domain, and most people don’t move their domains between servers. We have a section on domain portability between servers on the ActivityPub Data Portability report.
Using domains is also how much of the Internet works. Email addresses are tied to a domain; Web sites are tied to a domain. You can move the domain between different implementations transparently. It’s a really robust architecture that has stood the test of time for almost 50 years. - Users can’t migrate between servers. Partially true. Rabble covers the essentials; you can move followers and not much else. It’s also possible to move your “stuff” between identities; that’s most of what our Data Portability task force is working on.
- On a single server, it is impossible to change your username! Somewhat true. ActivityPub identities are URLs like https://social.example/user/vtles1XgZkPUEulBsFmRX . That identity URL is immutable; you can’t change it. Some implementations include a username in that url, like https://other.example/user/evanp. With that kind of server software, it’s true, you can’t change the username.
Also, we use a standard called Webfinger that maps an identity string like username@domain to an URL. You can read about it in the ActivityPub Webfinger report. Some servers use that string, instead of the ActivityPub ID, as the unique ID for a remote user. That’s discouraged, but if someone does that, changing your user ID will make you no longer findable for those other servers. I think as we stabilize our use of WebFinger, some of these usages are going to get better. - Fediverse servers have total control over your account and data. True. This is the “federation” part of the fediverse. It’s how Web sites and email work. Don’t use a fediverse server without a good trust relationship with your server admin; ideally someone you have a business relationship with, or your employer, or your university. Same goes for email!
It also means that if you control your own server, you have total control over your account and data. That’s a feature, not a bug.
Another option is using a cooperative server, like cosocial.ca or social.coop. A cooperative is a legal structure in which members pay for and manage their own service. I think cooperatives are awesome. - The fediverse is a network of fiefdoms, each server admin having total control over their users. This seems about the same as the previous statement, but OK. I think the key strength of the fediverse here is that we can have dozens of different models for server governance — coops, enterprises, city libraries, family servers, individual servers. That level of experimentation is a feature, not a bug. Governance is not baked into the protocol.
- Each kind of fediverse server is isolated. This one is just plain wrong. ActivityPub is based on an open data standard called Activity Streams 2.0 (AS2) which models social data. There is an extensive standard vocabulary that can represent Web content like text, images, video and audio, and the social graph, but also well-known social interactions like check-ins, events, and groups. More importantly, Activity Streams 2.0 is extensible, meaning you can add properties to existing types, or whole new types of objects or interactions. And every ActivityPub server is built to handle AS2.
What is true is that we have had a lot of servers that only handle a subset of the AS2 vocabulary, and reject content they don’t know how to handle. This is mostly due to mimicking the siloed social networks; we’ve gotten used to thinking of different social networks for different kinds of content. I think this is changing, especially as new kinds of content hit the network. Developers are just learning how to effectively handle extension content with fallback representations. I look forward to this improving over time. - The fediverse has no privacy; there is no system of end-to-end encrypted messaging. The first part is false; you can mark your posts as followers-only, or directed to a single person, or a group of people. Servers enforce this privacy. You can also mark that you don’t want your public posts to be indexable or your public account to be discoverable.
However, the second part is true; we don’t have end-to-end encryption. So, if you send a private message to someone on another server, you message can be read by both your admin and their admin. It’s stored in the clear on both servers. This is also how email works, as well as most direct messages on commercial social networks. However, it’s something worth working on. I’ve sketched out an architecture for end-to-end encryption over ActivityPub, and I’ve got a proposal out to work on it for Summer of Protocols. I think it will be good to level this up! - The fediverse has no system for micropayments. This is true. The fediverse is also first and foremost for social networking — connecting to friends, family, colleagues and neighbours. Most of these interactions are not mediated by payment; in fact, payment cheapens those interactions.
However, there are other relationship types on the fediverse — supporting creators, journalists, or publishers. The main way to do this today is with paid subscriptions; for example, you can subscribe to evanplus@prodromou.pub to get access to premium content I publish. You have to send me US$5 out-of-band or I won’t approve the follow; that’s the state of play right now on the fediverse.
I think in-band payments are kind of cool for this kind of work, as well as for marketplaces — buying and selling services or goods over the fediverse. I think the easiest structure is adding payment URLs like a PayPal account, or blockchain wallets like a Bitcoin Lightning address. - Lastly, and most importantly for me, the culture of fediverse server admins and developers is vindictive. I don’t think this is the case; I love the culture of the fediverse, which is playful, conversational, and collaborative.
I think there are a plenty of good points in Rabble’s critique, but there’s one way that I think he’s extremely wrong. There is still a lot to do in the ActivityPub ecosystem, but we have the architecture and extension mechanisms to make them possible. It’s totally not required to go start a whole new social protocol to build those things in from scratch. In fact, it’s a real mistake; it’s far better to work from the existing standard and build on it. Open standards like ActivityPub have a legitimacy that ad hoc systems like Nostr can never have, and it’s the reason that there is so much interesting development going on in the ActivityPub world.
Evan Prodromou's Blog 
@evanprodromou for @ricmac and @rabble . Hopefully this clears up some of the misconceptions!
@evanprodromou nice post 🙂
@evanprodromou It’s great that you responded to this with some clarity. But I think there’s an underlying misunderstanding here.
A lot of these complaints center on “this is my content, I should be able to do whatever I want with it”. But there’s a publisher here too. The instance and their admin team.
You’re addressing some of the technical details, but the general theme of the complaints is simply a dislike of the publisher model… Possibly the existence of a publisher at all… /1
@evanprodromou
I can understand and empathize with wanting a different version of these things. But at some level, it’s starting to look like OP is asking for a different thing all together.
ActivityPub is very much a “point in time” publishing platform. And it has to have some basic agreements in terms of publishing standards.
If you don’t want another publisher to be in control, then you have to be your own publisher. 🤷♂️
And Mastodon enables that today for relatively cheap. //
@evanprodromou one starting assumption that I had was that because mastodon used webfinger for identity, it subsumed it to the webfinger resource, creating an opportunity it’s to separate these concerns and, for example, point a webfinger on my domain to an activitypub server run by someone else. That this doesn’t really work is disappointing; it’s very “big software” not internet “small piece loosely joined.”
That should work, AFAIK, but there’s not an easy way to point it back to your Webfinger. So if user1@domain1 links to an url like https://domain2/users/12345 with preferredUsername user2, most remote servers will build a Webfinger address like user2@domain2. We’ve got some work to do in reverse discovery; you should take a look at the ActivityPub Webfinger report. https://swicg.github.io/activitypub-webfinger/
@evanprodromou 1. I've found the culture of server admins is vindictive only if you're a persistent pain in the ass. Almost every case of admin vindictiveness I've seen has been justified, and even then the responses have been measured.2. If you don't trust your server admin with sensitive information, start your own server(*). I know a good number of people who have done this. If anything, the issue is making it easier for people with limited technical skills to set up an instance. /2
@evanprodromou * – If you're not running it on your own hardware off your own net connection, you're still trusting your data centre, so the point is essentially moot.
I agree #fediverse has a lot more to express, but unfortunately the most famous software is also the less elastic. For example "usernames fossilization" (point nr.3) is just a limit of one software, the most propagated. That software lacks of support for others while the others are trying to acknowledge it to avoid missing a 70% of people to talk to. Fediverse isn't just a matter of "let's drain people from X SNS or Y". It's a matter of dialogue between developers, decentralization is strong but cohesion is poor. That's probably why someone else have built other protocols more than #ActivityPub
@evanprodromou one thing that’s bugging me is that you can’t see all replies to a post from a remote server. Of course you can visit the original server, but having to do that everytime is pretty bad UX – not to mention that each server has a different UI which makes the experience even more confusing. When I open a post, I expect to be able to see the discussion under it, without leaving my platform/app. I think it’s one of the things that make fedi weird and confusing for a lot of people. I discussed this with two project lead devs lately and they both agree there’s no efficient way to do it, not all platforms use the same API, and even if you cover the most common APIs to fetch replies from a remote server, they feel that the extra load this would cause on the remote server is bad practice and would cause complaints. So we have to send users to the remote servers if they want to see all comments to a remote post – and if they want to reply to something, they might need to copy the URL to fetch it on their home server and reply from there. This is not how users expect public discourse to happen, and it seems unnecessarily complicated in practice. Wish there was a solution to that.
@evanprodromou to give a specific example why this can be not only annoying on a personal level but problematic for the fediverse as a whole, imagine when Threads (with its comparatively huge userbase) fully federates. People will see a post with x replies on their server, and then when they visit the post on threads.net it may have 10 times more replies. How many times will someone do that? Eventually some people will just choose to move to Threads and save themselves from the extra clicks and time wasted from this.
@evanprodromou another valid concern about the current design, raised by someone in firefish’ matrix room, is that they can’t see most replies to remote followers only posts. The replies are theoretically visible to the followers of the original poster, but if nobody on your server follows the people who reply, then their posts aren’t fetched and there is no way to find them, since you can’t see them in the remote server, since you are not logged in there. This is not how this should work, I should be able to see replies that are intended to be visible to the followers of the original poster, whom I follow.
This is one of the reasons I think that the fediverse, as it is today at least, is not ideal for social media replacement. It is great as a tool for online communities that can talk to each other, but it’s far from ideal as a somewhat unified public space. This is why I think Mastodon’s approach of a “federated Twitter” has built in limitations, and I think you can see that in its failure to really replace Twitter when people were looking for an alternative. Threads may succeed, but not because of federation.
If you are dedicated to making fedi succeed as “the public square of the internet”, there needs to be a solution for this. The current design for viewing discussions is deeply flawed.
I might have given the wrong impression that I was open to just answering questions about ActivityPub. This blog post is about a particular person’s issues, with replies.
For your question, the `replies` collection I mentioned before is correct. If you want to fetch any remote object with your own authorization, use the `proxyUrl` endpoint, defined in the AP standard. If that’s not available in your implementation, file a bug.
You’re incorrect about ActivityPub; it’s a great conversation and discussion medium.
@panos @evanprodromou I think following hashtags on mastodon is similar. If you follow a hashtag, you will see posts that are already federated, you cannot subscribe to hashtags from all instances. In practice, it is almost pointless to follow hashtags if you are on a very small instance
Every note, article, image, video or audio on the fediverse has a ‘replies’ property which is a collection of all the replies that have been made anywhere on the fediverse. It’s a major bummer that these aren’t shown in a lot of UIs.
Hi Evan, I tried to add replies to a new site I built at utoots.com but it was a major PITA to say the least. Maybe there is a better way than what the ActivityPub API allows because I just cant figure out how to make it work!
@evanprodromou one thing that’s bugging me is that you can’t see all replies to a post from a remote server. Of course you can visit the original server, but having to do that everytime is pretty bad UX – not to mention that each server has a different UI which makes the experience even more confusing. When I open a post, I expect to be able to see the discussion under it, without leaving my platform/app. I think it’s one of the things that make fedi weird and confusing for a lot of people. I discussed this with two project lead devs lately and they both agree there’s no efficient way to do it, not all platforms use the same API, and even if you cover the most common APIs to fetch replies from a remote server, they feel that the extra load this would cause on the remote server is bad practice and would cause complaints. So we have to send users to the remote servers if they want to see all comments to a remote post – and if they want to reply to something, they might need to copy the URL to fetch it on their home server and reply from there. This is not how users expect public discourse to happen, and it seems unnecessarily complicated in practice. Wish there was a solution to that.
@evanprodromou yes, activity pub is very extensible. Some things will always remain the same I think, such as no nomadic identity support, no moving of posts, probably no in band payments. However, imo that’s ok, one part of the fediverse doesn’t have to have everything. Don’t conduct private messaging in your common social media apps is an obvious first one, but also, there’s a federated end to end encrypted messaging system next door, it’s called matrix. It’s not activity pub, but why must it be? sure, it would be nice to have everything under a single protocol, but sometimes, some kinds of interactions simply don’t fit in certain social media platforms, for example, video calls don’t have any place of being in mastodon, long form content shouldn’t be posted from peertube, mastodon stile social networks shouldn’t be forced on the matrix model, but that’s why there are or should be bridges which should send across only content that makes sense for both platforms, it’s better to have nothing bridged at all than to have information bridged with mediocrity in both places. However, being able to log into a peertube instance with my go to social account, say, by having most fediverse software implement the client part of activity pub, and have that interface to make a channel on my gts account, send the activities to post a video to the feeds of my followers, that kind of stuff is probably more than in scope for activity pub right now. Another big problem we currently have is http signatures. For one, they don’t mean much, especially if there has to be an instance specific actor to break loops of signed requests, most likely encountered while interacting with servers with authorised fetch enabled, for another the specification most of the fediverse uses is a draft, and that’s why, for example, I can no longer follow peertube channels from my go to social account, same about mastodon with authorized fetch enabled. I do believe activity pub is a great protocol, but at the same time, it’s great that nostr exists(although I hate it), same for matrix, because the following and followers model, which is at the core of activity pub, can’t always fit on all interaction models, and if we can’t even guarantee that, why not have different protocols for different things and make bridges at the intersections?
@evanprodromou thanks Evan for the thoughtful reply to rabble's post. My toot was specifically about this point by rabble: "I need a new account on an instance of each of these servers" I think you're saying that's an app problem, not a protocol one. But is there any work you're aware of that would make it easy to e.g. add Pixelfed and Lemmy to your Mastodon profile; so e.g. I could login to Pixelfed and post stuff using my Mastodon profile, and it would also show on my Mastodon feed?
@evanprodromou just to add, there was some good further discussion on this point in the thread, that I only read after I replied. So it's good to see this is being discussed — I especially liked @timbray's point that the likes of Phanpy could be the key innovators for cross-app fediverse networking.
@ricmac@mastodon.social @evanprodromou@evanp.me easiest would be to allow users to log in with another account, but then create a new account locally for that service.
That’s how the majority of SSO implementations work. It’s not like you can “log in via Facebook” and that app gets to post status updates on your behalf.
Hey, Richard. So, there is a design for that, and I can write it up for you as a blog post. It’s actually really interesting how it works! Essentially, the site you log into becomes an API client for your home site, and sends activities back to it on your behalf. It’s an interesting structure.
@evanprodromou@evanp.me Regarding the issue of Data Portability, Mastodon is very conservative and does not provide import functions, while competing products such as Misskey / Firefish provide related functions.One of my recent efforts is to expand the data import and export functions on Firefish so that it can import and export data relatively completely to ensure that data loss when changing accounts is minimized.However, considering various complex situations, such as the original account being frozen, banned or canceled, the server to which the original account belongs is offline, the new account does not have enough permissions to read data, the reply is interspersed with unreadable posts and network impacts, etc. There may not be a perfect data import/export function, so manual verification may become the norm in data import/export.
@evanprodromou regarding #payment options, there's a #FEP on Payment Links: https://socialhub.activitypub.rocks/t/fep-0ea0-payment-links/3121
I would like to see a @Taler implementation for the #Fediverse. The good news is that it can be #funded (especially if the proposed work leads to more than one implementation)
Hint: @NGI_Taler
#GoTALER
@evanprodromou Great post! As far as “content portability” goes, all Fediverse apps have to is support import/export like WordPress does.
A few Misskey forks also support this as well, but most of the notable ones do not.