full

Offchain Gateway (Rust)

Warning

This repository is under construction 🚧. We are actively improving it hackathon-style.

This is a Rust implementation of the CCIP gateway. It allows you to issue unlimited gasless subdomains for your name, as well as to create, manage, and moderate namespaces.

Note

This gateway is built to be an Opinionated ENS Subname Issuer, if youre looking for something more generic, please checkout ensdomains/offchain-resolver, and ensdomains/offchain-resolver-example.

Features

• CCIP Spec Compliant Gateway Endpoint
• postgres - Transparent Database backend.
• self-service - Authentication-based updating records.
• eoa-self-service - EOA-based Authentication. (TODO)
• Modular authentication for EOA, Admin API, & more.
• View endpoint for profile data.

Setup

Run the gateway

The gateway is just a docker container / standalone binary. You can run it with docker-compose or just run the binary.

cargo run

Deploy a Resolver

Using a CCIP Gateway requires a resolver contract to be acting on behalf of the name. Although you could write your own contract, we recommend you deploy a proxy contract through ccip.tools.

(Source for the contracts can be found at ensdomains/ccip-tools)

When asked for the Gateway URL supply your gateway's url (for eg: https://gateway.example.com/{sender}.json), and for the Signers field supply the address of your gateway (for eg: [0x225f137127d9067788314bc7fcc1f36746a3c3B5]), you can find this in the logs of your gateway.

Note

There are gas costs associated with deploying a resolver, at the time of writing this (30 gwei), it costs ~0.004 ETH (8 USD) to deploy a resolver (see txs).

Set your Resolver

Finally you need to instruct the onchain registry to use your resolver. You can do this by visiting your name in the ENS Manager App and under the More tab, set the Resolver field to the address of your resolver.

Fork this 🍴

Don't like the implementation? Fork this repo and make it your own!

You might also be interested in the resolution logic and database modularity.

Integration

This gateway implementation is designed to be modular, light, and easy to integrate. It comes with the abstract Datastore idea, (by default implemented with postgres), authentication, simple resolution logic, and a self-service API.

This means that depending on your use case you can easily swap out the database, the resolution logic, and customize authentication.

Issuing a name

To issue a name from an trusted server, you can simply POST to example.com/update with a JSON body such as

{
    "name": "luc.willbreak.eth",
    "records": {
        "name": "Luc",
        "text": "hello world",
        "avatar": "https://avatars.githubusercontent.com/u/11744586?v=4",
    },
    "addresses": {
        "60": "0x225f137127d9067788314bc7fcc1f36746a3c3B5"
    },
    "auth": "yes"
}

In a similar fashion users could self-service their names by using this api endpoint and custom authentication logic.

Viewing a name

In events were our app might not have access to ethereum specific tooling, we can use the GET endpoint example.com/view/luc.willbreak.eth to view the data of a name. This endpoint can be helpful for showing profile editing pages and more.