Great job! nusenu a écrit : > 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@xxxxxxxxxxx > - 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/operator-example-graph-2020-10-17.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 > > > > > > > > > _______________________________________________ > tor-relays mailing list > tor-relays@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays