Snowflake Identity Protocol and the Hydro dApp Store

Background: Planning for Snowflake

In planning the Snowflake phase of Project Hydro, our team thought carefully about the concept of digital identity. We wanted to make sure to provide a value-add separate from what most blockchain teams in the identity space provide; we realized that many teams are building digital identities per se which can be used in a variety of applications. These digital identities are analogous to the real-world identities people around the world use today: drivers licenses, passports, access badges, etc. The challenge with building a digital identity is that it is only as useful as the systems that accept it. For instance, if I have a digital driver’s license that is only accepted by businesses in the United States, I would need to manage an entirely separate digital identity that is accepted at a venue in France. Moreover, each of these digital identities encodes different information about an individual in different formats. This process would be ideal if we were able to obtain global consensus on a singular digital identity format, but this doesn’t seem to be a realistic proliferation of digital identity.

Taking this abstraction a step further, we realized that any information encoded in any smart contract with which a user interacts can speak to that user’s identity. An intuitive analogy would be to say: “looking through the mobile apps I’ve downloaded to my smartphone and all the data within each of those apps says much more about my fundamental identity than just looking at my national ID card.” In the digital world, one of those apps I’ve downloaded could very well be a digital rendition of my American ID card while another might be my French one. Accordingly, rather than building a digital identity, we set out to build a digital identity protocol that allows a user to easily manage and aggregate any identifying information, in any format.

This logic led us to an infrastructure in which a Snowflake Identity Token is a user’s gateway to the Snowflake dApp store. As a low-level identity framework, this allows developers to create any smart contract/dApp that can encode any user information. The easiest non-blockchain analogy to compare to a Snowflake Identity Token is an iCloud or Google Play account which acts as the gateway to a user’s access to a traditional app store.

Just like users can link their credit card to an iCloud or Google Play account, users are able to deposit and withdraw a HYDRO token balance from their Snowflake Identity Token. This mechanism makes it seamless for dApp developers to programmatically charge users for things like in-app purchases, monthly subscriptions, paying to download an app, and more.

At this point, Snowflake looked like this:

We still felt like something was missing — we loved the concept, but we needed to make it more usable.

Once we decided the overall architecture of Snowflake, we needed a way to make it secure and overcome some of the user-friendliness hurdles common in Ethereum dApps. Since users currently generate a HydroID from a wallet in our mobile app, we decided it would make the most sense to create a user’s Snowflake Identity Token from the same wallet already in the Hydro mobile app. This makes the Hydro mobile app a user’s one-stop-shop ticket into the ecosystem of dApps provided by the dApp store.

Once a user’s Identity Token is created, however, we determined that it would be very restrictive to only allow the user to access this Identity from a singular wallet stored locally within the memory of their Hydro mobile application. In today’s world, users expect to be able to access accounts from multiple devices — phones, tablets, desktops, etc.

Under the initial architecture of Snowflake, the only way to meet this demand would be to ask users to migrate their private keys across each of their different devices, either manually or through some sort of cloud infrastructure we would establish. Given that the private key in the Hydro app is designed for secure authentication, this sort of key migration wasn’t an option for us — it left too much room for user error and opened up unacceptable security threats; we realized we needed to come up with an alternative, standardized solution to access dApps across devices while maintaining a core identity.

Some time at the drawing board led us to the “multiple address management” solution. We maintain that for blockchain to obtain widespread adoption, users should not have to learn the nuances of key management. By allowing users to access their Snowflake token from multiple wallets, we pave the way for a world in which systems can generate locally stored wallets entirely in the back-end, and users can use their phones to securely authenticate new devices to connect to their identity without understanding the nuances of Ethereum addresses.

Accordingly, we broadened the Snowflake user flow to look as follows:

Snowflake dApp Store

Now, let’s break down the user interaction with the dApp store itself in greater detail. The user accesses the dApp store through the Snowflake dashboard. The dApp store consists of all dApps built by developers into the Snowflake ecosystem. In order to add a dApp to the dApp store, a developer needs to make a few modifications to their smart contract and build a modal in React for users to interact with their dApp; developers can access the developer guide to adding dApps to the dApp store for further detail on this process.

For users, we thought about some of the functionality in a traditional app store. Some apps are free to download, while others cost money. Some apps have in-app purchases , while others charge users monthly fees for a subscription. In our team’s experience building dApps, we’ve found that encoding these sort of functions to charge users from a smart contract under specific payment models is unnecessarily difficult, particularly when charging users in an ERC-20 token. In order to let developers focus on the core functionality of their dApps rather than payment structures, we created native payment flows that allow dApps to programmatically charge users under pre-defined rules. For users, this is helpful because they can see directly from their dashboard exactly how much they are paying for every dApp they use. They can cancel subscriptions, withdraw funds, or reserve funds for each dApp as needed. They can add or remove dApps much like they add or remove traditional apps from their smartphone or desktop UI.

Using the Snowflake dashboard

The Snowflake dashboard is currently in an early Alpha release — we have included the main functionality from the Snowflake contract. Now our focus is on collecting feedback from dApp users and smart contract developers to determine any additional core functionality we should encode in the Snowflake contract.

To use the dashboard, first you will need to obtain ETH and HYDRO on the Rinkeby testnet. To acquire Testnet ETH, follow the steps in this StackExchange answer:

How do I "Buy" tokens on the Rinkeby (test) environment?

To acquire Testnet HYDRO, connect your Rinkeby account from MetaMask on this page:

Rinkeby Accounts, Address and Contracts

and “write” the getMoreTokens function, which is a function on the Rinkeby version of the HYDRO token contract that creates 10,000 HYDRO and pulls it into your wallet.

Once you have obtained testnet ETH and HYDRO, you will need to generate a HydroID. In the future, the dashboard will be compatible with HydroIDs created in the Hydro mobile app. Once you have obtained a HydroID, you will need to claim your Snowflake Identity Token.

After claiming a Snowflake, you will observe tabs to manage dApps (Resolvers), manage addresses, and deposit and withdraw tokens from your Snowflake Identity Token. You will observe both the ETH and HYDRO balances in your wallet as well as the HYDRO balance in your Snowflake Identity Token.

At this point, you can view all dApps built into the dApp store, add or remove them from your dashboard, add or remove addresses from which you want to access your dashboard, and deposit and withdraw HYDRO into your Snowflake Identity Token.

You can see a detailed walkthrough of all of the current functionality of the dashboard in our live stream recap. We’d love for those familiar with using MetaMask on the Rinkeby testnet to try out the dashboard for themselves and provide us with feedback as we plan improvements.

All-in-all

Here are some definitions for how we’ve defined the functions in Snowflake.

dApp store: a space we have created in which developers can include their dApps, and users can easily manage dApps to add or remove from their dashboard.

Snowflake Dashboard: The user-facing dashboard through which users access the dApp store

Resolver: Any dApp a developer has built in the dApp store

“Setting a Resolver”: From a user perspective — analogous to downloading an app from a traditional app store

“Removing a Resolver”: From a user perspective — analogous to deleting a downloaded app from a traditional app store

“Address Management”: A function of the Snowflake protocol that allows a user to access the dApp store from multiple Ethereum addresses. This is important because it allows programs to generate unique addresses local to each of a users’ devices without the user needing to understand the underlying functionality. It also increases security on the platform because users don’t have to migrate private keys from one location to another.

Snowflake Identity Token: A tool that allows users to navigate resolvers, make payments to resolvers, add or remove resolvers, and manage HYDRO tokens scattered across multiple addresses — a gateway for a user into the Snowflake protocol, much in the same way that my itunes account is my gateway into the apple ecosystem, even across many devices like my iPad, macbook, and iPhone.

Here’s a curated list of things Snowflake does at the Smart Contract level:

1. Creates a unique, non-fungible, non-transferable Snowflake Identity Token for an individual that can be perceived as a digital rendering of that individual’s core identity.
2. Allows an individual to prove ownership of multiple Ethereum addresses. Most people who have actively interacted with dApps across multiple devices are familiar with the struggles of maintaining many wallets. Snowflake ties multiple wallets together, creating a query point for data associated with any of them. This reduces the need to transfer seed words across devices, mitigating risks associated with phishing schemes or malware.
3. Allows an individual to maintain a single Hydro balance that is accessible from multiple accounts. This means that when a user is paying for a service in Hydro, they don’t need to worry about maintaining the appropriate balance in each of their wallets, but rather just within their Snowflake, which further reduces the need to transfer seed words across devices.
4. Allows an individual to add or remove data from the query structure of their Snowflake Identity Token. This feature pertains to any form of data encoded in any Smart Contract that has set itself as what we call a Resolver of a user’s data. When we say a user is adding data to their Snowflake, we mean they are pointing to a Resolver from their Snowflake or one of their claimed addresses. That Resolver can contain any sort of data structure associated with the user’s address — merkle hashes, pointers to off-chain datastores, plaintext public data, encrypted data that enables secure multiparty computation, data hidden behind zero-knowledge proofs, etc.
5. Allows an entity, such as a business, to query a user’s Snowflake to glean insights from any associated data in a standard, consolidated, programmatic way. This allows them to design their business logic according to the results of these queries.
6. Allows APIs to query users’ on-chain data, enabling businesses to drive their business logic off of immutable, on-chain data structures without needing to hire blockchain developers.
7. Allows dApp developers to easily monetize their dApps in Hydro to set up programmatic billing models such as monthly subscription fees.
8. Allows users to easily interact with dApps charging subscription fees by setting transfer allowances to all these dApps from a single dashboard.
9. Allows users to easily manage the data associated with their Snowflake by adding and removing Resolvers through a single dashboard.
10. Displays a simple dApp description for each deployed Resolver with which a user interacts through a single dashboard.
11. Allows dApps to identify and interact with their users through a simple, short identifier called a HydroID instead of a long public key.
12. Allows users to pass entities leveraging their Snowflakes short HydroIDs instead of long public keys.

All-in-all Snowflake adds value to dApps within the Hydro ecosystem while allowing them to maintain all their core functionality. It makes it easy for users to interact with dApps, which is important for broad adoption of blockchain technology. Finally, it makes it easy for businesses, governments, and other entities to programmatically interact with users without forcing users to aggregate and pass redundant information across platforms.

As always, feel free to reach out to me or anyone on our team via Discord with any questions, and if you’re familiar with MetaMask, please, please fill out the feedback survey!