all comments plz #17
all comments plz #17
Conversation
| The feed specification includes: | ||
|
|
||
| - Feed definition | ||
| - Owner key |
There was a problem hiding this comment.
Is this ed25519 or another scheme?
There was a problem hiding this comment.
TBC. Other options are available
| #### Feed definition | ||
|
|
||
| ##### Source definition | ||
|
|
There was a problem hiding this comment.
Probably add something like:
A source definition is an endpoint that can be queried, e.g. via HTTP, which returns a data structure that can be transformed to an on-chain datum.
| - as a json with base64 or base16 encoded `{body: <body>, signature: <signature>}` | ||
| - as a json with signature in the header (base64 or base16) | ||
| - as above but in bytes | ||
|
|
There was a problem hiding this comment.
TBD: Orcfax will store the specification and source message in archival packages as well as on-chain as datum.
| Orcfax can work with customers to tailor the needs of the definition. | ||
| Data collectors broadcast the results of their collection to validators. | ||
|
|
||
| Data collectors report the following errors: |
| The endpoints should be globally available, otherwise collection may fail. | ||
|
|
||
| Multiple endpoints are recommended. | ||
| Note that this is for redundancy: A collector will attempt to collect data from any of the endpoints, not all. |
There was a problem hiding this comment.
cos they ought to be giving the same data. Else we have a problem
There was a problem hiding this comment.
what if the customer needs a feed which aggregates data across multiple sources?
There was a problem hiding this comment.
I think this starts to get a bit too complicated
| It is up to the customer to communicate to downstream consumers | ||
| as to whether or not they ought to be verifying the full feed id (including version). | ||
|
|
||
| Orcfax must lay out some examples of feed definitions for customers to understand this stage. |
There was a problem hiding this comment.
Not only should we have an example definition, we should publish an example on-chain so that we can point to each of these components/steps
| owner: VerificationKey, | ||
| info: { | ||
| hot-key: VerificationKey (Scheme dependent), | ||
| source: [<HTTP_ENDPOINT>], |
|
|
||
| 3. What if there are multiple on-chain registrations of the same owner? | ||
|
|
||
| 4. What precisely is the point of the on-chain registration? |
There was a problem hiding this comment.
Is there a way by which registration also identifies the wallet from which funding will be extracted?
| If so, we need to parse the bodies and extract, say, signatures. | ||
| Which schemes and formats do we support? | ||
|
|
||
| 3. What if there are multiple on-chain registrations of the same owner? |
There was a problem hiding this comment.
Is it problematic if there is?
Most of the data should be different in info, shouldn't that distinguish between multiple registrations?
Should feed id be listed after owner so that registrations can be more easily distinguished?
| - Other members of the validator network can independently verify the signatures | ||
| and do not need to collect the data separately. | ||
|
|
||
| ### Open questions |
There was a problem hiding this comment.
Would this design allow for the publication of multiple feeds from one registration/definition?
eg if we constructed CER feeds in this way, would each pair need a registration?
There was a problem hiding this comment.
There could be some overlap with CER, but its not really what this proposal is trying to address. This proposal is trying to address the needs of individuals/ entities who want some specific data reported on-chain.
For such a product line, we need to be very narrow about what and how this is done. I dont think we can offer arbitrary levels of customization. For example. I'm sure there's lots of people who want "bridging": reporting data from other chains. but to do so, our collectors would need to run nodes ... its not feasible
| } | ||
| ``` | ||
|
|
||
| - A token is minted, with name equal to customers cold key |
There was a problem hiding this comment.
I don't know the term "cold key" "hot key" in either of these contexts. Is there a more idiomatic term?
There was a problem hiding this comment.
https://www.coinbase.com/en-gb/learn/wallet/hot-vs-cold-crypto-wallet-what-is-the-difference
roughly this.
Hot keys on a server
cold keys, not on any server.
| There are many open questions concerning how rigid or flexible this process ought to be. | ||
| Here are just some. | ||
|
|
||
| 1. Data source schemes: do we support json and bytes |
There was a problem hiding this comment.
Does Aiken support JSON? -- bytes can be okay as a value that is transmitted and then converted to bytes for publishing.
There was a problem hiding this comment.
Aiken accommodates what plutus can do, which is cbor with specific quirks
|
|
||
| 3. What if there are multiple on-chain registrations of the same owner? | ||
|
|
||
| 4. What precisely is the point of the on-chain registration? |
There was a problem hiding this comment.
Decentralization for collectors is one.
- what exactly does de-registration look like?
- does orcfax have the power to deregister based on solid rules? e.g. endpoints are down for x-hours?
No description provided.