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?
|
|
||
| The total cost of a feed will depend on a number of factors such as: | ||
|
|
||
| - whether Orcfax has been contracted to develop the feed |
There was a problem hiding this comment.
I'd remove this one for now (we know from experience we will always be asked regardless) but let's work on the assumption:
a) sources exist,
b) we can describe what is required by a source to enable publication.
| protection of their solution's data. | ||
|
|
||
| If you have questions about Ortcfax's record keeping processes, or need guidance | ||
| on how best to structure archival records, please reach out to info@orcfax.io |
There was a problem hiding this comment.
This is good, but I'd shorten it, and I think we can make it more generic:
-
what is the rationale for the archive? -- Well, lots of reasons, but here, I think it is - did we publish when we said we published, and what did we validate. In the first instance I think we just need to create a schema that has a big hole in it where we place:
-
what was the payload (we don't even assume this can be more broadly understood),
-
sources (data + signatures),
-
what was checked.
And we make this the same for all customers for this feed type.
So for the sake of this document (or for the sake of our proof of concept) I think we focus on:
- we archive,
- you get an archive,
- you get your reassurances,
- everyone's archive looks the same.
|
|
||
| ### Integrator: can my feed be published to other chains? | ||
|
|
||
| Yes! While Orcfax currently operates on Cardano and Arweave, our oracle solution |
There was a problem hiding this comment.
- do we want to use arkly+arweave?
- do we want to use bagit?
One thought I have is preparing an audit document for this product that is slightly different from the standard archives.
Is it possible to create a single document object that contains all the information needed? I.e. just one JSON file will all records in?
This might lend itself better to content addressed storage in future, e.g. IPLD.
We'd need to answer this quite quickly though. The path of least resistance is designing one new record for our current packages.
fix malformed md link
| - Orcfax Custom Feeds | ||
| - Data Customization | ||
| - Custom oracle feeds | ||
| - Custom Orcfax feeds |
|
Notes from @waalge in 01/13 meeting
And notes from @ross-spencer |
3 participants
No description provided.