Tech & Infra

Generating IDs

Dua’s identities will be generated using the Elliptic Curve Digital Signature Algorithm (ECDSA) and compatible with all blockchains that use Ethereum Virtual Machine (EVM) as a part of their suite. The seed format that dua will use to generate these identities will be composed of the following parts:
  • Basic Personal User Data (data from the User such as birthdate, name, or sign-up DateTime). The application layer will decide the exact composition of data the service provider already owns about the user.
  • User Inputted Data - The data the user must input and remember to generate and retrieve their identity. It can be a passphrase, password, or PIN-type; we aim to keep it flexible to user needs or other third-party apps.
The formula below is:
The specific hashing algorithm to be used is keccak-256, and the generation of key pair is to be generated using open-source and battle-tested algorithms available publicly. We will consider adding a randomly generated string concatenated at the end of the seed, with the rest of the data returned to the user for safekeeping. However, such considerations are to be decided on the application layer.
The identities will be kept user-side with the public key shared with the service provider only upon user explicit agreement. We will also publish an open-source library to do the same for the users if they wish client-side. The code that does the identity generation will always be open-source.

Authorized IDs

We have defined the user and how their identities are generated. There are two more parts to our devised system for identity management. Even if user identities and their linkage can be a standalone offering for the web3 ecosystem, that wouldn’t be very novel if we didn’t propose a way to establish a reputation around these identities. That is where AE’s come in. We have users with reputations specific to a service provider. The AE's are entities who can update their reputations on given service providers. For example, John has generated an identity X and linked it to social network Y. Then, the AE for network Y can update John’s reputation based on how he interacts with the application and the RuleSetContract presented in the diagram. AE’s can also be set up to update their oracles based on the subset of users that have already connected their identities with their entities.
Each AE should have a rule set that they design to present the rules and functions that can be overridden to determine how their base actions are performed. For example, if SocialNetwork X wishes to ban someone from its network, it can present a ban function written in a smart contract that specifies what needs to be true for the ban to go through. In such a way, when they ban someone, they have to do it in the smart contract, allowing for transparency and credibility of their actions. It is up to service providers to build their rulesets depending on their internal values and application-specific architecture. Dua's primary added value is a mechanism to provide transparency and impartiality to these decisions.
In our case, initially, we would do it manually by authorizing the AE and then another third party, whether that be their fact-checker or an agent assigned by us. In the second iteration, we could provide a public key for each service provider and automatically allow them to claim their entity without our manual intervention.

AEs Oracles

For the dua contract to evaluate decisions and keep up with the set rules, it needs accurate data of items that currently sit outside the blockchain. These items are different indicators that are network and user-specific. For example, to create a set of reputations involving a user's Twitter follower count, the contract needs a constant flow of user data that updates follower count and reputation. Because of that, we will create a distributed off-chain oracle that will allow updates from different key points representing reputation data across various service providers.
Initially, we will update a few oracles based on users linked to these service providers. In the long term, however, we will aim to update open-sourced oracles with the community's latest information using an update bounty provided to entries that update outdated or incorrect information. We might even use existing Oracle ecosystems by partnering with them instead of inventing our own. Initially, we could provide the following oracles: dua Love, dua Biz, dua Friends, Twitter, Reddit, and Linkedin.
Data crawled from sources on the internet, such as social networks and other places where the user has connected their identities, will be stored in an encrypted manner in an off-chain set up securely. For the initial MVP, they will be stored in a centralized database with backups, but they should move to a decentralized database solution in the second version. The final storage solution should uphold these features:
  • Transparent
  • Secure
  • Immutable
  • Decentralized
We believe we can use existing solutions out there from many options. We will pick an option that we will decide on as we continue our technical due diligence of these solutions:
  • API3
  • OrbitDB (IPFS based)
  • Chainify DB
  • Cassandra
  • Apache
  • Direct IPFS setup
Most of the content from this data should be public or semi-public, such as the number of followers on a particular social network and others, mostly non-sensitive data. Then, using an off-chain trusted server that will serve as the oracle supplier, we will generate hashes of each value of key pairs of these collected data, periodically with the period between crawls depending on the entity and the frequency of posts. We will generate a Merkle tree of that entity’s data state from the hashes. Afterward, we will only upload the Merkle root for each updated crawl into our smart contract, saving gas and storage while retaining validation capabilities.
Crawling for reputation
To update the reputation, there will be an off-chain calculation of the reputation based on a predetermined algorithm which dua will make open-source to produce a Merkle leaf. The algorithm is based on the rules set of the contract suite. Each entity will have rules regarding how reputation is calculated, updated, and maintained.
After calculating the reputation according to these pre-set rules, we will send it to the smart contract to evaluate the validity of the calculation in the blockchain. We will update the reputation in the smart contract if it is proven valid with the available data.
To keep our system honest, the data we use will be available in the Distributed DB and publicly available from the sources where the data originates. Therefore any external party can derive the same data and perform the calculations using our open source libraries. They will get the same resulting Merkle tree as in the smart contract. If they achieve a different result given the same timestamp and it can be proven that somehow our calculations tamper, we will provide a significant bounty for such a case that will be stored in a smart contract. Doing this ensures that we keep our data contents and updates honest.

Deriving and Retrieving Reputations

Every platform we interact with today has, in some form, an algorithm that creates a reputation for its users. That reputation is responsible for the data sets that each particular user is exposed to, known commonly as the feed. Therefore it is safe to say that in a network, the feed consists of different reputations or user segmentations matching each other in a tuple of user => content.
Similarly, the reach of users' content is expanded depending on their derived reputation. In dua’s proposed solution, we would like to set the groundwork for a protocol that can evolve as we explore use cases. Regardless of how that reputation is derived, we are interested in keeping track of two data points:
  1. 1.
    What are particular identity reputations at a given time, and
  2. 2.
    An immutable trail on how that reputation is created, updated, and maintained
For each entity, we will have a way to calculate the reputation that can be as basic or complex yet straightforward with a template for the platforms to own this part of the process later. We will estimate it based on general data points relevant to each authority, which will be announced when we launch support for either.
The core concept of owning your reputation is that the user has complete control over whom to expose their reputation for a selected period. We will look into three characteristics when providing reputation:
  1. 1.
    Particular entity the reputation is requested for
  2. 2.
    Its particular sub-reputation
    1. 1.
      For example, a user can have an overall Reddit but also a ‘r/funny-memes’ subreddit reputation.
  3. 3.
    The party should be allowed to view the reputation
    1. 1.
      Identified by a registered public key
  4. 4.
    The time for which the viewing key should be available
We should offer a few ways to retrieve reputations, one with a complete retrieval that returns a number; the other can be in particular ranges. For example, a web service might need to know if the user has a reputation above 50 points, but they do not need to know exactly how much. Similarly, users don’t wish to expose more than they need to join the service mentioned above. Therefore we should support the second manner of querying, which is comparative, queries similar to this user’s reputation in such a manner:
  • Lower than 45
  • Bigger than 80
Since all reputations are stored encrypted with the user’s private key, given that the requesting party provides the following:
  • DUA proof of Payment
  • Their public key identity
  • The request specifics (reputation_id, timespan, etc.)
  • The request query
There will be a proxy-re encryption engine in the middle that sets up the reply from the smart contract with a viewing key for that particular reputation for a particular time until that viewing key expires at which point the third party has no longer access to that reputational value.
Client <> User Interaction diagram
The relation between reputations and sub-reputations will be defined in encryption design using hierarchical deterministic keys to have a more distributed level of protection.


To mark various reputational milestones, we can provide service providers with a contract to create NFTs and other on-chain rewards for users that achieve a certain reputation within a platform. These NFTs can be used to authenticate in different network layers and as flair. They can be tradeable or non-tradeable based on the AE’s community architecture design. We also plan to provide NFT giveaways for marking certain milestones with our users. These NFTs can then be used to authenticate for perks, on-chain rewards, or other access levels.
Having users own their identity means they also own and protect it from us as a service provider. In web3, the stakes are high; therefore, we ensure that we can provide proof of access to the identities and their attached reputational information using cryptographic proofs. Thus, even if we wanted to arbitrarily:
  • See personal data
  • Modify data
We cannot cryptographically do it without there being a clear sign of tampering publicly available. That ensures our identity protections and data reveals are protected by encryption from keys only the particular user has. Even if we wanted to, we could not reveal the data stored underneath.
We wish to keep our data flow honest and up to date; for that, we have allocated a bounty to explore if someone finds an inconsistency of data between what we have on our on-chain representation and what is presented off-chain.