I like this idea, for several reasons. For one thing, I think the flow
sounds intuitive and convenient for the users. Just open a link in your
browser and you're setting up a new outproxy. That sounds great. I also
like that they aren't intrinsically mappable, while I understand Tor's
position on the matter, FaF outproxies are definitely not Tor exit nodes
and I think our position should be different, or at least flexible, on
I also like it because it's fairly easy to replicate in my BYOB
webextension, since I'm already picking a proxy based on a container, I
could as easily pick a proxy based on a URL as well and select an
outproxy for non-i2p resources, and using a link to configure one or
more outproxies or even do a round robin is a fairly tiny leap.
In terms of the implementation, I would like to see an 'add' form of the
link and a 'remove' form of the link, and that the users should probably
be able to use multiple outproxies but I don't think round-robin is the
way to go, I think each tab should use the same outproxy for the
duration of it's lifespan, but if multiple outproxies are configured,
different outproxies should be assigned to each tab upon creation.
Inside the context of the tab, be consistent with the exit.
Those are my late-night thoughts on the matter, I'm sure I'll have more
in the morning. Peace
For the last topic from me today, I want to talk a bit about outproxies
which I also hope we would get some good discussions around. And I'm
thinking towards a world with multiple outproxies in the i2p network.
But, please discuss with me if you think I'm wrong, but we need a good
user-friendly way to share those outproxy addresses unless we want to
implement a automatic system for it on a lower level which I doubt we
want at the current stage.
So, that would leave us with I2PTunnel, web or not. And from my research
I think it's maybe only the webapp that has outproxy capabilities, at
least I couldn't spot a option for that in the CLI. Anyhow, doing some
XHR CORS magic to control the I2PTunnel webapp is probably not the right
path either, which then leaves us with a option we have from our friends
My suggestion is therefore that this magic share outproxy link is handled
on the browser level, making the browser the manager and controller of this
router feature, and which updates the I2PTunnel app via rewriting the
i2ptunnel.config according to the new outproxy changes or go back to a
default i2ptunnel.config depending on what the user wanted.
We can also learn somethings from Telegram which has battled Putin's
censorship lately. It at a early stage was clear that for Telegram to
survive in Russia, a lot of proxies was needed, but Telegram couldn't
have public listed proxies since the Russian government would obviously
just block them, so they invented a URI for sharing such.
That's a example of a link that will autoconfigure the Telegram client
to use one of my outproxy servers as proxy before making contact with
Telegram servers. In the Telegram client you can also show a image that's
just the link in QR encoding sized for a mobile camera to snap it up.
Anyhow, I think we should learn from this and take a step in the same
direction, in which our outproxies won't be mappable like Tor's are
for websites to block if they wish and so on. If that's a good or bad
thing can be a separate discussion.
What I would love to discuss and see more opinions on are how we
could addopt a such system. Do we only have one type of link that
just adds a new outproxy to the list? or does it remove the current
one? Should the users be allowed to have multiple configured at once,
doing a round robin on them? Now that I've written a HTTP(S)+SOCKSv5
proxy server, should we still stick to only HTTP(S) or expand to allow
more protocols with a SOCKS endpoint like Tor does?
I'm excited to see what we can make here and what the result could be!
-- Unless you're a developer or really cares about implementation details,
you're done reading this mail now. Everything bellow would just make you
fall asleep or something. :)
For implementation concerns; Mozilla's IO guides/docs where you can learn
is attached at the bottom of this mail.
Moving, Copying and Deleting Files:
Working With Directories:
Directory management like creating new ones didn't have as bad API
as expected, in fact it's much better than expected. Here is a
exmaple of checking the existence and based upon result creates
the directory if needed.
var dir = IO.getFile("Desktop", "myfiles");
Files are usually of the nsIFile interface, which we also gets
to know when implementing the management code of the i2p child
router process that the browser should launch.
Mikal / Meeh
I2p-browser-dev mailing list -- i2p-browser-dev(a)lists.i2p.email
To unsubscribe send an email to i2p-browser-dev-leave(a)lists.i2p.email