RE: An EOS Smart Contract for Block Producer Information
From our Telegram chat:
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)
I didn't see this conversations, but my opinion is that this contract isn't for node discovery.
Node discovery itself shouldn't even be on chain - since you'd need to connect to the chain to even access that data. It's a bit redundant, and if you're already connected, why would you need to discover more nodes?
This contract itself I feel is just about publishing the bp.json data on-chain - so that way the many wallets and web apps who need this information don't have to scrape 100's of websites.
I agree scraping 100's of websites doesn't make sense, but the pushback I'm getting from my team relates to the lack of a clear standard and the potential to have to support every backward compatible solution we introduce from here until whenever. If more people use this, will they also continue to support the website based bp.json file? If a full standard is developed in the future which puts this data directly into tables instead of as json, will that then be a third approach (with two legacy approaches to support)? That, I think, is the primary pushback I'm hearing from my team. A desire to plan out good specifications first, before introducing temporary solutions which will then need to be supported in order to not break applications which start to rely on them.
Unless we think the bp.json approach (both on the web and stored on EOS) is the solution the EOS community should be using for quite some time? I mostly agree with you that this is a good improvement on what is being done now, but I'm doing my best to relay concerns my team has to hopefully find some common ground. Maybe it's okay that app developers just have to change things as older methods go away naturally, but I think some prefer more structured, planned approaches and assurances that when we introduce a new approach, we've thought through if this is the best solution for the problem we're solving.
If this isn't for node discovery, then the current bp.json hosted on websites were were provided via listproducers still seems to be needed. If that's the case, is this data duplication?