Eos: Add a discovery_url to regproducer to facilitate launch and.. discovery.

[abourget]

Right now, there is nothing in chain to identify more information about producers, like their main website, a way to p2p connect to them, some rpc endpoints to reach them, a support email of some sort, a PGP key to transmit messages securely, etc.

I propose adding a "string" typed "discovery_url" to "regproducer".

A sample of my proposal lives here: https://github.com/eoscanada/network-discovery/blob/master/sample-mainnet.yaml

This will help a lot in the launch to discover where producers are, and will give them the control to modify that info at will.

Right now much of this is in the bios launch file, but it would be better hosted by the BPs. It could easily live directly on github through a raw gist URL or whatever static hosting.

[abourget]

We could/should add also: "logo_url_1024": "https://example.com/logo1024x1024.jpg",.. perhaps also some smaller logos? "logo_url_256"

[roelandp]

The whole ideo of the EOS chainsoftware IMHO is to be as 'generic' as possible by leaving out as much as possible, like these hardcoded variables you suggest.

If you look at the producer_object https://github.com/EOSIO/eos/blob/1e5e1f96571cce3fc29ea6ef265a6c2342983b96/libraries/chain/include/eosio/chain/producer_object.hpp#L12 it is very simplistic / bare minimum setup not even containg a 'shared_string 'url') which steem still has (which is the discovery url you mention and an additional custom_json part in the account_object open to any datastring storage), leaving it up for modifications / add-ons on a higher level, for example through a dapp / contract abi.

One could make a dedicated BP Introduction DB storing this kind of data you suggest, which might be a good thing. This way it would still use the chain for storing the (/any) data but not interfere with the strictness of the functionary setup of the software itself.

[abourget]

I'm not sure I understand all your points.

There are many DBs here and there, all with unstructured content about BPs. I suggest a minimal change to the chain, adding a URL, and am proposing a few standard keys for the community to adopt. The json keys wouldn't be on chain or part of eosio software.

[abourget]

Being a URL (and that data not being on chain) means it survives test at reboots, works across testnets, and most importantly, works before mainnet launch.

[abourget]

We should add a "timezone" also, with the standard in here: https://en.m.wikipedia.org/wiki/List_of_tz_database_time_zones

Do not reference deprecated zones :-)

[noprom]

This idea is great.

[ellipticasec]

If we are to point to some out of chain resource (like https url to larger JSON) is should be accompanied by a SHA256 fingerprint of that off chain resource.

IPFS would also address that scenario but we need something short term for launch.

[abourget]

The goal is to allow people to change it without affecting the onchain config. I don't see a point in hashing it. Not at this stage. This is basically deferring the authority to the DNS system.

[abourget]

Updated the desc to point to the network-discovery repository.