Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ActivityPub client-to-server support #10520

Sylvhem opened this issue Apr 9, 2019 · 3 comments


Copy link

commented Apr 9, 2019


Mastodon should implement the client-to-server part of the ActivityPub protocol. This would allow Mastodon users to sign in from every ActivityPub compliant applications.


With the growing popularity of the Fediverse, more and more clients are created. Implementing this would ensure that Mastodon users could login through most of them.

However, there is another reason to implement that. Mastodon is, currently, the biggest and more popular ActivityPub implementation. Most clients (like Fedilab, Tusky, Amaroq, Halcyon, Pinafore…) were created specifically for it. But as other platforms appear, including similar micro-blogging ones like Pleroma, developers of those clients have to choose between supporting new protocols or to stick to our API. And since Mastodon is the biggest fish in the pond, a lot of them choose the latest. As I understand, this is one of the reasons that pushed Pleroma's development team to add our own API into their software. The risk is that, at terms, our proprietary API will become the de facto standard when it comes to client-to-server communication in the Fediverse.

There must have been most urgent matters when ActivityPub was integrated into Mastodon, one year and a half ago (see #1557), but I think now would be a good time to start figuring things out and working on it.


This comment has been minimized.

Copy link

commented Apr 9, 2019

The ActivityPub C2S spec is incredibly barebones. No notifications (as separate from home feed -- it's all mixed together in "inbox"), no search, no autocomplete, no domain blocking, no muting (as opposed to blocking), etc etc. You'd end up defining so much custom vocabulary and endpoints that you might as well just use the Mastodon REST API.


This comment has been minimized.

Copy link

commented Apr 9, 2019

All those are client features, though.

  • There is no functional difference between a Create and a Like
  • Search can be performed on the local cache more reliably than the server database
  • Autocomplete can be performed against a contact address-book
  • Muting and filtering can be done purely client-side and in fact used to be done that way

However, it is true that the Mastodon API is better for thin-clients which depend on the server to perform all logic. I think the proposal to add C2S is more like asking for Mastodon to support more generic / advanced mail-like use cases. In another sense, it can be said that the Mastodon server is the ActivityPub client, since it's an integrated vertical.


This comment has been minimized.

Copy link

commented Apr 10, 2019

The mastodon rest API is designed for implementing a mastodon client, specifically. it's a thin-client API that works to provide a consistent user experience across all apps and platforms. The activitypub c2s api is cool but it comes from a wildly different perspective, and it would be a lot of work to write clients that support that, with no real clear benefit to the mastodon user experience. Furthermore, it would be incredibly hard for the mastodon code base as it exists today to support a good implementation of C2S and the mastodon API side-by-side—practically, it would mean basically re-writing the mastodon server from the ground-up. And even once you've done all of that work, there aren't any existing C2S clients out there that provide a comparable user experience to the mastodon front-end.

This is all on top of the bare-bones nature of the protocol that @Gargron mentioned.

I really truly believe there should be a good, simple, easy to use activitypub c2s client and server, but I don't think the mastodon project can be that—or at least, not the codebase we have today.

@Gargron Gargron added the suggestion label May 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
4 participants
You can’t perform that action at this time.