ActivityPub client-to-server support

[Sylvhem]

Pitch

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.

Motivation

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.

[Gargron]

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.

[trwnh]

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.

[nightpool]

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.

[aschrijver]

I think both @Gargron and @nightpool arguments are/were quite valid at the time. Since we are now almost 2 years further along the fedi adventure, I am wondering if the situation - and your perspective on implementing C2S - has changed. There are more C2S clients (I've followed a bit the work of @yvolk in andstatus/andstatus#499), and I saw a recent interesting discussion about generic AP C2S back-ends with custom API layers on top of them (but darn, I can't find that toot thread anymore).

[melvincarvalho]

Love the idea of C2S

High level thought here

The original thought was that S2S and C2S should all be one thing

1. Have a canonical identity URI
2. Obtain a credential (PKI or bearer token)
3. Attach credential to a payload (JSON)
4. Locate endpoint (inbox or file)
5. Send Message
   5.1 POST = activity/change
   5.2 PUT = new
   5.3 PATCH = edit

Each thing in itself is a useful thing (especially 1), and together they can be building blocks to more functionality, such as single sign on, client side apps, and even more advanced things like P2P chat, or payments (ie lots of things can happen out of band when you have distributed canonical entities)

You'd end up defining so much custom vocabulary

Just a note on this comment. One of my pet peeves is having to define custom vocabularies for everything. I find it a high overhead and barrier to getting things done. Actually I think this is a weakness of the RDF/Linked Data model in general that got inherited via JSON-LD.

IMHO we should simply have allowed plain JSON strings to be legal in any context, and explained to developers the benefits of creating URI predicates, vocabs and self documenting data models, while allowing choice

There is a trick however to be able to work with plain JSON string that i use. And that is:

to map foo -> urn:json:foo which can be done in the key itself, in the context or at the base level (ie implied)

Just something I use when I want to knock something up quickly without having to go to the trouble of a vocab and hosting it somewhere. Tho really IMHO could have been a useful addition to JSON-LD 1.x.

[melvincarvalho]

It might actually be worthwhile to do this in stages. Because each stage has benefits. For example (1) could allow federated single sign on to other parts of the fediverse without requiring them to run mastodon servers

If I could outline a design that would I think be relatively non-invasive to implement:

1.1 Give users a canonical identifier

This is more a challenge of consensus than anything else. But I'd suggest that profile pages have converged around

https://host/@user
Example: https://kosmos.social/@slvrbckt
Host: kosmos.social
User: silverbckt

as an http identifier for your profile page

This is actually very good and solves a lot of problems. The benefit of http identifiers is that everything speaks http, you can lookup the page, and get more information about the user

1.2 Put profile information in JSON in the profile page

Sounds obvious, but almost no one does this. Some do the complex webfinger dance, then parse JRD. Others use very complex content negotiation then parse either JSON-LD or Turlte.

But there's an easier way, and actually mastodon is way head of the curve on this.

You can just put it in a script tag. This is the so-called structured data island approached, popularized by schema.org

The good news is that mastodon partially already does this:

<script id="initial-state" type="application/json">

Whichever genius thought of this, I want to buy you a beer!

It can simply be extended (with another data island) to provide useful information that you might want to include in your profile. e.g. name, inbox, key, followers, homepage etc. It can then be used within the page, or parsed by an external server to authenticate that user or find out more about them and their endpoints

For example it could look like this:

<script id="me" type="application/json">
or
<script id="me" type="application/ld+json">

1.3 The JSON

So extending the existing data island, or better adding a new one, I think would be practical to code, and have many benefits. The JSON could evolve incrementally, but to start with it could be as simple as:

{
  "@id": "#me",
  "inbox":  <your inbox URI>,
  // optional 
  "publicKeyPem":  "my key #1",
  "<bearer token endpoint>": <Oauth URI>,
  "followers": <your followers URI>,
  "following": <your followers URI>,
  // and so on
}

If I get time, I'll do a proof of concept on a mastodon server and provide a patch. As I think most of the heavy lifting is done. If there was some will to get something like this upstream, that would be even better.

This would be a big step forward to making the fediverse even more distributed and decentralized. It would allow new work flows with new pieces of software, servers, and apps, with relatively little technical debt. Systems could continue to evolve without or without patches to mastodon servers, leading to a more diverse eco system and better UX for end users

EDIT: Re: 1.3 above. Actually someone pointed out to me that this part is already solved, because if you just put .json on the end of the profile URI you get back some JSON \o/

[markcellus]

Good ideas here! I'd like to at least point out my use case that I think could help around the brainstorming of an approach here.

I tried setting up a custom domain server for my blog that the Mastodon client can simply read from. I did this because I would like to continue to create my blog entries directly on my website rather than in Mastodon. I updated the server to expose the .well-known/webfinger endpoint so that Mastodon client can find my outbox feed. The outbox feed has all of my blog entries and all endpoints adhere to the ActivityPub protocol.

But I was surprised to realize that I couldn't simply search for myself as a user on my own custom domain from within the Mastodon client.

[viktorstrate]

I would wish that client-to-server activitypub was widely supported by the festiverse.
This would allow me to use it like I use email:

• With a client where I can have multiple accounts across different instances and platforms.
• Local address book to better manage friends, I could even use the same address book as I use for emails and phone.
• Also being able to use a custom client-sided formatter using the ActivityPub source property, eg. Emacs Org mode or RTF, would be really nice.

[aschrijver]

With openEngiadina moving away from ActivityPub to XMPP, in part due to lack of C2S support, I posted to the SocialHub thread discussing C2S. Just mentioning the thread here for cross-ref: https://socialhub.activitypub.rocks/t/implementing-activitypub-client-to-server/981

[dellagustin]

Hey all, I got here because I was investigating how to add comments support for podcasts on my open source client side only podcast aggregator app.

Just to explain the use case, there is a proposal on an initiative called Podcasting 2.0 (podcast:socialInteract specification) to use ActivityPub for a commenting system on podcast episodes.

I was planning to consume C2S ActivityPub APIs from my podcast aggregator to allow my users to post replies, but it seems that overall adoption of C2S is not widely available on servers implementing activity pub.

[aschrijver]

Hi @dellagustin I see this relates to podStation/podStation#304 .. Good C2S support is a long-standing open issue. It is best to take questions and discussion to the SocialHub community in the C2S category (where you'll find related discussions too). (PS. If you do so, pls refer to this issue and yours from the forum topic so we keep things well cross-linked).