Hi,
I'm happy to announce version 2 of the ContactInfo Information Sharing Specification.
https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/
It comes with an easy to use ContactInfo generator, which is maintained by Eran Sandler: https://torcontactinfogenerator.netlify.app/
Example ContactInfo string as defined by this specification:
email:tor[]example.com url:https://example.com proof:uri-rsa uplinkbw:100 ciissversion:2
In words this ContactInfo string means: - the technical contact for this relay can be reached at tor@example.com - the entity responsible for this relay has a website at https://example.com - the proof file to verify the url can be fetched from https://example.com/.well-known/tor-relay/rsa-fingerprint.txt - this tor instance can provide a bandwidth up to 100 Mbit/s - this string implements version 2 of this specification
The spec has many fields to choose from but I'd like to highlight these 3 fields, also used in the example above, as some of the most relevant:
- email - url - proof The proof field allows operators to make their URL value verifyable (protected against spoofing) by placing their relay fingerprints in a text file located on their website. If no website is available DNS TXT records can be used instead.
Now that version 2 is out, we will work on parsing to provide operators with an easy way to check their strings (and maybe also their proofs) interactively.
I intend to use the data as input for OrNetStats as operators start to set their ContactInfo strings. I have operator-level graphs in mind, showing the operator how his set of relays evolved over time. See https://raw.githubusercontent.com/nusenu/tor-network-observations/master/png... for an example. The timespan will likely be significantly smaller than the one used in this example.
The release of version 2 marks the deprecation of version 1. I aim to support version 2 for at least 2 years and aim to make future releases backward compatible. I've no plans to significantly change or extend the amount of fields, with the exception of one potentially interesting use-case (see the bottom of this email).
Many changes that went into version 2 are directly related to your comments after publishing version 1, thanks for that!
We also got feedback for the generator and are tracking them here: https://github.com/erans/torcontactinfogenerator/issues
Changelog ----------
Most notable changes since version 1:
- 'operatorurl' got renamed to just "url"
- "verifyurl" field simplified/replaced with "proof" (no longer requires a webserver)
- email field is no longer mandatory - UTF-8 support - xmr (monero) field added - bitcoin field renamed to btc - zcash field renamed to zec - PGP keys should be on keys.openpgp.org (verifying keyserver) - removed fields: KIST, ricochet
Future Idea
Since some had concerns about spam: It would be trivial to add support for an encrypted email address when the operator has a webserver and a verified url field. If there is some demand for this and the Tor Project is willing to publish a GPG key that can be used for encryption I'll add support for it. That would mean only the persons at the torproject having access to that key could fetch the encrypted address and decrypt it with their private key, others would only see "encemail:y" or similar.
kind regards, nusenu