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, ... ?
-
What would you consider the minimal features to be considered an #ActivityPub C2S server? Support for inbox GET, outbox POST, OAuth2, proxy endpoint, ... ?
-
What would you consider the minimal features to be considered an #ActivityPub C2S server? Support for inbox GET, outbox POST, OAuth2, proxy endpoint, ... ?
-
@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.
-
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.
https://github.com/swicg/activitypub-api
What fedivers is, is in the eye of the beholder, though, so
-
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.
https://github.com/swicg/activitypub-api
What fedivers is, is in the eye of the beholder, though, so
-
@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.
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.
-
? Guest crossposted this topic to General Discussion
-
What would you consider the minimal features to be considered an #ActivityPub C2S server? Support for inbox GET, outbox POST, OAuth2, proxy endpoint, ... ?
@steve you saw this right?
https://swicg.github.io/activitypub-api/basicprofile
Maybe we can work together on it?
-
@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.
-
-
"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.
-
"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.
-
@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.
-
@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.
Adding the link, for reader's information..
https://codeberg.org/fediverse/delightful-fediverse-apps/issues/130
-
-
-
"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 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.
-
@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.
-
@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 @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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login