FediForum hot take
-
Evan Prodromoureplied to Raphael Lullis on last edited by
-
@julian @pfefferle @evan @evan @pfefferle It's headless but honestly I don't see how that could help. Vendor-specific RESTful APIs won because they are easier to understand and easier to implement. In order to be competitive, standard C2S needs to provide something that can't be achieved with RESTful APIs.
I think the answer is FEP-ae97, which enables rich offline-first clients and data portability.
-
@[email protected] @[email protected] @[email protected] @[email protected] long story short, the session participants basically agreed that it was a bit of a chicken and egg problem.
Also looping in @[email protected]
-
@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)
-
Erin π½β¨replied to Emelia πΈπ» on last edited by
@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
subclaim is theidof the actor or specify a JWT claim for this -
Kevin Marksreplied to Evan Prodromou on last edited by
@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
-
The Nexus of Privacyreplied to julian on last edited by
-
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 |
