On Sun, Jun 30, 2019 at 02:12:49PM -0400, tor wrote:
I've been running an obfs4 bridge for about a month.
Thanks for running a bridge!
My hashed fingerprint is: E120A0492F789F5367EAD84C64F92EE279018F98
I recently lost the stable flag. Not sure why.
I wouldn't worry too much about that flag -- it is not a big deal, either for relays or for bridges.
I just checked and your bridge appears to be listening on its obfs4 port, so I am guessing it is all working fine.
Bridges get the Stable flag if they're in the top half of running bridges based on their past mean-time-between-failure, i.e. how long they're expected to be consistently reachable between restarts. So if you were near the 50% mark already, and some bridges came back online that had higher MTBF, or some bridges went offline that had lower MTBF, that could explain it.
As far as I remember, the Stable flag is used in only one case for bridges: we try to make sure that at least one of the bridges in each answer from bridgedb has the Stable flag. You can read about it here: https://gitweb.torproject.org/bridgedb.git/tree/bridgedb.conf#n255 https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt#n216
Another reason I suggest not worrying about it is that I've always been a bit suspicious that we're not tracking MTBF and WFU (weighted fractional uptime) quite as we intended to: https://trac.torproject.org/projects/tor/ticket/19162#comment:5 and at some point somebody should investigate to see if there is a bug there, and in the mean time, stressing about it from the operator side will just lead to more stress. :)
Hope that helps, --Roger