GSoC.md

@@ -3,6 +3,47 @@ The following is a page to help with GSoC / SoP / Outreachy coordination.
 
 # GOOGLE SUMMER OF CODE'S PROJECT FOR 2022
 
+## Tor Weather
+
+### Problem
+
+If a relay disappears today, it is unlikely that anyone will notice or even send an email to the operator.
+
+The entire Tor network would benefit from a "Tor Weather" service to notify relay and bridge operators when the state of their relays has changed. This has a number of benefits, including:
+- increasing the likelihood that relay operators notice problems and actually mitigate them.
+- showing relay operators that someone actually cares if their relays go down or become outdated or have other problems
+- giving relay operators information about best-practices, e.g not running outdated versions, fixing their DNS, etc...
+
+Right now, there is very little direct feedback given to relay operators. This can mean that operators become discouraged and stop running relays.
+
+### Proposal
+
+This project would involve the implementation of an email notification service that relay operators can subscribe to and choose which notifications they want to receive about their relay. 
+
+This project already existed and was known as "Tor Weather". It was unfortunately discontinued due to lack of maintenance and resources to keep the project alive. However, we think that this is still a great idea and the most efficient way to achieve and maintain a healthy Tor network on the long run. The resulting service should conform to our current styleguide. 
+
+There is a repository, maintained independently from the Tor project, with code that can be reuse and expand for implementing this proposal. You can find it in https://github.com/thingless/torweather/ . 
+
+This notification service should support subscribing via single relay fingerprint or MyFamily groups. Additionally, it should not need any subscription change if a new relay gets added to the family. As this service would store email addresses of potential tor relay operators, they should be kept private and safeguarded. However, a passive observer can collect them by watching outbound email traffic if no TLS is used. As such, this service should suggest using a dedicated email address for this service.
+
+Once a basic email notification service is implemented, these are some ideas for potential notification types that could be implemented within it:
+
+    Email me when my node is down - Here we should decide how long before we send a notification?
+    Email me when my relay is affected by a security vulnerability
+    Email me when my relay runs an end-of-life version of tor
+    Email me when my relay runs an outdated tor version
+    Email me when my exit relay fails to resolve hostnames (DNS failure)
+    Email me when my relay loses the stable/guard/exit flag
+    Email me when my MyFamily configuration is broken
+    Email me when you detect issues with my relay
+    Email me with suggestions for configuration improvements for my relay
+    Email me when my relay is on the top 20/50/100 relays list
+    Email me with monthly/quarterly status information, e.g what is my position in the overall relay list, how much traffic did my relay do during the last month, etc...
+    Email me about new relay requirements
+    Email me about tor relay operator events
+
+For each notification implemented, there should be a corresponding specification written to describe the meaning of each notification type.
+