What would you consider the minimal features to be considered an #ActivityPub C2S server?

What would you consider the minimal features to be considered an #ActivityPub C2S server? Support for inbox GET, outbox POST, OAuth2, proxy endpoint, ... ?

@steve there's a pretty nice checklist at the end of @evan's book. It includes both C2S and S2S.

@steve

This may be relevant:

Basic Profile for Social API Servers

(swicg.github.io)

#ActivityPubAPI

@reiver Thanks. I knew there were some related git issues, but I didn't know Evan had created a document for his proposals. Based on that document, servers that don't support OAuth2 auth code grants would not be considered C2S (Social API) servers. It's interesting to me that there's no requirement for outbox POST or inbox GET. It seems like Mastodon would satisfy these C2S server requirements (OAuth2 auth code grants, bearer tokens, 429 rate limits, etc.), but that doesn't seem correct to me.

@reiver @steve

What I found interesting and had a nice exchange on some time ago (unfindable, lost in the fedi) is that I found what is listed on the ActivityPub API task force README to be a particular interpretation of what is needed, that is not the minimum perhaps.

But that is against my thinking that fediverse - via post-facto interoperability and protocol decay - diverged from the power and promise of AP. With AP a "social graph of addressable actors that exchange activities with an object payload" and fediverse having all kinds of leaked abstractions and conventions that make it more a content publishing environment to remodel existing social media but more decentralized.

GitHub - swicg/activitypub-api: ActivityPub API Task Force repository.

ActivityPub API Task Force repository. Contribute to swicg/activitypub-api development by creating an account on GitHub.

GitHub (github.com)

What fedivers is, is in the eye of the beholder, though, so

@reiver @steve

See also https://social.coop/@smallcircles/116379158584600016

@steve

I think the document is preliminary. And, Evan has asked for feedback.

I'm sure he would welcome your feedback on anything you feel is missing.

@steve you saw this right?

Basic Profile for Social API Servers

(swicg.github.io)

Maybe we can work together on it?

@steve @reiver so, this is a profile to make it easier to write social API clients.

@steve @reiver authorization code flow is so common in OAuth 2 that a lot of people just call it "OAuth". What were you thinking of instead?

@steve @reiver

"Social API servers SHOULD provide an inbox collection that accepts the GET HTTP method. Social API servers SHOULD allow actors to read their own inbox collection.

"Social API servers SHOULD provide an outbox collection that accepts the POST HTTP method."

I'm not crazy about the language though. It needs tightening up.

@steve @reiver you can get pretty far with Mastodon's implementation of actors, collections and objects! It's an OK read-only API. The CORS support sucks, though; you have to run everything through a proxy.

@evan @reiver I wasn't thinking of something instead, although I can imagine implementations that use pre-shared "app tokens" or HTTP Basic Auth (as examples). The motivation for the question is the C2S list maintained by @smallcircles. It seems like most of those are not what I'd think of as C2S (Social API) servers.

@steve @evan @reiver

Adding the link, for reader's information..

Which ActivityPub applications support Client-to-Server (C2S)?

delightful-fediverse-experience - A curated list of server applications supported on the ActivityPub Fediverse and related standards.

Codeberg.org (codeberg.org)

@steve @reiver I also think it's perfectly reasonable for Mastodon to move iteratively closer to this basic profile. Supporting CIMD or dynamic client registration would be great. CORS for actors, objects and collections would be nice, too.

@evan @reiver An actor not being able to read their own inbox disqualifies it as a C2S API for me (even a read-only one).

@evan @reiver Thanks. I saw that. These seem like fundamental C2S capabilities to me (more than a "SHOULD") but I can add my comments in the github repo.

@steve @reiver one part I am concerned isn't "minimal" is the section on client to server interactions.

Basic Profile for Social API Servers

(swicg.github.io)

That said, this is about the minimum of what I'd want to work with as a client developer: creating web content and organizing it into collections.

@steve @reiver that's interesting.

It's something a client can quickly detect with an OPTIONS request.

Inbox read access seems important but not essential.

I can think of a lot of write-only client applications that don't need read access to the inbox. Like a video game that shares in-game achievements, or a follow button widget.

@steve @reiver @smallcircles that's interesting!

I think the whole reason we have OAuth is so you don't have to put your password into a third-party app. Basic Auth sounds like trouble!

For the pre-authed token, aka "personal access tokens", I use those a lot for different APIs, but I think they're usually just treated as Bearer tokens? So they'd fit here.