In the past I've mentioned that I'm looking to upgrade Mastodon to ActivityPub instead of OStatus. That's been an overarching, long-term goal ever since Mastodon has started picking up steam for the first time. The OStatus protocol has its issues, and I had to do some patchwork on top of it to make things work the way we needed them to. Naturally, this is not something that most users should care about. The protocol layer is mostly hidden from plain view. So in fact, changing the protocol will be barely noticeable from a UX perspective. There are but a couple improvements which have now become possible thanks to the upgrade, which I will mention later.
However, like I've said in previous posts, there was one genuinely concerning problem with OStatus in Mastodon, which was the driving reason for me to work on an upgrade. It was the fact that status privacy and protected accounts were an extra feature, and non-Mastodon servers wouldn't understand them. We were careful to only deliver private toots to servers of followers, thusly alleviating the issue entirely if you had the locked account option and were careful not to approve followers from non-Mastodon servers. However, this is obviously inconvenient, and doesn't inspire confidence. Users shouldn't need to care about what software their followers are using!
Still, if a private toot did go to a follower on a non-Mastodon server, that server would treat it like a public post. This has been reason for many worrying warnings I had to add to the UI, as well as people warning others via word of mouth. Some people cited it as the reason they won't use Mastodon, and it also meant I couldn't make an emphasis on our superiour granular privacy settings when recommending my software.
In ActivityPub, unless specified otherwise, any post defaults to invisible. And yes, the ActivityPub standard mandates a way of addressing content to specific groups of people. Meaning that any implementation of ActivityPub will, by default, respect the privacy of our toots. And as I am involved in the development of the ActivityPub standard (W3C Social Working Group), I have also pushed a specification that all accounts are treated as "locked" by default (similarly to XMPP), e.g. each "follow" must be answered by an "accept" before it's considered valid on both servers. In case of unlocked accounts, we simply auto-accept.
Talk on implementing ActivityPub in Mastodon has started in April, however it wasn't my own primary focus until last month. That's when I seriously started to implement it using a 3 step plan: entity representation, handling of incoming data, and sending of data, in that order. Version 1.5 had a focus on different features, but contained the first step of that plan. After 1.5 was released, ActivityPub became my sole priority, and that's what I spent this month on.
Mastodon will support both OStatus and ActivityPub, but prefer ActivityPub when available. Slowly, all accounts in the network will upgrade. Upgrading an entire federated network to a new protocol is very hard, and very frustrating, but I think we're close to a point where we have it all figured out. However, there's a point to be made about backwards-compatibility: To solve the aforementioned OStatus privacy problem, we have to entirely stop sending private toots over OStatus. But during the upgrade phase of the network, as some users will still be primarily on OStatus, this would lead to messages not being delivered where they should. So, in fact, we will have to have two releases: backwards-compatible v1.6, which will continue to send private toots over OStatus, and backwards-incompatible v2.0, which will not.
Anyway, enough of that. That's the privacy benefit of the upgrade. There are a couple more:
With ActivityPub, we will be able to forward "delete" messages a lot further in the network, e.g. through people who reblogged the original. Before, the reblogger's server would receive the "delete", but not the reblogger's followers' servers, since the original server has no way of having that connection (unless there is a different way they're connected). Now, the reblogger's server will forward the "delete" to followers.
Similarly, we will forward replies to followers' servers. E.g. you are following Alice, you are not on Alice's server, Alice toots a cat picture. You would only see replies to that cat toot if you happen to follow the people who reply, or if Alice replies to them and your server back-loads that part of the conversation. Now, Alice's server will forward the replies she gets to your server (for clarity: not into your home feed, just to your server), so when you expand the conversation, you will see all the parts, rather than a segment.
Phew. Okay. Done talking about ActivityPub. I've also redesigned the public profiles. By default, non-reply only toots are shown, and there are tabs for toots with replies, and toots with media. Also, public profiles can now display pinned toots (toots can be pinned from web UI). I've also fixed up how everything looks in right-to-left languages.
Wew, quite a wall of text I've written up. Sorry about that! As always, I am immensely grateful for all the support from all of you.