just thought I’d mention I just created yet another http proxy
feel free to fork, steal code, open issues or PRs …
it’s the first draft; to use the console script I seem to have made a mistake and you always need to pass the --host flag otherwise it errors out and doesn’t default to localhost …
the README shows a bit more of the broader picture/plan … it really is just the first couple of lines of code ;D …
Known limitations:
you need to always pass the --host flag
only GET for immutable data
my very own goal here is to have a simple to install and easy to use proxy server against which I can easily develop svelte client-side apps that I can then publish to autonomi
what I was missing when I started them was the OpenAPI interface description to put that into a project folder for an app where I can interact with an AI to develop the frontend app faster …
and the docker container isn’t a dealbreaker but the key-handling is somewhat basic for now I think too; with my own proxy I’ll just AES encrypt the pk into a local file and no need to get the info into a docker container or into my envs and stuff …
probably a mixture of valid reasons and just seeing that it’s pretty easy and fast to create with the python libs … (and to publish to pypi and to install it from there and use it everywhere I want … with docker as dependency or rust/compiled binaries it’s not super difficult but a little bit more of a hassle for me than just installing a python lib …)
it’s a very valid question though … we shouldn’t require people to run 3+ different proxy servers to be able to surf autonomi …
… at least my plan (!) is to have an abstraction layer on my client apps to be able to detect which proxy server is running and to make the corresponding GET/PUT calls accordingly …
so multi-proxy-support would be the idea … but for my first drafts just using my own proxy is the fastest and simplest route …
I think sooner or later a standard for autonomi proxies will establish itself … just because there will be good reasons to do it in one way or another … (even if the good reason might just be to adopt to the API structure of the most widely used proxy … mid to longterm everyone looses with non-standardized http proxies … short term I think it probably makes sense to go different routes in parallel to see the good the bad and the ugly …)
I think its fantastic that there are 3 proxies because there is 3 skilled people thinking about this, 3 skilled people doing very smart things on the left and bad ideas on the right and you can all learn from each others mistakes and each others genius approaches.
100% and when we get our network bugs out of the way the whole focus of improving etc. will move mostly to app devs. They are the new vanguard of this project and there time is coming. This is when things should really start to happen.
I think we might get somewhere with this
with the notebooks I can make some simple examples and tests and with the IDE I can do the “real programming” and testing in production environment
…
…