For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.
-
@mariusor woot! 🥳
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)
@smallcircles thank you Arnold.
-
@smallcircles thank you Arnold.
The codeberg issue is kind of still an ugly scratch pad rn. The thing awaits a follow-up where stuff is more organized and easier to drill down into. Proper docs eventually.
A first step may be to name the discrete and granular building blocks that one should focus on when starting out on an #ActivityPub client-to-server adventure quest. Give them consistent names. And then to map all the various projects to that as a MDN-like who-supports-what table.
-
The codeberg issue is kind of still an ugly scratch pad rn. The thing awaits a follow-up where stuff is more organized and easier to drill down into. Proper docs eventually.
A first step may be to name the discrete and granular building blocks that one should focus on when starting out on an #ActivityPub client-to-server adventure quest. Give them consistent names. And then to map all the various projects to that as a MDN-like who-supports-what table.
@smallcircles GoActivityPub servers support following things for Client to Server:
* Accessing objects and collections
* Filtering the collections through query parameters (eg. ?type=Create)* Support for OAuth2 actor endpoints information and authorization
* Support for .well-known information (webfinger and now, OAuth2 client registration)* ACLs for accessing them based on recipients list - this includes collection filtering of individual items
* ACL principal extraction from OAuth2 Bearer token (or from HTTP-Signature)* Outbox Activity validation & processing (which I think is the main one :D)
-
@smallcircles GoActivityPub servers support following things for Client to Server:
* Accessing objects and collections
* Filtering the collections through query parameters (eg. ?type=Create)* Support for OAuth2 actor endpoints information and authorization
* Support for .well-known information (webfinger and now, OAuth2 client registration)* ACLs for accessing them based on recipients list - this includes collection filtering of individual items
* ACL principal extraction from OAuth2 Bearer token (or from HTTP-Signature)* Outbox Activity validation & processing (which I think is the main one :D)
( @smallcircles in case you wanted a starting point )
-
( @smallcircles in case you wanted a starting point )
@mariusor wonderful, thank you. It is updated on codeberg now
-
@mariusor wonderful, thank you. It is updated on codeberg now
@smallcircles sometime in the future I'll have a bit more explanations about the different things to incorporate in the #GoActivityPub documentation.
I'll try to remember to ping you.
-
For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.
The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni
@mariusor this is great, I'm looking forward to testing this
-
@mariusor this is great, I'm looking forward to testing this
When you do, feel free to ping me with questions (here or on the mailing list).
-
For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.
The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni
@mariusor nice!
-
For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.
The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni
@mariusor did you implement the oauth metadata endpoint also? Can clients discover the registration endpoint easily?
-
@mariusor did you implement the oauth metadata endpoint also? Can clients discover the registration endpoint easily?
@evan yes, yes, of course.
They go hand in hand... I remember seeing on the SWICG mailing list a comment where this mechanism is no longer considered secure, but I don't recall the details.
-
@evan yes, yes, of course.
They go hand in hand... I remember seeing on the SWICG mailing list a comment where this mechanism is no longer considered secure, but I don't recall the details.
@mariusor yeah, it might be a good idea to think about CIMD. It uses the same schema of properties as dynamic registration, but you fetch them at authorization time instead. I implemented both in onepage.pub and it was pretty straightforward.
CIMD - OAuth Client ID Metadata Documents
Learn about Client ID Metadata Documents (CIMD) - a new OAuth approach that lets clients identify themselves using URLs instead of preregistration. Presented by Stytch.
CIMD (client.dev)
-
@mariusor yeah, it might be a good idea to think about CIMD. It uses the same schema of properties as dynamic registration, but you fetch them at authorization time instead. I implemented both in onepage.pub and it was pretty straightforward.
CIMD - OAuth Client ID Metadata Documents
Learn about Client ID Metadata Documents (CIMD) - a new OAuth approach that lets clients identify themselves using URLs instead of preregistration. Presented by Stytch.
CIMD (client.dev)
@mariusor are you coming to FOSDEM? I think we should have an ActivityPub API hackday.
-
@mariusor are you coming to FOSDEM? I think we should have an ActivityPub API hackday.
@evan as of now I don't plan to come.
But I have no other obligations for February, maybe a last minute change of heart.
-
@mariusor yeah, it might be a good idea to think about CIMD. It uses the same schema of properties as dynamic registration, but you fetch them at authorization time instead. I implemented both in onepage.pub and it was pretty straightforward.
CIMD - OAuth Client ID Metadata Documents
Learn about Client ID Metadata Documents (CIMD) - a new OAuth approach that lets clients identify themselves using URLs instead of preregistration. Presented by Stytch.
CIMD (client.dev)
@evan yes, this is the one, I realized I already added it to my ticket list: https://todo.sr.ht/~mariusor/go-activitypub/337
-
@evan as of now I don't plan to come.
But I have no other obligations for February, maybe a last minute change of heart.
@mariusor let me ask, what are your opinions on beer?
-
@mariusor let me ask, what are your opinions on beer?
@evan I lived in Burssels for some many years, you won't tempt me with beer.
-
@evan I lived in Burssels for some many years, you won't tempt me with beer.
@mariusor that's too bad. All I have left is mussels, French fries, large-scale bureaucracy, and peeing statues.
-
For people interested in #ActivityPub #C2S (client to server), the #GoActivityPub services have gained the ability to dynamically register OAuth2 clients based on RFC7591.
The easiest to test is the ONI project that can be directly run without much setup: https://git.sr.ht/~mariusor/oni
I'd generally discourage RFC7591 in decentralized systems due to the fact that it creates client sprawl (this is currently a problem with Mastodon's client registration mechanism, which is why we created CIMDs) — every client in RFC7591 is a distinct client, with its own
client_idandclient_secret, which can make client management interfaces difficult to implement (e.g., every time you login on a mobile device or SPA, you'll get a brand newclient_id). CIMDs solve this by anchoring client metadata to a URI, and using that URI as theclient_id.If you need to test clients using CIMDs in development, there is cimd-service however, it's currently targeting the AT Protocol ecosystem (so has a few specifics that at present there that would not necessarily make sense of ActivityPub)
