v1 Architecture about web3studio-soy HOT 4 CLOSED

Hey, good write up. A few questions:
-What is the process for storing new revisions in their associated sub domains? Is this done automatically? What entails a new revision?
-Why are smart contracts needed here? What is the justification for including the mainnet in this process?
-How, exactly, will the smart contract map revisions to their subdomains? Based off this line, The hyperlane gateway functionally allows developers to choose which revision of their site (defined by a top level ipfs folder content hash) with smart contracts., it seems like the smart contract will store a mapping of revision to ipfs hash. Is that correct?

from web3studio-soy.

Some background: The smart contracts are ENS resolvers. Their role is to map an ens record to a contentHash EIP-1577.

After pitching this to john in person and seeing your questions I'm realizing that I'm telling the story wrong, so I'm going to rewrite the OP. BUT:

What is the process for storing new revisions in their associated sub domains?

Interacting with the ENS resolver/smart contract. Not sure what the ABI is, but it will probably be something like resolver.publishRevision(contentHash).

Is this done automatically?

The CLI is an interface for this. So what I imagine the CLI doing is something like:

$ hyperlane publish ./build/out

This will publish the ./build/out directory to IPFS and call whatever the abi is resolver.publishRevision(contentHash)

What entails a new revision?

Any change to the static content

Why are smart contracts needed here?

It's how ENS works. Every "domain" is a smart contract that either resolves to a value and can nest (every level of the domain path is a new smart contract) to another smart contract to handle the lower path. Check the ENS introduction

What is the justification for including the mainnet in this process?

Also just how ENS works. Now, why am I using ENS? It's the evolving standard for how this is going to work. Sense writing originally, I've discovered https://eth.show which is, if not exactly, the gateway I described above. @humbitious didn't like the idea of "needing to hit mainnet for every request" but you can do a few things to limit the load like cache results (with a ttl like normal dns) or, all of these functions to resolve are views so you don't necessarily need a whole node to do the calculations, the js evm can run it so long as it has the state, drizzle/truffle does this for .call. The "right" way to cache it isn't perfectly clear to me yet. I need to play with a few implementations and check speed/memory.

How, exactly, will the smart contract map revisions to their subdomains?

Let me try to answer this with an example. Let me know if this isn't clear still. Let's assume we have a website, named foo, with 3 revisions. We're using simple logic where the main resolver will send the latest version. I believe there will be 4 smart contracts here, but I need to double check if it could be done with one. (only about 90% clear on ens resolver implementations).

Here's a mapping of possible ways to get to your website:

Another thing we can do is map foo.hyperlane.io to a custom domain name, say foo.io. To do that, we'd need to create a dns txt record on _dnslink.foo.io to point to foo.hyperlane.eth and a CNAME of foo.iotofoo.hyperlane.io` and the gateway will do the mapping based on that standard.

it seems like the smart contract will store a mapping of revision to ipfs hash. Is that correct?

Yes, the smart contract(s) will contain a bunch of mappings actually that, through ENS, instructs the gateway which files to serve.

from web3studio-soy.

Do any of the other alternatives use mainnet smart contracts to handle the conditionals like, if parameter x then give back IPFS hash y, else z?

"Smart contracts are programmable! See where this is going?"

from web3studio-soy.

I haven't been able to find anyone attempting to write ENS resolvers with this complex of logic.

The reference contract that people use is just a key-value mapping.

The ENS spec also doesn't include parameters to be passed down. This current architecture and existing gateways don't support that, but I have thought it could be nea, powerful, and also backwards compatible.

from web3studio-soy.