Hello list,
we've been developing Onionbalance v3 for the past months, and I'm
pretty hyped to say that the project has reached a stability point that
could benefit from some initial testing by curious and adventurous
developers and users.
The project is not yet ready for proper use in actual production environments
(more on this later), but my hope is that this testing will reveal bugs that I
can't catch in my test environment and receive user feedback that will speed up
the overall process and allow a faster and more stable initial release.
This email features a pretty complicated pseudo-guide that if it gets followed
to completion it will hopefully result in a functional onionbalance setup.
As I said the guide is complicated and in ugly text format, so I suggest you
put on some calming music (perhaps some Bill Evans or some Com Truise or some
Tor) and go slowly. Trying to speed run this will result in disappointment and
perhaps even partial or total loss of faith in humanity.
== So what's the current status of Onionbalance v3? ==
The project lives as a fork of Donncha's original Onionbalance project in this
repository: https://github.com/asn-d6/onionbalance
The current status is that during my testing I have onionbalanced a real v3
service with two backend instances successfully for a few days with no obvious
reachability issues. It also works on a private tor network (using Chutney) for
hours with no issues. All the above happened on Debian stable and testing.
Also, here are some features that are currently missing but will be
included in the initial launch:
- This new onionbalance will support both v2 and v3 onion services, altho
currently v2 support is botched and only v3 will work for the purposes of
this testing. If you can quickly revive v2 support patches are welcome!
- Any sort of documentation about v3 mode (this post is all the documentation
there is for now!)
- Missing streamlined setup process (installation scripts, packages or
dependency tracking)
- Code documentation and unittests missing
- There is no daemon mode. You will have to run this in screen for now
- Fun bugs included!
Furthermore, v2 and v3 support will not have feature parity at the time of the
initial launch, and we will have to incrementally build these features:
- Cool v2 features like DISTINCT_DESCRIPTORS are not yet implemented so v3
cannot load balance as deeply as v3 yet (patches welcome!)
- There is no way to transfer your existing v3 onion service to onionbalance
(patches welcome!)
- There is no torrc generation for instances as in v2 (patches welcome!)
- It will be possible for clients and HSDirs to figure out whether a descriptor
comes from an onionservice vs a regular v3 onion. Making them
indistinguishable is possible but requires more engineering and will be left
as a TODO for now (see #31857)
Finally, there is no guarantee that configs generated with this pre-alpha
version of Onionbalance will be forward compatible when we actually launch the
project. This means that if you setup onionbalance v3 right now, you might need
to re-set it up in a month or so when the actual release happens.
tl;dr This is a call for experimental testing and it's meant to help the
developers and accelerate development and not to be used in anything remotely
serious or close to production. The actual release for operators and users is
coming in a month or so.
== Before we get started... ==
OK so let's assume that you still want to help out!
Given that this is a pre-alpha test I'm gonna assume that you fill the
following prerequisites otherwise you are gonna have an adventure:
[ ] Comfortable with git
[ ] Familiar with v2 onionbalance (at least in terms of terminology and how it
works)
[ ] Familiar with setting up and configuring (v3) onion services
[ ] Familiar with Linux (or in the mood to find weird bugs in other platforms)
[ ] Familiar with compiling C projects and chasing their dependencies
[ ] Familiar with running Python projects and chasing their dependencies
[ ] Patience to push through various import error messages that might appear
The above are not mandatory but if you don't check out all the boxes you might
encounter various errors and roadblocks that will frustrate. Actually... even
if you check out all these boxes you might encounter various errors that might
frustrate you.
== Some theory ==
In any case, if you want to learn more about the architecture of Onionbalance,
see:
https://blog.torproject.org/cooking-onions-finding-onionbalance
As part of this guide, you might hear me say the term "frontend" which is what
we call master onionbalance onion service instance (whose address clients type
on their browser), or the term "backend" which is the load balancing instances
that do the actual introduction/rendezvous work for the frontend. So for
example, in the visual below, Alice fetches the frontend's descriptor but does
the introduction/rendezvous with the backends:
