ethDenver Project Development Plan

[hebbianloop]

Web3 Avatar and DID for Scientists

• Links scientist login credentials with user-readable public address
• Imports academic credentials and activity into a decentralized schema
• Allows scientists to claim and mint achievements for their academic activities

Research Back-End Identity Management

• [ ] - Overview of Web3Auth
• [ ] - Overview of Self.ID // Ceramic
• [ ] - Ecosystem Architecture Diagram: How does the DeSci-DID fit into a flourishing commons for DeSci?
• [ ] - Low-Level Architecture Diagram for Identity Login
• [ ] - Assemble Notes on Ceramic + DID

Project Goals

• [ ] - Simple front end with Web3 Login
• [ ] - Simple front end with Web2 Friendly Log-in
• [ ] - Integration with ORCID: LogIn
• [ ] - Integration with ORCID: Read Records
• [ ] - Integration with ORCID: Write Records

Questions

• [ ] - Onboarding flow for profile completion? (GTC model?)
• [ ] - How to demonstrate cross-compatibility across science apps?

References

https://profiles.impactstory.org/u/0000-0001-6728-7745/achievements https://docs.web3auth.io/ https://info.orcid.org/documentation/ https://github.com/ourresearch/impactstory-tng https://github.com/dabit3/decentralized-identity-example https://docs.web3auth.io/usecases

[hebbianloop]

Came across OpenAlex today, it seems to be a much more general tool / API than ORCID. Highly recommend exploring more in detail. https://docs.openalex.org/api

[hebbianloop]

Summary: A portable identity and personal digital locker for scientists to track their academic impact, link their credentials across ecosystems, and verify ownership of published digital knowledge artifacts.

Features:

1. Linked Academic Credentials
2. Verifiable Achievements
3. Personal Data Locker for Free Storage
4. Rails to Publish Datasets, Papers, and Code on a Smart Contract Marketplace

Architecture Overview (1st draft):

• How to Onboard?

  1. Standard Login --> they should also be assigned a prv/pub keys
  2. Claim ID
  3. Complete Profile

• Define Academic ID Schema. What are useful fields? Accounts

  * email
  * DID: (string: public key)
  * ENS: (string: ethereum name service)
  * openalex (String: this author's OpenAlex ID. Same as Author.id)
  * orcid (String: this author's ORCID ID. Same as Author.orcid)
  * mag  (Integer: this author's Microsoft Academic Graph ID)
  * wikipedia (String: this author's Wikipedia page)
  * scopus (String: this author's Scopus author ID)
  * twitter (String: this author's Twitter handle)
  * github
  * open science framework
  * discord

  Profile

  * Nickname // Handle
  * Institution
  * Bio
  * Field of Study
  * DAOs or Organizations

  Achievements

  * Verified: signed with key pairs
  * Unverified: all other imported achievements

  Published Assets

  * Papers
  * Code/Containers
  * Datasets

• Schemas will live on Ceramic with Storage on Estuary Miro Board

  • log in through ethereum account
  • check if did doc exists
  • if not, fetch it
  • datasets associated with DID
  • data stored in data locker are personal access only
  • can upload to estuary, adding metadata to ceramic along the way

• Web3Auth for Onboarding: Generates a Key Pair, nodes store key chunks (pay for >1000 users)

[NiklasTR]

I talked to Shady about this project 2 days ago - it is really exciting! Building a trusted on-ramp to web3 by giving an easy ORCID-linked way to generate a wallet is going to be super interesting. I checked google domains, and there are interesting domains one could use for this on-ramp, including "rabbithole.science".

Excited to meet you in Denver!

[kinshukk]

A key question we have right now - how should the authenticator be implemented? For posterity's sake, here's some options we were toying with:

Ceramic DID document - we can define a schema (upgradeable) with the fields we'd like, connected to the user's wallet.

Pros:

• easily forkable and composable - just create a new schema with a ref to the one you want to extend
• access control is already present - you can select what data you want public, and can also include private info (maybe draft datasets / research material CIDs)

Cons:

• depends on longevity of the ceramic protocol + breaking changes happening quite frequently

  Non-transferrable NFTs - with fields that can be populated by the owner. Similar to ENS

Pros:

• easy to understand due to existing ENS standard

Cons:

• ownership is intrinsically tied to the wallet - if wallet is lost, identity lost too

Smart contract storage, likely on an L2. Hashmap that'll link addresses to a struct with fields. Functions to populate each field using auth tokens, but gas might be an issue. forking is difficult, as is the issue of all data being publicly viewable

Pros:

• easy to implement
• quick lookups, can make it into a graph

Cons:

• gas
• everything is public

[hebbianloop]

I think that Ceramic is pretty much hands down for the sole reasons:

1) potentially permanently losing your academic identity is a non-starter xD 2) gas is expensive, smart contracts are not easily upgradeable

since this is just a demonstrator application, i believe that ceramic is a great place to start

slides have been posted as well! critical feedback welcome

https://docs.google.com/presentation/d/1rVNy8Z5iWHmrt0YJdYtpdif1FslLu90HCczNiUAa2OE/edit?usp=sharing

[keesvanbochove]

See also: https://pidforum.org/t/creating-resolvable-pids-without-registering-them-in-a-registry-through-cids-and-ipfs/1165/3