[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] Using ContactInfo to publish additional relay properties in a standardized way (opt-in)



Iain R. Learmonth:
> The ContactInfo field doesn't need to be overloaded again. ):
> 
> See proposal 234 [0] for adding bitcoin/zcash/etc addresses.

Thank you for the pointer. This proposal is from 2014 and I havn't found
any trac ticket for it, so I guess no one is working on implementing it.
Once this is implemented I'll remove these fields from [1] if onionoo
includes these fields.

> Maybe we can work out new fields for extrainfo documents [1] that could
> contain some of this information.

While I agree that it would be nicer to have this as separate fields -
and this is the way to go on the long run (if anyone implements it) - in
practice this requires a lot more than people just changing their
ContactInfo string according to a specification:
- proposal(s)
- deployment of new tor version on the network
- tor code change (implementation)
- onionoo code change to parse new data
- atlas code change to display new data


Using ContactInfo does not require any tor/onionoo code change even
atlas is optional and relay operators don't have to wait for a new tor
version that supports it. They can basically start using it once the
specification for the format is done (<1month).


I see you played with a long (>5k) contact string already ;)
https://atlas.torproject.org/#details/A5B70A588FC01FAC572536B0BC35C7DD4252842A

[1] https://github.com/nusenu/ContactInfo-Information-Shareing-Specification
-- 
https://mastodon.social/@nusenu
twitter: @nusenu_

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays