Super cool! If there's anything that makes sense to submit upstream, please do!

[Wowfunhappy]

Hi, I just discovered this existed! I'm so glad you were able to build on top of AquaProxy, I love that my work (itself built on top of others) can get further extended by more people.

It makes sense that you created a full fork, because there are some features in here I don't think I'd want to have upstream. AquaProxy, unlike LiquidProxy, is built to be accessed from the same machine it's running on, so having e.g. a web UI or certificate management feels like a lot of extra surface area for something to go wrong.

However, if there's anything you think would make sense to have upstream, please submit a pull request! You do not need to test building your code in the way AquaProxy gets built for Snow Leopard compatibility, I'll do that part, I'm very aware that my build process is nuts. The one thing I would need is for all code to stay compatible with Go 1.19. (Maintaining compatibility back to Go 1.13 as well is preferable, but I could be convinced to drop it.)

For example, I think it's great that you were able to combine the Mail and HTTP proxies into one binary (if I'm understanding the readme correctly), and I think it's probably better to have the code split into multiple files as you did. There are some other features you added which I don't entirely understand, so I might need your help to assess what makes sense.

If this all sounds like too much extra work, that's fine too, but I wanted to put the possibility out there. Also, if you do make a pull request and it takes me a long time to review/merge it, I apologize in advance, I'm a 5th grade teacher and sometimes stuff takes me a while during the school year.

---

While I'm here, your readme says:

There are some AI? traces on the code - and .claude on .gitignore. They likely come from the original project, not me. (likely AquaProxy, not mitm)

Just for avoidance of doubt, I used Claude very extensively when developing Aqua Proxy, and I don't think the project would have been possible for me otherwise; this just isn't a domain I'm familiar with. I'm definitely not trying to hide anything here!

[nilFinx]

Hey, thanks for the response.

You do not need to test building your code in the way AquaProxy gets built for Snow Leopard compatibility.

Since I have Mojave (just barely newer...) + Mavericks combo, and some friends with SL, I'll likely be able to test it myself.Thanks for the offer though!

a web UI or certificate management feels like a lot of extra surface area for something to go wrong.

I could make a flag that disables the web UI, and relax the certificate file requirement, so it can be used exactly like how it was used before. Done

For example, I think it's great that you were able to combine the Mail and HTTP proxies into one binary (if I'm understanding the readme correctly), and I think it's probably better to have the code split into multiple files as you did

Everything you mentioned here is correct. Mail and HTTP proxy is combined into one binary, and since you already provided flags like no-imap, you could easily disable it if you don't want.

Oh, and the README's AI disclosure is here to deal with "Is this AI" problem that might come, and isn't supposed to shame anyone. It also helped me in this project a lot.

I'll see if I can make a PR for merging proxies and separating the files. Done I really appreciate your response!