Idea: Generic ActivityPub Server/Reverse Proxy

#1

Hello, SocialHub!

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?

Thanks.

#2

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

#3

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.

#4

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.

#5

Let us know, if you are prototyping. i’m interessted on everything java and activity pub related :wink:

#6

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