Merge branch 'master' of gitea.moe:lamp/activitypub-proxy

README.md

@@ -1,8 +1,15 @@
 # ActivityPub Proxy
 
-A **simple** proxy for ActivityPub that lets you circumvent blocks by masquerading as another domain name. All it does is replace all hostnames in the text proxied through, and for signed POST requests, it swaps the public keys and re-signs the requests.
+A brutally-simple proxy for ActivityPub that lets you circumvent instance blocks by masquerading as another domain name. All it does is replace all hostnames in the text proxied through, and for signed POST requests, it swaps the public keys and re-signs the requests.
+
+Suppose you have a server at *.proxy.example, your handle is @bob@mastodon.one and you want to follow a friend at @alice@mastodon.two, but mastodon.two blocks mastodon.one for irrelevant reasons. You can change the handle to @alice@mastodon-two.proxy.example and theoretically will be able to fully interact with the other user (and vice-versa) by being masqueraded as @bob@mastodon-one.proxy.example. (If the domain has hyphens, replace with double hyphens.)
+
+The intended usage of this is as an alternative to using alt accounts or moving your account to circumvent whole-server blocks that have nothing to do with you and are unfairly cutting you off from mutuals, despite your particular account being compliant with their rules. Of course, you are entirely responsible for your behavior and compliance whether it's an alt account or a mirror, as there is no practical difference to the other end. ActivityPub Proxy is not intended for nefarious usage.
+
+The major caveat with this particular implementation is that if you boost or reply to proxied posts, your followers will see and interact with those authors via masquerade as well, causing a bit of a mess. This is unless you limit the usage to whitelisted domains/users, which you will almost definitely have to do or someone will abuse it and get it blocked. In that case, anyone who isn't whitelisted just won't see the boosts.
+
+With that said, this initial implementation is more of an experimental proof-of-concept of what can be done with so little code, but to implement this concept properly, it probably needs to be rewritten with a deeper, stricter integration into the ActivityPub protocol. Access controls need to be more flexible and reliable, and a solution needs to be found for the boosting issue.
 
-To use it, type a user's handle, replace the dots in their domain with hyphens, and add `.yourproxydomain` to the end. (If the domain already has hyphens, replace them with double hypens.) So for example, say you want to follow @kingu_platypus_gidora@octodon.social but the woke administrator has blocked you (or your instance blocked them wtf mastodon.social??), and you have a proxy at *.activitypub-proxy.cf: that would make @kingu_platypus_gidora@octodon-social.activitypub-proxy.cf which you can theoretically follow and fully interact with just like the real user. The person on the other side will see your tag proxied the same way, `@yourname@your-domain.your.proxy`, and they can follow and interact with you back.
 
 ## Installation
 
@@ -34,11 +41,3 @@ WantedBy=multi-user.target
 ```
 
 `systemctl enable --now ap-proxy` and Bob's your uncle.
-
-
-## Known issues
-
-- Sending AP messages to Pleroma makes it 500 Internal Server Error for no obvious reason
-- Since it simply replaces all instances of the domain names in the raw JSON text, mentions of those names in post content will be replaced as well. Although this makes it more likely to work with _anything_ with less code, a stricter version that parses deeper into the protocol might be of better quality.
-
-If any issues please submit!