[Draft] EIP-X: Off-Chain Data Write Protocol

[NameSys]

@nick.eth

Given that clients would have to support each of these reverts separately, is there any reason to hardcode a 2 character limit? It may be simpler to just standardize each one based on the name that makes the most sense.

That is correct. No particular reasons for 2-character limit other than having a short code to remember for your favourite storage. Can be adjusted according to popular demand.

@nick.eth

Also, if you’re defining a different revert type for each platform, it doesn’t seem like you need a generic interface like ‘config’ - each revert type can have platform-specific arguments instead, which will be clearer and easier to implement.

That is true although if multiple storage handlers need to be nested, second handler should be able to trust the digest from the first handler’s callback. On second thoughts, you may be right; callback() can be coded to regenerate config from response…

@nick.eth

I’m having trouble understanding what this is meant to convey. Can you rephrase it somehow?

This has just been updated. input, output was simply config, aka a global interface that two or more handlers could blindly trust.

@nick.eth

I’m also not really seeing the need for a callback, or chaining multiple write calls. Can you elaborate on the intended use-cases here?

This is for the use-case where a service intends to use two handlers for their stack. See below:

@NameSys

I wrote my comment before reading this part and we have ended up saying the same thing. We briefly entertained precisely this (= Index-on-L2 + Store Off-Chain) for NameSys v1 but gave up in interest of simplicity at that point; it is still in our To-Do list for NameSys v2 a little further down the line.

For example, a service that wants to serve the data on some storage but index on L2, it may be necessary to await the storage transaction (such as IPFS/Arweave hash) and then index its transaction hash or some other parameter (e.g. IPFS/Arweave hash) on L2. Nesting was constructed keeping such a multi-pronged service in mind.

@nick.eth

I’m no longer a huge fan of the revert-based approach; I think it will likely introduce additional complexity in handling write operations, with apps potentially having to make ‘fake’ eth_call requests to resolvers just in order to find out where the request should actually be sent. I’d personally prefer to see something based around a standard metadata API that can be called to fetch write metadata for a resolver instance.

I’ll ponder on this more.