I had an idea for an open source tool, and figured it was worth having a discussion to see if it’s really something people want, or if there’s a better option for the task.
Essentially, my idea would be to write a small standalone HTTP server in Java, probably called ap_proxy. ap_proxy wouldc ontain a complete, spec-compliant implementation of both the client-to-server and server-to-server protocols.
Like nginx, ap_proxy would read configuration files in a simple language, and use it to determine how to handle user/federated actions.
A contrived example, that reverse proxies to your server, might look like:
#!/usr/bin/env java org.ap_proxy.Main
on Create {
when Like {
forward_to http://localhost:3000;
}
}
The DSL would be pretty simplistic, as the main use case would be proxying over some underlying server.
Pros:
Would guarantee your server to be spec compliant; many S2S implementations of AP today are partial/incomplete
Would normalize all data into its most verbose forms, so users of statically-typed languages could now handle AP with ease
Most importantly - you don’t have to implement AP yourself, which saves time, AND encourages more fed services to support AP as well
Cons:
Overhead of running an additional server
Requires learning the DSL (although simple)
Introduces new complexity during development/testing
So, what does everyone think? Would this be a worthwhile use of time? I know that I would use it, but is it something that would truly have a positive impact for many people?
When first building out go-fed/activity, I had a similar idea, but was thinking more of a forward proxy at the http layer (route the AP HTTP request to a backend) than a reverse proxy at the AP layer. I abandoned that idea because I wasn’t sure how http-signatures would behave, and because such a HTTP proxy wouldn’t need go-fed/activity for payload introspection as any generic JSON introspection for making routing decisions would suffice.
I think the idea of a generic AP server has been asked for quite a few times, (both go-fed/activity and go-fed/apcore let one build it in a statically typed environment, Pleroma in a dynamically typed one) but at the end of the day the question always seems to be “why does one want AP data” which is usually a specific Activity side effect (from running joke reply bots to OCR image to text reply).
I’m not quite sure I understand the “reverse proxy” part since your DSL markup makes it look like a forward proxy. It’s not immediately clear how an actor at such a proxy would forward Activities without wrapping it in its own Activity, such as an Announce (which is what pherephone is doing).
Thanks for reponse. forward_to is a bit of a misnomer; it would probably actually be called proxy_pass, like in nginx, or something similar.
Also, I guess I didn’t mention this, but the hypothetical ap_proxy wouldn’t forward activities/the AP data itself. It would just forward the JSON content sent by the client, normalized into the most verbose form. Your upstream server wouldn’t have to handle JSON-LD, or multiple formats; instead, it could operate on the JSON body itself, like your average REST API.
I think I might go ahead and try hacking a prototype out, if I have time today.
I am still confused, as I thought the JSON (or JSON-LD) payload of an AP POST HTTP request was the same as the AP data itself. The rest of it about HTTP clients and JSON-LD expansion algorithm I am good on. But, don’t let my confusion get in your way, it sounds like you have a pretty good idea of what you want.
But AP is not only about receiving the requests, it’s also about sending them and – importantly – keeping track of who follows you. It’s not a stateless protocol like HTTP. Which part is going to be handling and storing this persistent state?
p.s. I’m no longer alone in writing AP things in Java, yay
This is true, and ultimately something I overlooked in this design. I was really thinking of something in the same vein as nginx, but as you said, AP isn’t stateless.
I may be misunderstanding AP, though, but I still think it’s possible to have a sort of “gateway” server that normalizes incoming data, at least.
My core problem, though, is about getting the data properly read in a language like Dart or Java, so this might just be the wrong solution altogether.
