@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 @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.

@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.

@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 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 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 @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.

@evan @reiver Maybe we need a read-only and write-only subprofiles? But what about an C2S server that doesn't allow reading the inbox nor posting to the outbox (like Mastodon) but still satisfies the MUST requirements in the profile?