[tor-project] Rhatto's Monthly Status Report, September 2024
rhatto
rhatto at torproject.org
Wed Oct 2 12:32:07 UTC 2024
Hi all :)
This is my monthly status report for September 2024 with the main relevant
activities I have done, was involved or are related to my work during the
period.
For other Onion Services news, check this post:
https://forum.torproject.org/t/some-news-from-the-onionspace-2024-09/14963
# Planning
Helped with the overall planning for the upcoming Onion Service tooling
development.
It allowed me to figure out priorities, and finally clean my backlog.
This also resulted in creating an Onion Services feature matrix
comparing Arti and C Tor:
https://onionservices.torproject.org/dev/implementations/
The current plan is summarized below.
## Oniongroove - next generation onionsite manager
Project page: https://onionservices.torproject.org/apps/web/oniongroove/
Plan: have Oniongroove acting as a middleware, abstracting specifics from the
underlying Tor (and perhaps the HTTPS rewriting proxy) implementation.
Advantages: it might be easier for Onion Service Operators to adopt
a tool supporting both backends. They can start using the C Tor backend
and later on switch for Arti, eg. once the needed feature set becomes
supported.
Current goals:
* Goal 1: support both C Tor and Arti as backends (prototype).
* Goal 2: feature-parity with Onionspray, for the C Tor
backend (taking some onionsites we manage as a reference for
the requirements); migration procedure from Onionspray (production-ready).
## Onionspray - current onionsite manager
Project page: https://onionservices.torproject.org/apps/web/onionspray/
Current focus:
* Keep supporting Onionspray until there's feature parity with Oniongroove,
plus a migration procedure.
* Merge requests are welcome :)
## Onionbalance - load balancer for Onion Services
Project page: https://onionservices.torproject.org/apps/base/onionbalance/
The road mapping discussion for Onionbalance is still ongoing.
Meanwhile, my focus would be to keep the software working, and going through
issues and MRs when doable.
It's still uncertain how load balancing with Onion Services should be done
in the long term, since:
* Proof of Work (PoW) Support in Onionbalance is still in the
discussion phase:
https://gitlab.torproject.org/tpo/onion-services/onionbalance/-/issues/13
* A replacement built-in directly on Arti still needs design; it will possibly
be based on changes in the descriptor; a publisher node would be way simpler
than the current functionality. There's still no timeline for that.
On the other hand, Onionbalance is basically a descriptor publisher. So,
roughly speaking, migrating away from Onionbalance to an Arti-equivalent
implementation won't require Operators to migrate all their C Tor setup to
Arti: they could just replace their Onionbalance instance with something else
and keep all their backend onionsites with C Tor for a while.
That said, depending on the design changes to implement PoW, it would still
be needed to backport this feature to the C Tor backends and clients, which may
not be a lot of stuff (possibly just descriptor changes).
In summary, one way to move forward could be (but these are still only
speculations):
1. Creating a spec for PoW with descriptor-based load balancing: this seems to be
mostly about (new) descriptor field(s).
2. Evaluate/scope what would be needed to:
* Implement this both for Onionbalance. Maybe it's just a few changes...
* Implement this on Arti. That involves implementing the whole load
balancing feature.
* Backport the changes needed on C Tor both for backends and clients.
3. Then we could decide whether to do it for Onionbalance to win time, or
just skip it in favor of a migration.
## Onionprobe - monitoring tool for onionsites
Project page: https://onionservices.torproject.org/apps/web/onionprobe/
Current focus: properly set the Grafana dashboard within Tor Project:
https://gitlab.torproject.org/tpo/onion-services/onion-support/-/issues/93
Support for the Arti backend was postponed to future (2026+), after Arti's RPC
is stabilized. This is being tracked at
https://gitlab.torproject.org/tpo/onion-services/onionprobe/-/issues/86
There are lots of ideas for improvements, that may be implemented
opportunistically.
# Documentation
Did some documentation updates, including:
* The Certificate Proposals page:
https://onionservices.torproject.org/research/proposals/usability/certificates/
* Some roadmap scenarios (but these still need more work):
https://onionservices.torproject.org/research/scenarios/ux/
https://onionservices.torproject.org/research/scenarios/network/
--
Silvio Rhatto
pronouns he/him
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20241002/9d87ee65/attachment.sig>
More information about the tor-project
mailing list