FediForum hot take
-
@julian @silverpill @pfefferle @evan @dmitri
I was far more interested in the idea of delegating the publishing & distribution of activities to another server from existing AP software
-
@julian @silverpill @pfefferle @dmitri @thisismissem The big advantage is that you can create clients that do interesting things like games, drawing apps, enterprise applications, and you can plug them directly into the social network. You don't have to create a new social network service for every single application type you're making. That's a dumb, old way of thinking, and we have to get over it.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@julian @silverpill @pfefferle @dmitri @thisismissem The Fediverse should be more like the Facebook Platform (lots of client apps using the same social graph) rather than the Apple App Store (a bunch of one-feature apps that have to bootstrap their own social network each time).
We'll get there. Most servers already support the read-only aspect of the ActivityPub API pretty well. Implementing the write-only part is actually pretty straightforward. A ratchet process of clients and servers.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@julian @silverpill @pfefferle @dmitri @thisismissem The next thing we need is a straightforward OAuth 2.0 profile. I did one as a FEP, but Miss Em thinks it should use a different discovery method, so I think we should maybe move the effort into a TF at the CG.
-
Evan Prodromoureplied to Evan Prodromou on last edited by
@julian @silverpill @pfefferle @dmitri @thisismissem I used onepage.pub as the sample app in my book, and created a command-line API client called `ap`.
https://github.com/evanp/onepage.pub/
https://github.com/evanp/ap/ -
@[email protected] that's actually a pretty wild concept... ActivityPub as a Service.
I see dollar signs.
-
Emelia πΈπ»replied to Evan Prodromou on last edited by
@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.
-
@julian Yes, absolutely. Plug it into your authentication domain like an LDAP server or a Google Workspace, and away you go.
-
infinite love β΄³replied to Emelia πΈπ» on last edited by
@thisismissem @julian @silverpill @pfefferle @evan @dmitri
"delegating the publishing and distribution" is exactly what the AP C2S API does.
-
Emelia πΈπ»replied to Evan Prodromou on last edited by
-
Emelia πΈπ»replied to infinite love β΄³ on last edited by
@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 β΄³replied to Emelia πΈπ» on last edited by
@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)
-
@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 theid
of the actor or specify a JWT claim for this -
@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⦠-
Actually quite barebones but the most concrete example Iβve seen https://github.com/WhyINeedToFillUsername/inbox
-
-
Jupiter Rowlandreplied to Evan Prodromou on last edited by@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 | -
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 βreplied to Evan Prodromou on last edited by
@evan @julian @pfefferle I think @js's browserpub is a good start
-
@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.