[Request-for-grant] Build eth.link to near.link

Eth.link is a website that allows to map xyz.eth ENS address to domain xyz.eth.link.

We just registered near.link to enable the same functionality for NEAR’s account ids.

This service should also provide functionality like resolving IPFS and other content hash links via gateways for browsers that don’t support it.

You can implement this and request funding from http://sputnik.fund/

5 Likes

The CrossChain Labs team is ready to start working on this project.

Deliverables:

  • The near.link service

  • DNS smart contract

  • ‘npx create-nearlink’ dev tool that generates a template web app which can be published to near.link

@crosschainlabs thanks for grabbing this and posting the funding request.

To be clear, Genesis DAO is designed to fund building Sputnik itself, so there might be a better place to apply. Let me follow up with the right place.

Curious about few things, specifically scope of work and time estimate:

  • The source code for eth.link is available here GitHub - wealdtech/coredns-ens, so just need to switch to read data from NEAR’s DNS contract
  • Not sure why npx create-nearlink is needed, because any web app should be deployable. It’s just deploying the static app to IPFS, I’m assuming there is already command for that.

The create-nearlink tool will have the ipfs sdk and near sdk included, so it will simplify the deployment process. With just one command the developer can deploy the static page to ipfs and also send the ipfs CID to the DNS smart contract.

I was thinking to build such service but like host everything completely on NEAR vs IPFS.

Like if you have berries.near account – you get berries.near.wtf domain automatically and can publish website by deploying conforming contract.

Which can potentially handle stuff like URL rewrites and even basic server-side queries to allow you hosting stuff without hacks like # before route.

Like this pretty common problem with static websites. For example with Berry.Cards:

You have this link which has the same social preview no matter which card you add. If you had ability to map some queries to smart contract view call – smart contract can be providing social preview data.

1 Like

It’s just deploying the static app to IPFS, I’m assuming there is already command for that.

Yeah, there is GitHub - ipfs-shipyard/ipfs-deploy: Zero-Config CLI to Deploy Static Websites to IPFS

But also it somehow didn’t really work when I tried it, so we need to make sure there is a tool that does work.

@illia Related to the scope of the project, we initially splitted this in 3 components:

  1. The near.link service → nodejs based server that will resolve accountId.near.link using the DNS smart contract to content hash and use that content hash to retrieve the data from the decentralized storage, and serve that data.

  2. DNS smart contract → maps accountIds to content hashes, also providing update functionality

  3. ‘npx create-nearlink’ dev tool → to simplify deployments to the decentralized storage and adding content hashes to the DNS smart contract

If we go for the option of porting coredns-ens to NEAR then the nodejs based server can be replaced by this. I did try to run coredns-ens in docker there are some errors , It doesn’t seem as just a matter of switching to NEAR rpc, I think it requires some effort to port it.

@vlad We like the idea of hosting content on NEAR directly, the DNS smart contract could support multiple protocols:

Mapping the accountID → to {
protocol: u8, // 0 - NEAR, 1 - IPFS, 2 - SIA, ….
hash: Hash, // hash used to retrieve the data
}

In the case of storing the data directly on NEAR, I think we could save in the DNS smart contract only the block reference, and the payload itself will remain in the transaction history. I’m not sure what the size constraints are here with the payload.

I think ideally you should be able to have some routing config as well.

Ideally something like: Redirects and rewrites | Netlify Docs

where you can define redirects and rewrites you want to happen for given domain.

But ultimately it should be possible to resolve some of the routes to smart contract view call, which generally can be returning whatever data (including JSON, HTML, images, etc). Like maybe just have expectation that method calls return object in certain format (with content-type, cache-control, and response data itself).

So, the near.link code is ready and includes:

coredns-near
near-api-go
near-link
near-dns

We also made a demo recording on how the service works.

1 Like