draft: dservice text records #43
Conversation
ensips/x.md
Outdated
|
|
||
| It is RECOMMENDED that the URL protocol *scheme* is `https`. | ||
|
|
||
| ### DService Definition |
There was a problem hiding this comment.
This should probably come earlier.
ensips/x.md
Outdated
|
|
||
| ### DService Definition | ||
|
|
||
| A decentralized service, or dservice for short, is a backend service that provides the dapp with specialized functionality beyond what is provided through ethereum RPCs and bundlers. Each dapp MAY implement one dservice (it MUST NOT implement more than one) and it is RECOMMENDED to provide multiple endpoints for this service that are hosted on independent infrastructure (these URLs are to be provided in the `dservice` text record). |
There was a problem hiding this comment.
This is unclear. Is there a one to one relationship between an ENS name and a dApp?
There was a problem hiding this comment.
A dapp here is defined as a frontend deployed to the contenthash field of the ENS name in question.
ensips/x.md
Outdated
|
|
||
| #### External DServices | ||
|
|
||
| A dapp MAY also use DServices provided through ENS names beyond its own. For example, `dapp-a.eth` could look up the `dservice` text record of `dapp-b.eth` to get the latest endpoints for its dservice, then query those endpoints directly. |
There was a problem hiding this comment.
How? Is there a standard for this forwarding?
There was a problem hiding this comment.
It would work the same way a dapp looks up it's on dservice urls. Happy to clarify this further, could you say more about what you don't find clear here?
|
This is interesting, but lacks some clarity IMO. I think it'd be worth jumping on the ecosystem call to run through this proposal. Often times getting further implementations up front is a better route to standardization. It could also do with some tidying up - acronyms for example. rpc => RPC, dapp => dApp |
|
Thanks for the feedback @clowestab! Where do I find info about the ecosystem call? |
|
|
||
| #### Indexer Requirements | ||
|
|
||
| 1. MUST only rely on indexed data from the following sources: |
There was a problem hiding this comment.
Good point, will add the following why: Because anyone should be able to spin up an indexer node and arrive at the same state as other nodes without having to rely on any trusted source of information
ensips/x.md
Outdated
| 1. MUST only rely on indexed data from the following sources: | ||
| 1. The Ethereum blockchain, i.e. Ethereum L1 and L2s | ||
| 2. Content-addressed data, e.g. the IPFS network | ||
| 2. MUST be deterministic, all Indexer nodes given the same input should produce the same state |
There was a problem hiding this comment.
Is there any integrity checking mechanism built in?
There was a problem hiding this comment.
From the perspective of the node operator or the perspective of the user?
There was a problem hiding this comment.
Both, but I imagine its more important to the user..
|
Is 'indexer' the correct terminology here? it sounds like a more generic API endpoint. The lack of integrity checking and overrides concerns me - i could persuade people to override with my endpoint that isn't running the open source software (even though I say it is), and returns malicious data.. |
|
@clowestab I'm open to ideas as to what would be a better name. I did choose |
|
@clowestab Ended up reverting back to the |
|
It feels like this is an API discoverability solution. "dAPI" comes to mind. The title could be "Decentralized APIs using ENS". Why are you constraining it to "should only provide an index over on-chain and content-addressable data."? |
Because if we don't do this we are opening up for prorietary api endpoints to be listed in this way. That would fundamentally break the trust assumption here, because whoever is running the api could lock users in to their service. The main property that absolutely must be maintained is that anyone can trustlessly spin up an endpoint that would be equivalent to the existing endpoints in terms of functionality and state. |
2 participants
📃 ENSIP-X: Dservice Text Records (preview)
This ENSIP proposes a standard for decentralized access to indexer (and other auxiliary) endpoints, enabling dapps to be more resilient.
I've used this pattern in simplepage.eth and plan to continue using it on other dapps I might build.