Creditor Authentication Options

The CredSperiment Research
#1

Introduction

SourceCred is building an authentication service. This service will provide users in communities that utilize SourceCred to:

  1. Claim and link accounts across supported plugins
  2. Manage Grain awards
  3. Access administrative tools for their community if they are so empowered
  4. interact with creditor
  5. …more features as they emerge

In short, this will be a significant piece of code, as far as UX goes. This is complicated (perhaps enhanced?) by the fact that this will be an onchain integration, meaning that users of SourceCred will be interacting with the blockchain.

We’ll want to provide some way to auth directly with Discord and Github (ideally via some keybase-like proofing model so users can transparently revoke permissions as needed). However, the question around which web3 provider we want to point users towards is non-trivial.

There are many web3 providers, which link users securely to the ethereum blockchain. Some require a paid developer subscription. Some have really friendly UX and recovery tools.

Some Questions for us to think about

When the ethereum plugin is active in a sourcecred instance, what should the user see?

Do we show them an unopinionated list of web3 providers?

If not, what do we want to promote for new Users?

Some Existing Options for Web3 Providers

  • Torus
  • metamask
  • rainbow?
  • argent
  • coinbase custody
  • Portis

Let’s discuss these questions and options together here and arrive together at the best UX that balances our ability to retain some scope of control, cost, and good UX/Onboarding

#2

Thought about this further, and after having a meeting with Ceramic team today I’m leaning towards https://idx.xyz as one of our top 2-3 options. They are launching testnet next week and have SDKs / docs etc ready to start implementing with.

This enables a lot of use cases for us beyond account linking (e.g. the “metanomics” structure @decentralion described for inter-community cred flows). Another use case would be to store config for weights etc on Ceramic with the same versioning / history of changes we get from storing config in git. Think of it as each document being a distributed git repository with its own commit history and links to other documents.

Its also completely chain agnostic and can easily integrate with things like Torus and BrightID (BrightID integration already being implemented actually), which enables good forward compatibility with systems we might integrate with in the future.

In terms of performance, they aren’t loading the entire state client side anymore which is what made 3box really slow, so we can run our own nodes if we want to act as indexers for better perf.

The downside is that this will still be a pretty early stage bet on IDX/Ceramic, and that we might want to prototype something of our own first and see how the testnet plays out. FWIW MetaGame / 1Hive / Gitcoin / RaidGuild / DAOHaus / BrightID and other big players are all in on IDX. 3Box has strong existing foothold as well and they will be fully migrating all that to IDX.

Link to notes from our past calls: DProfiles community calls - HackMD