eosrio / bp-info-standard Goto Github PK

Add 'medium' as a valid social. medium.com/@

example: https://medium.com/@eosnationbp

Some people are already publishing bnet_endpoint even though that is not defined in the specification. Please add this new type of endpoint.

What do you think about adding testnets info to the bp.json?

testnet_nodes: [
   "jungle" : [{},{}],
   "ghostbusters" : [{},{}],
   "scholar" : [{},{}],
]

Each bp can serve a different bp.json for each testnet as well, however I think it convenient to have them all in one place.

Add 'discord' as a valid option for social.

The attribute "node_type" is not described in the readme documentation. What value types are expected for this key?

Related to the comment here: #7 (comment)

If producer_public_key serves a purpose for voting tools, then please close this issue with a description. Otherwise, let's remove it.

I propose that we create a standard location object such as

{ 'name': "London', 'country': 'GB', 'latitude':0.1, 'longitude:50 }

Then we can create a top-level org object which has location as a property. Each node could also have a location attribute so that geospacial data is consistent

We have published bp.json on Blockchain.. But where is miss-match? What is not matching? More specific information is needed...

Currently we are experience an increase of API services being introduced to Antelope chains.

Therefore we proposed to add the following services to the standard, namely:

• "light-api"
• "ipfs"

What do you think of the proposal?
When can we expect those services to be added to the documentation?

Based on a recent conversation with a BP ratings group, the idea of linking to useful projects came up which makes a lot of sense to me. It would still be up to the community to evaluate that BPs level of involvement in the project or how beneficial that project really is to the greater ecosystem, but I think it might be an interesting way for BPs to quickly communicate to others what they are into. Yes, their website will probably do this also, but having it part of the BP.json standard would help others quickly aggregate this information in a useful way for voters.

What do you think?

The dfuse team has created a new type of endpoint called the "firehose". Please add new feature to support this.

Documentation can be found here: https://github.com/dfuse-io/playground-firehose-eosio-go

It is unclear if the producer_public_key is the account active key, the account owner key, the block signing key or some other. Would be good to clarify.

Given that a BP should have more than 1 technical contact, github_user should also accept an array of multiple users. Single user (as a string) as currently defined is ok too.

RFC5785 is internet standard for defining well known machine discoverable URIs
https://tools.ietf.org/html/rfc5785

We should do something like
https://bp.org/.well-known/eos/chain-id/bp.json

My bp.json currently fails the schema validation. See screenshot, I believe the schema is incorrect, node_type should be an object not an array.

We have 4 node types. It is not clear what is the definition for each. This is what seems to be in use today:

producer: for producer nodes. the actual end points should not be published
query: for nodes you can query with http or https
seed: for nodes you can connect on p2p or bnet
full: both query and seed

However, there are some thoughts that 'query' is useless and the definition i put for query should be used for 'full'. Thoughts?

Would be great to also have a link to a BPs code of conduct.

Provide list of country code being followed. For example https://en.wikipedia.org/wiki/ISO_3166-1_numeric

Related to #7

If we allow qualification of the producer public_key as suggested in #7 , we would make it practical to also include an optional signature field to the file to attest authenticity.

The json representation should be stringified in a canonical / deterministic manner, then signed with the private key associated to the account with active permission.

This would make the standard more solid and protect against spoofing, impersonation, phishing attacks, etc... as people will start relying on them more and more.

Can you please help us formulate a nice standard to include IBC in bp.json?
Does it actually make sense to include it?

Michael from WAXUSA can support on this.

@igorls

The readme specifies that port numbers should be specified on API endpoints:

api_endpoint: EOSIO HTTP endpoint http://host:port
ssl_endpoint: EOSIO HTTPS endpoint https://host:port

However, when it is a standard port (80 or 443), the normal convention is to leave it off, when it is the standard port (https://tools.ietf.org/html/rfc3986#section-3.2.3)

So should the readme be amended to follow RFC 3986 convention or we always want the port number?

The validator at https://validate.eosnation.io currently follwows RFC 3986, which is not aligned to the documentation.