From <a href="https://t.me/EOSPros/48611">our Telegram chat</a>:

Luke Stokes, [Jul 20, 2018 at 12:30:20 PM]:
Looking at this and discussing it now. Curious your thoughts on having a seperate table just for endpoint discovery? I'm getting a little pushback in terms of the workflow for a wallet to download all the data just to get the endpoints is a bit much. We created this file (updated every 10 minutes) to help: https://eosdac.io/topnodes.json

but I'm curious your thoughts on using multiple tables with straight data instead of just one json file

we also craated https://eosdac.io/topbps.json (also updated every 10 minutes)

on chain is a much better approach, for sure, but having everything in json may not make sense if someone just wants the nodes

Scott (anyx), [Jul 20, 2018 at 12:32:15 PM]:
Not really sure a seperate table is needed; you could parse the json from the producerjson table and grab as many endpoints as you need. 🙂 
I briefly explained in the post why I don't think mutliple tables is the best idea; the BP standard is likely to change over time (possible rapidly), and validation should be clientside.

Luke Stokes, [Jul 20, 2018 at 12:34:06 PM]:
I only see this:

> as well as allow quick changes to the BP standard format without a contract update.

But not much mention of the downsides of multiple tables (one for nodes, contact info, etc)

Maybe staying in json for now makes sense to keep a fluid, dyanmic standard as it's developed, but more and more I'm thinking we should be taking RFC approaches to do the hard work up front of defining a set standard

instead of assuming it will change later (and thus lead to breaking apps)

Scott (anyx), [Jul 20, 2018 at 12:36:20 PM]:
The big downside for multiple tables (at this current time) is the standardization efforts. Right now it just takes a json blob, and external validators can determine the convention.

In my opinion the transition to this will be much easier than conforming to a new standard, and we can change things over time if desired.

It's literally a one-liner cleos command to put your bp.json file into this table, so hopefully this gets traction.

Luke Stokes, [Jul 20, 2018 at 12:38:30 PM]:
What about the costs associated with wallets and apps having to change things, potentially multiple times? If they are pulling json files now, then they change to pull on chain then later they change to pull from individual tables once a standard is defined. In the meantime, how do we decomission old, legacy approaches? that could prove to be quite difficult. There is a cost associated with supporting approaches now which may become legacy in the future.

Scott (anyx), [Jul 20, 2018 at 12:39:08 PM]:
This is true regardless of using seperate tables while the standard is changing

Luke Stokes, [Jul 20, 2018 at 12:41:37 PM]:
I think that's kind of my point: Wouldn't it be better to do the work of figuring out a standard first? That way we have fewer changes all around and we remove one change in this cycle: pull json from web, pull json from chain, pull data you want from chain

(btw, I'm partially pushing back just based on push back I got from my own team. I think your idea is a great improvement on what we're currently doing)

Great job Greymass! This is a great approach to store Block Producer bp.json on chain. Looking forward to see more Block Producers host their bp.json on chain!

I fully support this initiative. We should store BP information on Blockchain instead of relying on off chain web sites.
My only feedback is to add JSON validation to smart contract (if possible) to make sure we are storing valid data on Blockchain. 

@EOSTribe published it's bp.json on Blockchain as well!

A really good idea and it works perfectly, good job.   I've [added](https://bloks.io/transaction/db246d289568b7e951437b60d263c4ee52337def7e7c317a379dc14211e26142) the @blockgenesys bp.json file to the table.

sweet initiative. tip of the hat from EOS Romania.
thanks to this eosromania22 bp.json is now on chain

This is huge.  The EOS community has been waiting for something like this.  Thank you for putting this together.  Greymass rocks!

Hello you are keep changing this with high pace... And I understand that it takes time to mature... Security is a continuous improvement process.  But are you involving all block producers or just few hands are involved in changing parameters and validation process... We are already too afraid to give lot of power to top 21 block producers ad we hope that their should be **INDEPENDENT VALIDATION** process.... and **Future Contract Changes** could be managed by **INDEPENDENT VALIDATORS**, **NOT** by top 21 BPs..

This works especially well on mobile, one call to chain/get_producers and another call to getTableRows->producerjson and we have a filtered list of eligible block producers and their information.