Hello, been working on my interpretation of Dmap, and my hope is to drive adoption and get paying users to buy zones.
If you are interested, I'd be happy to get some feedback from you on these points and the implementation. Happy to discuss any aspect.

I agree Dmap's design shines where immutability and security are needed. My thinking is these uses seem interesting:

• Registering hashes of dapp clients should be the first use I'd pursue because it's a high value use to protocol teams to prevent DNS hacks.
• More far fetched is there may be a group of users interested to moving away from Github because of potential tracking/censorship, so storing git branches HEADs under dpaths could be interesting.

There are a few changes I made to registries. A couple noteworthy things:

• The decisions regarding the pricing of names under a zone can be deferred and upgraded to be based on auctions/governance decisions.
• I added the ability to store blobs (i.e. raw bytes) onchain, so contracts can resolve names onchain and pass by the dependencies on IPFS.

Wdyt? Happy to share testnet addresses if these sound interesting

Hello, been working on my interpretation of Dmap, and my hope is to drive adoption and get paying users to buy zones.
If you are interested, I'd be happy to get some feedback from you on these points and the implementation. Happy to discuss any aspect.

I agree Dmap's design shines where immutability and security are needed. My thinking is these uses seem interesting:

• Registering hashes of dapp clients should be the first use I'd pursue because it's a high value use to protocol teams to prevent DNS hacks.
• More far fetched is there may be a group of users interested in moving away from Github because of potential tracking/censorship, so storing git branches HEADs under dpaths could be interesting.

There are a few changes I made to registries. A couple noteworthy things:

• The decisions regarding the pricing of names under a zone can be deferred and upgraded to be based on auctions/governance decisions.
• I added the ability to store blobs (i.e. raw bytes) onchain, so contracts can resolve names onchain and pass by the dependencies on IPFS.

Wdyt about the uses and implementation changes? Happy to share testnet addresses if these sound interesting.

Hello, been working on my interpretation of Dmap, and my hope is to drive adoption and get paying users to buy zones.
If you are interested, I'd be happy to get some feedback from you on these points and the implementation. Happy to discuss any aspect.

I agree Dmap's design shines where immutability and security are needed. My thinking is these uses seem interesting:

• Registering hashes of dapp clients should be the first use I'd pursue because it's a high value use to protocol teams to prevent DNS hacks.
• More far fetched is there may be a group of users interested in moving away from Github because of potential tracking/censorship, so storing git branches HEADs under dpaths could be interesting.

There are a few changes I made to registries. A couple noteworthy things:

• The decisions regarding the pricing of names under a zone can be deferred and upgraded to be based on auctions/governance decisions.
• I added the ability to store blobs (i.e. raw bytes) onchain, so contracts can resolve names onchain and pass by the dependency on IPFS.

Wdyt about the uses and implementation changes? Happy to share testnet addresses if these sound interesting.

Hello, been working on my interpretation of Dmap, and my hope is to drive adoption and get paying users to buy zones.
If you are interested, I'd be happy to get some feedback from you on these points and the implementation. Happy to discuss any aspect.

I agree Dmap's design shines where immutability and security are needed. My thinking is these uses seem interesting:

• Registering hashes of dapp clients should be the first use I'd pursue because it's a high value use case to protocol teams to prevent DNS hacks.
• More far fetched is there may be a group of users interested in moving away from Github because of potential tracking/censorship, so storing git branches HEADs under dpaths could be interesting.

There are a few changes I made to registries. A couple noteworthy things:

• The decisions regarding the pricing of names under a zone can be deferred and upgraded to be based on auctions/governance decisions.
• I added the ability to store blobs (i.e. arbitrary length of immutable bytes) onchain, so contracts can resolve names onchain and pass by the dependency on IPFS.

Wdyt about the uses and implementation changes? Happy to share testnet addresses if these sound interesting.

In reply to @kbrav:matrix.org
What’s the purpose of blobs? A lil unclear on that

In reply to @kbrav:matrix.org
What’s the purpose of blobs? A lil unclear on that

In reply to @kbrav:matrix.org
yeah there's that but i think i remember that there's stuff you can do with meta and data, not sure if that's the same type vibe
so only one bit is actually taken by dmap LOCK mechanism...you can use the rest in meta to specify other metadata e.g. a length, and then in ascending keys store the stuff you need
but in most (not all) cases big blobs should be stored externally

In reply to @kbrav:matrix.org
so for example, have a dpath, you know the dpath will get you to the correct zone, and let's say you really trust the zone owner for whatever reason, or you trusted them when they set LOCK == 1. that's how you know the data is good

In reply to @kbrav:matrix.org
so for example, have a dpath, you know the dpath will get you to the correct zone, and let's say you really trust the zone owner for whatever reason, or you trusted them when they set LOCK == 1. that's how you know the data is good

In reply to @kbrav:matrix.org
Wrt deferring pricing (there doesn’t necessarily have to be any at all) think you could just have an upgradeable proxy as the zone, idk that there’d need to be a rootzone update for that. But curious to hear thots

• am thinking it's nice zone owner can change their pricing strategy by taking in the plaintext name and block name registrations (eg revert based on length), and avoid adding proxy (to me it's a little complex); code below
• totally agree with you rootzone doesn't need to change, the rootzone governor can manually grant tld and that is all the object does
  • as per ens, thinking there would be one tld eg dmp so there is no collision with tlds in DNS

wdyt? : )

    function assume(bytes32 salt, bytes32 name, string calldata plain) external {
        require(owners[name] == address(0), "ERR_TAKEN");
        require(keccak256(abi.encode(plain)) == name, "ERR_NAME");
        bytes32 comm = keccak256(abi.encode(salt, name, msg.sender));
        require(commitments[comm] >= Appraiser(appraiser).appraise(plain), "ERR_PAYMENT"); // appraiser is upgradeable by zone owner
        commitments[comm] = 0;
        owners[name] = msg.sender;
        emit Assume(name, plain);
        emit Transfer(address(0), msg.sender, name);
    }

In reply to @kbrav:matrix.org
Wrt deferring pricing (there doesn’t necessarily have to be any at all) think you could just have an upgradeable proxy as the zone, idk that there’d need to be a rootzone update for that. But curious to hear thots

• am thinking it's nice zone owner can change their pricing strategy by taking in the plaintext name and block name registrations (eg revert based on length), and avoid adding proxy (to me it's a little complex); code below

• totally agree with you rootzone doesn't need to change, the rootzone governor can manually grant tld and that is all the object does

  • the reason is, as per ens, thinking there would be one tld eg dmp so there is no collision with tlds in DNS
    • thinking it'd be nice dpaths can be used in browser as URI (need a flag somewhere to state if the URI is mutable or not)

wdyt? : )

    function assume(bytes32 salt, bytes32 name, string calldata plain) external {
        require(owners[name] == address(0), "ERR_TAKEN");
        require(keccak256(abi.encode(plain)) == name, "ERR_NAME");
        bytes32 comm = keccak256(abi.encode(salt, name, msg.sender));
        require(commitments[comm] >= Appraiser(appraiser).appraise(plain), "ERR_PAYMENT"); // appraiser is upgradeable by zone owner
        commitments[comm] = 0;
        owners[name] = msg.sender;
        emit Assume(name, plain);
        emit Transfer(address(0), msg.sender, name);
    }

• am thinking it's nice zone owner can change their pricing strategy by taking in the plaintext name and block name registrations (eg revert based on length), and avoid adding proxy (to me it's a little complex); code below
• totally agree with you rootzone doesn't need to change, the rootzone governor can manually grant tld and that is all the object does

  • the reason is, as per ens, thinking there would be one tld eg dmp so there is no collision with tlds in DNS

    • thinking it'd be nice dpaths can be used in browser as URI (need a flag somewhere to state if the URI is mutable or not); so eg v1.rico.dmp.limo/im

wdyt? : )

    function assume(bytes32 salt, bytes32 name, string calldata plain) external {
        require(owners[name] == address(0), "ERR_TAKEN");
        require(keccak256(abi.encode(plain)) == name, "ERR_NAME");
        bytes32 comm = keccak256(abi.encode(salt, name, msg.sender));
        require(commitments[comm] >= Appraiser(appraiser).appraise(plain), "ERR_PAYMENT"); // appraiser is upgradeable by zone owner
        commitments[comm] = 0;
        owners[name] = msg.sender;
        emit Assume(name, plain);
        emit Transfer(address(0), msg.sender, name);
    }

• am thinking it's nice zone owner can change their pricing strategy by taking in the plaintext name and block name registrations (eg revert based on length), and avoid adding proxy (to me it's a little complex); code below

• totally agree with you rootzone doesn't need to change, the rootzone governor can manually grant tld and that is all the object does

  • the reason is, as per ens, thinking there would be one tld eg dmp so there is no collision with tlds in DNS
    • thinking it'd be nice dpaths can be used in browser as URI (need a flag somewhere to state if the URI name is mutable or not); so eg v1.rico.dmp.limo/im

wdyt? : )

    function assume(bytes32 salt, bytes32 name, string calldata plain) external {
        require(owners[name] == address(0), "ERR_TAKEN");
        require(keccak256(abi.encode(plain)) == name, "ERR_NAME");
        bytes32 comm = keccak256(abi.encode(salt, name, msg.sender));
        require(commitments[comm] >= Appraiser(appraiser).appraise(plain), "ERR_PAYMENT"); // appraiser is upgradeable by zone owner
        commitments[comm] = 0;
        owners[name] = msg.sender;
        emit Assume(name, plain);
        emit Transfer(address(0), msg.sender, name);
    }