Published in


Reputation & Identity Layer

Today we’re releasing new information about the Reputation & Identity Layer (RIDL) which has just undergone a massive update after careful evaluation of the previous system running in a testing network for months.

It’s been a long road getting to this point, and after massive usage of RIDL in the testing phase we’ve identified some key points that required changes to allow for a more dynamic and useful reputation environment. Let’s dig into some of them below.

You can view the new contract here

What the hell is an EOSIO account?

By far the biggest hurdle for users is having an EOSIO blockchain account to bind their identity to. Not only is this problematic from an onboarding standpoint it also goes against the philosophy that RIDL should be usable regardless of blockchain or network, and shouldn’t incur any added blockchain account setup costs.

In the old system users were required to send transactions to create/manage their identity and assign reputations to entities directly from their blockchain accounts. This means they incurred RAM, CPU, and NET costs as well as basic EOSIO account setup costs. We didn’t feel this in the test networks as they were proprietary privately run networks which paid it all for the users, but in public networks this simply isn’t an option as the costs would skyrocket to unmanageable amounts.

With the new system the user no longer needs to manage an EOSIO account. Instead, RIDL uses cryptography to validate reputes and identity management. The actions themselves can then be sent from any public account without risking modification of the user’s actual intent by the sender. We will be supplying a back-end API which accepts signed and verified parameters which will then be sent off to the blockchain using our own accounts with properly managed resources so that there’s always at least one entity providing a sending service, but anyone can become a sender.

For the techies, this means when you want to rate an application you would be doing the following:

const block_num = // current head block from chain;
const entity = '';
const fragments = [{"type":"overall", "value":1}];
const tokens = '1.0000 RIDL';
const cleartext = `${identity_id}:${entity}:${block_num}:${ => `${x.type}${x.value}`).join('')}:${tokens}`;
const signature = sign(sha256(cleartext), IDENTITY_PRIVATE_KEY);

The signature is then checked on chain to verify that it came from the public key registered to the identity, meaning anyone can send your transactions for you. To top it off, senders also get 5% of the RIDL usage tokens which were used in the repute for each transaction they send, allowing technical users to gain more usage tokens to use with their own identities.

Many chains, single output source.

In the old system, RIDL contracts were deployed on a single chain which completely encapsulated all identity and reputation data. This meant that any global friction on a given chain could impact the usability of RIDL (for instance CPU issues or RAM costs on a single chain could become an issue).

With this update, the RIDL contracts only hold the metadata of identities, and not of historical reputes, fragments (what makes up an entity’s reputation) or reputed entities. The contract now only handles the movement of usage tokens, validation checks, identity existence and signature verification.

A separate caching back-end can simply catalog and aggregate the reputations and identities from the chain, while using the blockchain as a source of truth. This also means that RIDL contracts can exist on many many chains where the resource costs are different, and have all of their data aggregated into a single export.

For instance, you can have reputes of Everipedia on EOS, TELOS, BOS, WAX, LYNX, and any other chain which all get merged together inside of the API to create a single cohesive reputation for the entity.

The user never needs to know what chain they are on, or that they are even on a blockchain at all. The verifiable historical proofs are there and having them on many chains at once means there’s always a level of historical redundancy to compliment a system that provides something as important as identity and reputation.

New mining systems

Since entities are no longer stored on chain, and knowing the “last miner” isn’t possible, we’ve shifted the usage token mining system to align with this update.

  • The last identity to repute takes 10% of the usage tokens used in the next repute.
  • The sender takes 5% of the usage tokens used in any transaction they push to the blockchain. (we talked about this one above)

For the last identity mining system, this means if the user to repute after you uses 10 RIDL to assign a reputation to an entity, you will get 1 RIDL into your identity. Not only does this keep usage tokens circulating through the system naturally, it also promotes usage of the system. Usage tokens mined from the the next repute also bypasses the 24 time constraint you hit when you load tokens into your identity from an account, and a final plus of this system is that usage tokens mined from the next repute will also bypass your expansion limits (which is a limit you have on how many tokens you can load into your identity at once, starting at 100 for each identity).

Some much needed action(s)

Due to some of the constraints of pushing things like prices to the blockchain and for stability reasons, a few new actions were added to the contract which are:

  • init— This sets a manager account into the contract which is the only account allowed to create identities and do some other managerial actions like moving tokens and identities from chain to chain. It doesn’t have to be the contract owner, and we will eventually move this to a more decentralized system once a few other pieces are in place. init also sets the starting block of the contract after the first time called, so that we know when to start watchers at for the API.
  • activate — Because there is a difference in time between paying for an identity and a transaction being irreversible (and very different on different chains, as we won’t just be allowing payment with a single payment method) identities can immediately be created once sufficient checks are completed. Once the payment becomes irreversible then an identity will be set to activated which will allow its owner to manage the identity and apply reputations.
  • revoke — This allows a manager account to revoke an identity which might have had an identity created but their payment for it reversed. This can only happen when the account is not yet activated.
  • moveidentity — Move identity allows a manager to move an identity from one chain to another. This can be used in the case that a chain has become unstable or unusable, and simply provides proof that the identity has moved.

The following actions were changed:

  • identify— Only the manager account can create new identities in the contract now, as payment can happen outside of the realm of the blockchain (using credit cards, paypal, etc). In the future there can be an option to allow for a secondary payment contract to also have creation access by assigning something like liquid oracles as a price pusher.
  • repute— There is now a lower limit on the amount of usage tokens that must be used when reputing. You must use at least 0.2 RIDL for each fragment that is included in the repute. This change is related to the mining system, so that people don’t abuse it by using 0.0001 RIDL to repute constantly in an effort to gain 10% of the next identity’s usage tokens.

The Foundation for Interwallet Operability (FIO)

On top of RIDL, we’ve also prepared integration for FIO for when their mainnet launches soon. FIO provides a layer on top of identities that can link accounts together under a common name (such as nathan@scatter). You’ll be able to link your blockchain accounts to your identity name and have users on any of the FIO supporting wallet send you funds without knowing your blockchain accounts/addresses. You can see some of the supporting wallets here.

Once live, you will also be able to apply reputations to identities! So when you go to send scammer@wallet some funds, it’ll notify you that they have a bad reputation, and that you shouldn’t. Or if you just want to piss off your friends and give them bad scores, you totally can. You psychopath.

Reserved identities?

We didn’t forget about you, don’t worry :)

  • We’ve registered every reserved identity holder an @ridl FIO name which will be linked to the key you used to reserve your RIDL identity.
  • Instead of starting with a maximum of 100 RIDL that can be loaded into your account, you start with an expansion of 5000 RIDL (the equivalent of loading and using 50,000 RIDL to repute entities over a long period of time). This means you will be the most influential identities on the network when it starts, as you have much more reputing power.
  • You will also start with 1000 RIDL loaded into your identity, instead of the normal 20 RIDL, which means you’ll be able to repute entities between 1000–5000 times (depends on how many stars you give) just by claiming your identity.

Okay okay, enough tech talk, show me pretty images.

A lot of you were worried when you noticed that the Scatter 12 release had the RIDL panel removed. The technical reason behind this was that it was originally an embed of which can’t be embedded into ScatterEmbed, but it also signified the end of the testing period and us wanting a deeper integration into Scatter itself.

We’ve come to the conclusion that ScatterEmbed (the advanced UI) is mostly just too hard for users and we’re going to configure the wallets to default to “Simple Mode” (Bridge). We’ve been quietly hammering away at Bridge for the past few months and it’s a monstrous improvement in terms of user-experience, stability, and ease of use. RIDL has been re-integrated into Bridge and it looks awesome.

Setting up your identity is part of the new onboarding flow
Setting up your identity from the identity->digital panel
Managing a registered identity, you can: export keys, change keys, and unlink an identity
Your wallet now shows you an app button for tokens with applications registered under the token name (with a nice little rocket next to it, naturally)
Clicking on an app from the wallet or the app explorer now shows an app rating popup instead of instantly going to the application so that you can see what it’s about and what others think of it.
You’ll be able to apply ratings to any application within Scatter, and even add details about why you think the way you do (express yo’self!).
Once you’ve rated an application, it’s then visible to all.
Once FIO is live, you will be able to easily send funds from one account to another using nothing but the identity name.

In short, there is some really exciting things coming down the pipeline, including but not limited to RIDL. And for those of you who are about to ask “But what about mobile?”… This is actually the mobile UI, and we have a working prototype of the new mobile wallet container almost ready to be open-sourced.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store