Remaining record content types to support #51

New Issue

i-norden · 2022-11-15T14:15:57Z

i-norden commented

2022-11-15 14:15:57 +00:00

Git repository
- Do we want to register the entire dependency graph?
  - Not necessary for the first pass
    - Just top-level, standalone binaries
- Full indexing node stack
  - Geth node modified with statediffing ETH IPLD ETL service (for head tracking): https://github.com/vulcanize/go-ethereum/tree/v1.10.15-statediff-3.0.1/statediff
  - Standalone statediffing service for offline levelDB : https://github.com/vulcanize/eth-statediff-service
  - Mempool/pending state indexing service: https://github.com/vulcanize/eth_probe
  - ETH IPLD DB Schema: https://github.com/vulcanize/ipld-eth-db
  - ETH IPLD data APIs: https://github.com/vulcanize/ipld-eth-server, https://github.com/vulcanize/tracing-api
  - ETH IPLD state snapshotting tool: https://github.com/vulcanize/ipld-eth-state-snapshot
  - Trailing validation code (WIP): https://github.com/vulcanize/ipld-eth-db-validator
  - Snapshot validation code: https://github.com/vulcanize/eth-ipfs-state-validator
  - IPLD ETL service for beacon chain: https://github.com/vulcanize/ipld-eth-beacon-indexer
  - Beacon IPLD DB Schema: https://github.com/vulcanize/ipld-eth-beacon-db
- Watcher stack
  - TS watcher: https://github.com/vulcanize/watcher-ts
  - Uniswap V3 Watcher Overview: https://github.com/vulcanize/uniswap-v3-info-watcher
  - Watcher that can run subgraphs: https://github.com/vulcanize/graph-watcher-ts
- Attributes:
  - Name
  - Reference to repository
  - Description?
Binaries
- Go releases
- Watcher stack
- FIN (full indexing node stack)
- Attributes:
  - Raw multicodec
  - Raw binary (reference to the raw binary as stored on IPFS)
  - Targeted arch
  - Runtine version e.g. go 1.18
  - Reference to repository (reference to the nameservice record registering that repository)
    - Version information
Docker images
- Own file format
- Attributes
  - Image ID
  - Docker image binary (reference/CID to the binary stored in IPFS)
  - Version number
  - Reference to repository (reference to the nameservice record registering that repository)
Watcher registration (watcher metadata/artifact)
- Note: we need to write IPLD schemas and register multicodecs for watcher metadata/artifact
- Attributes
  - Watcher metadeta
    - Talk to Ashwin
    - Version
    - Reference to the chain registrations for the the chains that are producing the data being consumed by this watcher
  - Reference to git repository that contains the watcher source code (reference to its registration record)
  - Compiled WASM binary of the watcher (a reference to it stored on IPFS)
    - Build meta data
      - WASM compiler version
      - Execution engine version
- SDK generates the record
  - Laconic has an endpoint for registering watchers, where you provide the unique set of attributes
Responder contract schema
- We need to write IPLD schema and register multicodec
- Anyone can make an ask for a set of service providers to run watcher instances of a specific configuration
- Result of an auction
- We need an ask compiler which takes human readable input to generate the auction
- The responder contract record should be produced by the SDK as a result of a service provider auction
- Attributes
  - Reference service providers (their registration records)
  - Reference to the auction
  - Reference to watchers (their registration records)
Service provider registration
- Attributes
  - Bond/Vault ID
    - https://github.com/cerc-io/laconicd/blob/main/x/bond/types/bond.pb.go#L77
    - Vault and Bond need to be merged
  - Laconic ID
    - DIDs
      - Need to support multiple types of addresses (ethereum, cosmos)
      - Treat as simple string for now
  - Reference to legal identity
    - Specifies location
    - Use x.500
      - Look into how/if it is hashlinked, can/should we provide explicity IPLD support (schemas + multicontent types + codecs)
      - commonName - common name of a person, e.g., "Susan Jones"
        
        Usually the only field used
        
        Usually a DNS host name
      - organizationUnit - small organization (e.g, department or division) name, e.g., "Purchasing"
      - organizationName - large organization name, e.g., "ABCSystems, Inc."
      - localityName - locality (city) name, e.g., "Palo Alto"
      - stateName - state or province name, e.g., "California"
      - country - two-letter country code, e.g., "CH"
Npm packages
- For self hosting
- Attributes
  - Reference to git repository that contains the npm source code (reference to its registration record)
  - npm package (tar or w.e.; reference to it stored on IPFS)
  - Version information
Websites
- laconic.com
- mobymask's website
- our uniswap.info website
  - Our endpoint which supports the uniswap.info front end
- Attributes
  - url
  - Reference to git repositor(ies) (reference to their registration records)
  - Some type of package/build artifact for the website (uniswap.info is stored on IPFS?)
  - TLS cert
    - Ideally the orgs here match the orgs in service provider registration
Chain registry
- Attributes
  - Name
    - Use an existing chain registry
      - Starname
  - List of IPLD types and their codec or schemas
  - Fill in the rest....

- [x] Git repository * Do we want to register the entire dependency graph? * Not necessary for the first pass * Just top-level, standalone binaries * Full indexing node stack * Geth node modified with statediffing ETH IPLD ETL service (for head tracking): https://github.com/vulcanize/go-ethereum/tree/v1.10.15-statediff-3.0.1/statediff * Standalone statediffing service for offline levelDB : https://github.com/vulcanize/eth-statediff-service * Mempool/pending state indexing service: https://github.com/vulcanize/eth_probe * ETH IPLD DB Schema: https://github.com/vulcanize/ipld-eth-db * ETH IPLD data APIs: https://github.com/vulcanize/ipld-eth-server, https://github.com/vulcanize/tracing-api * ETH IPLD state snapshotting tool: https://github.com/vulcanize/ipld-eth-state-snapshot * Trailing validation code (WIP): https://github.com/vulcanize/ipld-eth-db-validator * Snapshot validation code: https://github.com/vulcanize/eth-ipfs-state-validator * IPLD ETL service for beacon chain: https://github.com/vulcanize/ipld-eth-beacon-indexer * Beacon IPLD DB Schema: https://github.com/vulcanize/ipld-eth-beacon-db * Watcher stack * TS watcher: https://github.com/vulcanize/watcher-ts * Uniswap V3 Watcher Overview: https://github.com/vulcanize/uniswap-v3-info-watcher * Watcher that can run subgraphs: https://github.com/vulcanize/graph-watcher-ts * Attributes: * Name * Reference to repository * Description? - [x] Binaries * Go releases * Watcher stack * FIN (full indexing node stack) * Attributes: * Raw multicodec * Raw binary (reference to the raw binary as stored on IPFS) * Targeted arch * Runtine version e.g. go 1.18 * Reference to repository (reference to the nameservice record registering that repository) * Version information - [x] Docker images * Own file format * Attributes * Image ID * Docker image binary (reference/CID to the binary stored in IPFS) * Version number * Reference to repository (reference to the nameservice record registering that repository) - [x] Watcher registration (watcher metadata/artifact) * Note: we need to write IPLD schemas and register multicodecs for watcher metadata/artifact * Attributes * Watcher metadeta * Talk to Ashwin * Version * Reference to the chain registrations for the the chains that are producing the data being consumed by this watcher * Reference to git repository that contains the watcher source code (reference to its registration record) * Compiled WASM binary of the watcher (a reference to it stored on IPFS) * Build meta data * WASM compiler version * Execution engine version * SDK generates the record * Laconic has an endpoint for registering watchers, where you provide the unique set of attributes - [x] Responder contract schema * We need to write IPLD schema and register multicodec * Anyone can make an ask for a set of service providers to run watcher instances of a specific configuration * Result of an auction * We need an ask compiler which takes human readable input to generate the auction * The responder contract record should be produced by the SDK as a result of a service provider auction * Attributes * Reference service providers (their registration records) * Reference to the auction * Reference to watchers (their registration records) - [x] Service provider registration * Attributes * Bond/Vault ID * https://github.com/cerc-io/laconicd/blob/main/x/bond/types/bond.pb.go#L77 * Vault and Bond need to be merged * Laconic ID * DIDs * Need to support multiple types of addresses (ethereum, cosmos) * Treat as simple string for now * Reference to legal identity * Specifies location * Use x.500 * Look into how/if it is hashlinked, can/should we provide explicity IPLD support (schemas + multicontent types + codecs) * commonName - common name of a person, e.g., "Susan Jones" * Usually the only field used * Usually a DNS host name * organizationUnit - small organization (e.g, department or division) name, e.g., "Purchasing" * organizationName - large organization name, e.g., "ABCSystems, Inc." * localityName - locality (city) name, e.g., "Palo Alto" * stateName - state or province name, e.g., "California" * country - two-letter country code, e.g., "CH" - [x] Npm packages * For self hosting * Attributes * Reference to git repository that contains the npm source code (reference to its registration record) * npm package (tar or w.e.; reference to it stored on IPFS) * Version information - [x] Websites * laconic.com * mobymask's website * our uniswap.info website * Our endpoint which supports the uniswap.info front end * Attributes * url * Reference to git repositor(ies) (reference to their registration records) * Some type of package/build artifact for the website (uniswap.info is stored on IPFS?) * TLS cert * Ideally the orgs here match the orgs in service provider registration - [x] Chain registry * Attributes * Name * Use an existing chain registry * Starname * List of IPLD types and their codec or schemas * Fill in the rest....