Data Ring: Problem Statement

According to the Denver notes, we agreed that the problem we’re trying to solve is:

Its difficult to get the data out, and also to get the data in

A couple of questions for discussion:

  1. Does the above description capture what we’re trying to solve? (Here’s notes from the Prague data ring. There are some concerns voiced there.

  2. Would it make sense to break into two different sub-rings? Data Extraction / Oracles? (This issue came up in the ring discussion.) I think maybe we should have two subrings.

  3. Should there be a third subring: Data Delivery. (This might include data marketplaces, IPFS delivery, Web 2.0 server/API delivery, others)

Please discuss the issue of the ring’s “Problem Statement” What are we trying to solve?

1 Like

Question 1.

I think that the problem statement or “mission” might mention additional pain points, data use cases, main stakeholders in this.

So something like:

“Making use of data is key to using the Ethereum network, whether it originates from the blockchain itself or from other sources. End-users, dapp developers, and network operators are stakeholders in valuable data use cases and this Ring aims to understand and address their pain points.”

Question 2.

As for side Rings … side is better than sub :slight_smile: … perhaps let’s see which of these further topics stick.

Query Interface / Underlying Data
Provider Infra / Running Nodes
Oracles / External Data
Data Verification

Question 3.

Yes, but as with the others, we need a champ.

Also, would Data Ring be involved with maintaining JSON-RPC?