- tor-relays - lists.torproject.org

AROI Validation vanished due to ciissversion:3 on 1AEO Metrics
by ProSecureRelays 15 May '26

15 May '26

Hey there, is there any information out regarding the AROI-Status and the trasisition from ciisversion:2 to ciisversion:3? I was proud having it all setup, but then I followed the advice on creating an ed25519 key and added the proof in my github page. The setup was done correctly as far as I can see, however, this led to loosing my AROI Status :'( . I'm happy if someone sees my fault or has a clue what to do now to get the AROI back. Of course it would be easy to just revert the change to the contact info, but the must be a "Go-Live" when the ciisv3 is the desired value? Best regards, Joker P.S. What I also noticed - I have only one relay, but since I configured the ed-key, there was a notice in the tor log that MyFamily Descriptor is still needed aswell. [warn] FamilyId was configured, but MyFamily was not. FamilyId is good, but the Tor network still requires MyFamily while clients are migrating to use family keys instead. As with one relay, I didn't see the benefit, but added the fingerprint as desired with the MyFamily Option. The warning is gone since then. Additionally I also lost my "First-Seen" Date when doing the change to v3. But I heard this is already under investigation. Picture 1: Happy Family Cert is installed and valid. Picture 2: 1AEO stats claims missing ciisversion:2. Picture 3: On the Page from Nusenu (OrNetStats), I still see myself as verified, but the update rate is quite low. This reflects the data before the change.

3 4

Reducing ContactInfo to the family ID level
by nusenu 14 May '26

14 May '26

Hi, since we have a significantly less cumbersome and much less error prone way for tor relay operators to self-declare their relay groups using the Happy Family design I was thinking about whether we actually need ContactInfo at the relay fingerprint level or if we only need it at family ID level? The idea: - only a single relay in a family publishes a ContactInfo that is valid for the entire family benefits: - easiers ContactInfo management for relay operatos not using configuration management, since they only need to update a single config - less redundant information in relay metadata that gets received and distributed by tor directory authority - significantly smaller onionoo details files downsides: - no "backup channel" in case software has Happy Family related issues - like we saw in collector/onionoo - less flexibility you want to have different contacts for different servers I do not expect that rust-based tor relays - that hopefully significantly reduce the number of tor daemons an operator has to run to make use of multi-core CPUs will take over the tor network soon. So this will remain a relevant question for the time being. This topic is limited to relays and not bridges until bridges fully support Happy Family. If there are no strong reasons for relay level ContactInfos I might implement the idea in a minor variation in ansible-relayor: only a single tor instance per server will get a ContactInfo torrc entry. The CIISS spec would also be updated to reflect that. kind regards, nusenu -- https://nusenu.github.io

3 2

What's wrong with geolocation here?
by Dennis Bronk 13 May '26

13 May '26

2 2

Quetzalcoatl relays - Loss of may exits with immediate effect
by Dr Remmiz 13 May '26

13 May '26

Hi, I thought I would write to let you know that I have just lost all my servers - all exit relays, that were part supported and sponsored by rdp.sh. They had very kindly supported and sponsored many of my exit relays over the past several years. Rdp.sh made the decision to drop all my tor exit traffic after repeated and numerous Spamhaus listings. These had recently been forwarded to their upstreams who are now starting to cut their lines. This is with immediate effect as of several hours ago - and instead of 760 exit relays, I shall now be serving only 160 exit relays. I apologize for this disruption in service, but unfortunately it is out of my control. I shall endevour to rebuild some of my server pool, but this may take some time, and finding someone to help sponsor some of the servers I run will likely be difficult, and finding such a good provider as rdp.sh was, will also I believe be difficult. If anyone has any suggestions which may help, I'd be happy to hear them. Thanks for utilizing my server pool over the years. Regards, Zimmer

2 1

Tor-ddos project is now dead
by Chris Enkidu-6 12 May '26

12 May '26

On my last post to the group I mentioned a serious illness. unfortunately I should have said a terminal illness. I probably have a couple of weeks.Since my original post I really had no legitimate offer from anyone to take it over. Just a few time waster conversations that went nowhere. So as of now both tor-ddos and tor-relay-lists are down. Sorry to do this but I have other things to worry about and since only a limited number of people on this list know about it. Others can judge me however they like. Thank you for reading this.

7 7

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

confirming onionoo/CollecTor issues vs. Happy Family relay misconfiguration
by nusenu 29 Apr '26

29 Apr '26

Hi, I've been contacting relay operators to verify suspected CollecTor/onionoo issues that appear since CollecTor got replaced in early April. To scale a bit better I'm sending this email to the tor-relays list + BCC instead. In most cases so far it turned out to be an onionoo issue but I see some slow improvements. If you are one of the operators listed below it would be great if you could help verifying your config and confirm if - this is indeed an onionoo issue (all your relays found by the onionoo URL below should have the same Happy Family configuration but according to onionoo do not) - or an inconsistent Happy Family configuration on your side: not all your relays have Happy Family configured (not an onionoo issue) - they are not actually your relays - in this case you can report them for removal to the bad-relays team if they use your contact information With your help we can get a better overview of the current onionoo / CollecTor situation. I noticed unexpected (missing) family_ids on relays using this CIISS url value: alxu.ca doedelkiste.de germancraft.net torix-relays.org tuxli.org for-privacy.net emeraldonion.org www.1aeo.com example onionoo URL for doedelkiste.de: https://onionoo.torproject.org/details?contact=doedelkiste.de&fields=family… You can simply replace the contact parameter value with your domain. You should be able to spot suspicious lines in the output because these lines are shorter (no family_ids string included). thanks for your help! nusenu -- https://nusenu.github.io

2 2