FediForum hot take

Emelia 👸🏻

@evan @julian @silverpill @pfefferle @dmitri

I'm not the only dissenting voice on that FEP, we should definitely use standardised discovery from the OAuth WG, and the client registration problem can be solved using the internet draft I've co-written with Aaron Parecki.

Evan Prodromou

@julian Yes, absolutely. Plug it into your authentication domain like an LDAP server or a Google Workspace, and away you go.

infinite love ⴳ

@thisismissem @julian @silverpill @pfefferle @evan @dmitri

"delegating the publishing and distribution" is exactly what the AP C2S API does.

Emelia 👸🏻

@evan @julian the only other "problem" here that I can foresee is different applications clobbering each other because they don't understand each other's data or extensions (I think of this as the "solid problem")

Emelia 👸🏻

@trwnh @julian @silverpill @pfefferle @evan @dmitri

I mean like saying to Mastodon, Pixelfed or Peertube "hey, this is my AP actor over here, send C2S activities to it and it'll handle distribution"

infinite love ⴳ

@thisismissem @julian @silverpill @pfefferle @evan @dmitri right, i've oft said that mastodon/pixelfed/peertube/etc are in reality better fit as AP Clients rather than AP Servers (technically, they are monolithic implementations where the S2S bits are subsumed by the transformers/workers/controllers)

having mastodon et al implement AP C2S support against a generic AP server would help solve the chicken-and-egg problem as well as ameliorate a slew of others (portability, etc)

Erin 💽✨

@thisismissem @evan @julian @silverpill @pfefferle @dmitri We should definitely use RFC 8414 for the metadata

If anyone ever works on a spec for this I’d definitely be interested (& interested in doing an impl)

Another thing missing (which maybe has been covered!) is how you learn what account you got authorized for. I think we should do that either via token introspection or OpenID Connect User Info; with token introspection we need to either say that the sub claim is the id of the actor or specify a JWT claim for this

Kevin Marks

@evan @julian @silverpill @pfefferle @dmitri @thisismissem I recognise that reference!
You can revive the other 2 bits of OpenSocial - Portable Contacts for friend graph and the data api that stores data per person and allows querying of it from friends…

django

Actually quite barebones but the most concrete example I’ve seen https://github.com/WhyINeedToFillUsername/inbox

@evan @julian @pfefferle

The Nexus of Privacy

@julian @dmitri

Jupiter Rowland

@Evan Prodromou @julian @Emelia

You may want to get into contact with @Mario Vavti and @Harald Eilertsen. Hubzilla already has an OAuth 2.0 implementation, both as a server and as a client AFAIK.

CC: @silverpill @Matthias Pfefferle @Dmitri |

Sebastian Lasse

@julian @dmitri

This is actually funny cause I said this in my Talk at https://berlinfedi.day/ too.
If non techie- or English people don't imagine "headless" (or ask for a CW), I do say:
C2S means "specialized clients and a generic server"

Josh Shaked ⁂

@evan @julian @pfefferle I think @js's browserpub is a good start

bumblefudge

@evan @julian @silverpill @pfefferle @dmitri @thisismissem

I like evan's point here, but my variant thereof would be to distinguish between a developer platform (Facebook Connect, Twitter's open API era), a user platform (Threads, Mastodon API; potentially harmonized OAuth cross-AuthN), and a data platform (ActivityPub, currently only plausible as such in read-only mode for lack of C2S hardening). We should think of those as 3 distinct layers of interop and prioritize/invest accordingly.

bumblefudge

@evan @julian @silverpill @pfefferle @dmitri @thisismissem

I tend to agree that OAuth work is low-hanging fruit for most projects' priorities, and maybe SWICG's as a whole. It's also worth mentioning that bluesky has modeled one way that OAuth can mediate between the same 3 layers (ATP data platform, Bsky user platform, and 3rd party apps borrowing bsky's users).