Conversation

Notices

1. Embed this notice
   Steve Bate (steve@social.technoetic.com)'s status on Monday, 01-Jun-2026 21:34:46 JST Steve Bate

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 21:34:45 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     @steve you saw this right?

     https://swicg.github.io/activitypub-api/basicprofile

     Maybe we can work together on it?

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 21:38:35 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Monday, 01-Jun-2026 21:38:36 JST Steve Bate

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     @reiver ⊼ (Charles) :batman: (reiver@mastodon.social)'s status on Monday, 01-Jun-2026 21:38:37 JST @reiver ⊼ (Charles) :batman:

     in reply to

     @steve

     This may be relevant:

     https://swicg.github.io/activitypub-api/basicprofile

     #ActivityPubAPI

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 21:39:24 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 21:41:29 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 21:44:04 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 21:53:34 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 22:03:38 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

     https://swicg.github.io/activitypub-api/basicprofile#client-to-server

     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.

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 22:12:55 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Monday, 01-Jun-2026 22:12:56 JST Steve Bate

     in reply to

     • @reiver ⊼ (Charles) :batman:
     • Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 22:22:08 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • 🫧 Social coding commons
     • @reiver ⊼ (Charles) :batman:

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

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Monday, 01-Jun-2026 22:22:09 JST Steve Bate

     in reply to

     • 🫧 Social coding commons
     • @reiver ⊼ (Charles) :batman:
     • Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Monday, 01-Jun-2026 22:31:19 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • 🫧 Social coding commons
     • @reiver ⊼ (Charles) :batman:

     @steve @reiver @smallcircles I think Bonfire and Emissary both support cookie auth for their social API implementations, but that seems like an internal implementation issue and not an interoperability issue. Third party apps can't use cookie auth I think?

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Tuesday, 02-Jun-2026 00:46:23 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

     @steve @reiver You have more faith in the compelling powers of MUST than I do.

     https://cosocial.ca/@evan/116403967622366259

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Tuesday, 02-Jun-2026 00:46:24 JST Steve Bate

     in reply to

     • @reiver ⊼ (Charles) :batman:
     • Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

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

   • Embed this notice
     Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸 (evan@cosocial.ca)'s status on Tuesday, 02-Jun-2026 01:23:29 JST Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     in reply to

     • @reiver ⊼ (Charles) :batman:

     @steve @reiver I agree with that. It's the option that says, it just isn't going to work unless you do it this way.

   • Embed this notice
     Steve Bate (steve@social.technoetic.com)'s status on Tuesday, 02-Jun-2026 01:23:30 JST Steve Bate

     in reply to

     • @reiver ⊼ (Charles) :batman:
     • Evan Prodromou 🇨🇦🇺🇸🇬🇷🇵🇸

     @evan @reiver Speaking for myself, I'm not interested in compelling powers. I think MUST is valuable not because it forces developers to behave, but because it defines the behavioral contract we can test, reason about, and build on (with interoperability guarantees).