FediForum hot take

[trwnh@mastodon.social]

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

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

[thisismissem@hachyderm.io]

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

[thisismissem@hachyderm.io]

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

[trwnh@mastodon.social]

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

[erincandescent@akko.erincandescent.net]

@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

[kevinmarks@xoxo.zone]

@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@social.coop]

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

@evan @julian @pfefferle

[thenexusofprivacy@infosec.exchange]

@julian @dmitri

[jupiter_rowland@hub.netzgemeinde.eu]

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

[sl007@digitalcourage.social]

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

[joshshaked@me.dm]

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

[by_caballero@mastodon.social]

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

[by_caballero@mastodon.social]

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