May 2026 - tor-relays - lists.torproject.org

Re: Reducing ContactInfo to the family ID level
by DTMF dont.track.my.stuff 10 May '26

10 May '26

Hello together, thank you for raising the idea. As far as i understood - defining some kind of data attributes centrally which are unique on family level is causing more struggle in usability even if there could be a slight benefit in reducing the general payload. ////////////////////////////////////////// Single Point of Truth /////// I see a potential down side in the definition of the central point of truth. It could be one relay of the family. But when a single relay is holding that information and that relay disappears or is compromise, the information could be lost/altered. Are there any other location (non-torrc) where that information could be included. Maybe some functionality that could be added by the TOR-Project themselves instead of having workaround with third party specs like CIISS. ////////////////////////////////////////// Levels of relevancy /////// Furthermore i see different levels of relevancy. - FamilyID / HappyFamilyID Level - vServer Level (Multiple Relays) - Relay Fingerprint Level The ContactInfo (according to spec ciissversion:3) can contain also data attributes (hoster, ram, etc..) which are only relevant on Relay Fingerprint Level, or even vServer Level (multiple relays). That means when we will end up in a hydrid-state anyways. All relays would contain their specific (Relay Fingerprint Level ) data attributes in the ContactInfo field - only one relay would have have the additional information. I also like to understand which data attributes of ciissversion:3 you are specifically talking about. @NUSENU Is it only about these - that you want to markup centrally? (1) email: (2) url: (3) proof: Kind regards DTMS - dont track my stuff

1 0

Mangled metrics and more
by Ralph Seichter 08 May '26

08 May '26

I am currently looking at a relay's data on metrics.torproject.org. It is still listed as "first seen 31 days ago" although it has been active since the second half of 2025. Was this not supposed to get fixed for all relays? More importantly, over the last four weeks the amount of traffic routed through this node has dropped sharply, to less than half of what was in March 2026. Consensus weight has dropped significantly as well, which I assume is connected. The relay is online most of the time, with brief interruptions in the form of reboots about once a week. It uses the latest available version of Tor. I do not know what could cause this massive decline in node usage. Perhaps someone here can enlighten me? -Ralph

1 0

OneProvider using now Scaleway AS
by DeuZa 05 May '26

05 May '26

Hi everyone, Until now, I’ve been managing three exit nodes with OneProvider (WIIT), which is generally considered Tor-friendly. But apparently, they’re now working with ScaleWay, and my fourth server in the Netherlands—which I’d just set up—was suspended in less than 24 hours, and I have to pay $100 to the UCPROTECT mafia... I just wanted to let you know that they’re now using AS12876 (Scaleway SAS), which is already well known... As for me, I’m switching to maxko-hosting -- Alain alias DeuZa alias 0x2A

3 5

The tor-realay-list and the tor-ddos project will soon go down
by Chris Enkidu-6 03 May '26

03 May '26

Due to a serious Illness Soon I will not be able to maintain that list anymore. Without that list the Enkidu-6 Tor-DDOS iptable lists will become useless because they all point to the tor-relay-lists. I'm looking at someone established with enough resources to maintain that list and I'd be glad to offer them the source code for how I get that list. You'll just need to associate your PGP key with your Github account and hopefully have at least two separate servers to run the Cron job on. Any dedicated takers please let me know. The whole thing will go down in probably a couple of weeks. Thank you all for taking the time to read my post.

3 2