DAB V1.0.0: New Architecture and Registry Standard 🏛

We’re changing the way that DAB is wired in order to improve flexibility and add inclusivity for developers looking to create their own registries!

Published in

DAB — An open internet service.

6 min readFeb 14, 2022

With this update, we are making significant strides towards the decentralization of the DAB open internet service by empowering developers to create and manage their own registries through the use of our new DAB Registry Standard.

This comes with an update to DAB-js and our registries. Don’t fret, it’s not code-breaking! You’ll only need to update your DAB-js version on your dApps and sites that integrate it. Applications won’t break with this release as we will wait a month to deprecate old methods/registries (more on that below!).

We are also updating our current registries so that they meet the Registry Standard.

But, how is this change implemented exactly..?

Let’s dive in and find out 🌈

Updating Current DAB Implementations

Before going over DAB’s new architecture & why it’s important, let’s highlight how we’ve avoided breaking current DAB integrations & the actionable steps that applications who currently implement DAB need to take to avoid breaking in the future.

To avoid a breaking update, we’ve simply copied our current registries into the new registries that follow the DAB Registry Standard. For the time being, both instances (old and new) will co-exist and be updated with new data in parallel.

If You Integrate Through DAB-js:

You only will need to update your DAB-js version on your app/site to migrate over to the new standard and registries. DAB-js new version is adapted to support the existing integration code so there won’t be any breaking changes.

Under the hood, DAB-js has been fully refactored so that it works with the new Token, Canister, and NFT list registries that follow the DAB Registry Standard.

If You Integrate to Registries Directly:

If your application interacts with the old DAB registries directly (not through DAB-js), the integration will not break either. However, in the near future we will no longer be maintaining the old DAB registries, since we’re moving to their newer standardized versions.

We know this might be the minority of our user base (as DAB-js is the main entry point) but we still will maintain these old registries for a minimum of a month to allow ample time for migration to new methods. For more information on our new registries public interfaces, checkout our updated candid files:

DAB Verified Registry Candid Files

Why Refactor DAB? 🤔

The short answer is that the way that DAB is currently designed is not flexible enough to align with our long term decentralization goals for DAB.

We can all agree that further decentralization of the platform is good, but to get there, we need to pivot away from the current limitations facing DAB.

Current Limitations

DAB’s original registries (NFT, Token, etc…) are maintained by our team. Most of the current manual control is to ensure safety and validity of the information that gets added to DABs registries as we research and build systems for trustless additions to any registry.

However, in the meantime, one of our major points of centralization with DAB right now is the fact that we’ve put a limitation on who is able to create registries and how entries are added. We do our best to listen to the wants and needs of the community and create registries as a reflection, but who are we to have the final say on who can and can’t create a registry?

Our solution

Instead of gatekeeping, we want to bring down the barriers to entry for DAB registry creation through the use of a standard for registries that anyone can follow to build a registry of their own. There are many use cases for registries and some dApps might want to create custom token lists, or registries of other sorts.

These community created registries will fall under the ‘unverified’ category upon deployment but will still be completely interoperable with apps that already consume DAB registry data.

Unverified registries will be able to request to become verified. Verification decisions will be determined by admins for now and by DAB’s decentralized community governance in the near future.

This allows us, as the current admins, to abstract registry creation and accessibility away from our own domain, while still trying to act as a central source of trust for ‘verified’ DAB registries for the time being as we work on democratizing the verification process behind the scenes (we are getting closer and closer to this 😉).

This is one step in decentralization, and we’ll continue to move forward with other updates to continue expanding that. For example, allowing the community to curate submissions to registries!

DAB V1.0.0 — Multi-List Architecture ⛓

The new architecture that we’ve implemented into DAB is going to let developers do a few cool new things… such as:

DAB’s new multi-list architecture is made up of two components; A single Router and multiple Registries.

The router canister acts as DAB’s autonomous management canister. It keeps track of (and can be queried for) the list of ‘verified’ DAB registries. The router canister also has the authority to add and remove registries from its ‘verified’ list.

NOTE: The router canister has no control over and makes no interaction with any of the verified or unverified registries.

For the time being, the update calls made to add and remove ‘verified’ registries at DAB’s router will be authorized to admins only. This will not be the plan going into the future.

We are working on a project we are calling the ‘lifecycle canister’ that would effectively become DAB’s controller and make updates based on the results of democratic votes. But more alpha on that soon 🤫

The registry canisters that make up DAB’s new architecture now all conform to a common standard. We have refactored all of our current registries and all future DAB registries (verified or not) will be built atop this standard.

Let’s learn some more about this new pillar in DAB’s architecture.

The Registry Standard

We’ve introduced DAB’s ‘Registry Standard’ as a part of this refactor to help DAB scale with confidence.

By creating a set standard that all canisters who wish to be registries must follow, we create a predictable base set of functionalities to which further applications can be reliably built.

A great example of this is DAB-js. Being able to know that every registry canister will have the same base functionality means that the DAB-js developers only need to implement new methods once, and will be guaranteed that these methods will work with all registries now and into the future.

If you’re interested in creating your own registry to add to DAB, you can check out the Create Your Own Registry section in our docs.

Until Next Time 👋

It’s been about four months since we debuted DAB and things have been moving at light speed ⚡️ So far the launches of all three registries (NFT, Canister, and Token) have been successful and we just want to say thank you. We are very grateful for the community’s continued support of DAB.

We hope that this refactor continues to show our devotion to the community and the eventual full decentralization of DAB. If you have any thoughts / concerns / ideas about the refactor or just want to come jam with the DAB team, join our Discord!