The problem dmapper solves

dmapper is a graphical frontend for dmap, an on-chain key-value registry that's simple yet profound. It enables a recursive system of name zones, keys and values with any logic. It has no token, governance or treasury. The contract is immutable, which means dmap is a truly unstoppable application. It was built by Nikolai Mushegian, a pioneer of credibly neutral technology and MakerDAO's technical co-founder.

We believe dmap is a tool whose principles are increasingly rare in distributed systems, but are more needed than ever.

As a replacement to the IANA DNS root or any overengineered alternative, dmap offers a practical way of anchoring the security of anything in the most credibly neutral source we know -- Ethereum mainnet. Potential use cases range from software supply chains, through websites, to marvels unimagined. We want to support this cultural reformation by building dmapper, the first multi-purpose frontend for dmap that makes it accessible to a wider audience.

dmapper allows users to interact with dmap through

:free

, a simplistic first-come-first-serve name zone. It does so using dpath, a syntax convention for describing dmap keys. You can:

• look up, validate and trace dpaths.
• see the value assigned to a key.
• display or open the content a value refers to -- plaintext, an IPFS content ID or an Ethereum address.
• register a key through Take, which you will own with your Ethereum address.
• assign a value to a key you own, or turn it into a new simple name zone under

  :free

  , both by using Set.
• lock a key via Lock, making the given dpath immutable.
• pass on a key you own to another Ethereum address via Give.

dmapper is inevitably a simplified and opinionated representation of dmap, intended to showcase dmap's potential. We acknowledge this limitation and strive to show the system as it is as far as a hackathon project's constraints allow that.

Challenges we ran into

This project involved a lot of decoding/encoding issues and transformation of data with several moving pieces: IPFS and its many multiformats quirks, moving around bits to use the contract storage, various other patterns and encodings relating to the kind of data users can store with dmap.

Understanding the contracts, even though the documentation is very sparse at the moment, was much easier than we anticipated. Dmap is an extremely simple design. Building the correct mental model was the key for us.