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

[Iain R. Learmonth]

Hi,

On 15/10/17 09:07, nusenu wrote:
>> 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.

It would be interesting to see how many relays currently have
bitcoin/zcash or similar addresses in their ContactInfo fields.

> 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

This is true.

> 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).

Perhaps then we can use the fields that people choose to use as an
indicator of which ones we should progress to proposals for changes to
the descriptors.

I would suggest though that if these do catch on, perhaps proposing an
AdditionalInfo field as a catch-all field to house future properties
until they can be formalised to avoid doing too much with the
ContactInfo field?

Thanks,
Iain.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171015/420a90e6/attachment.sig>