๐จโ๐ป User Story
As a developer I want to easily add Account input fields in my Web3 application.
More specifically I want an <InputAccount />
component to handle validation, fetching metadata and rendering details like a profile picture (PFP) using an address, domain or identifier as the input.
๐ Disclaimer
To be eligible for the payout you must first get approval to work on the bounty.
It's recommended to share a link to your personal Github account.
๐งฑ Project
Create a Input component that accepts account
, domain
and identifiers
as inputs.
- Account: Ethereum address i.e. 0x121...212
- Domain: Web3 domains i.e. Ethereum Name System
- Identifiers: Decentralized identifiers (DIDs) and related linkages.
The input field should be able to accept any account, domain or identifier data and output (resolve) a valid address.
For example:
- Input is
0x121...212
the output should be 0x121...212
- Input is
kames.eth
the output should be 0x121...212
- Input is
did:3:ky92v...19al
the output should be 0x121...212
- Input is
twitter:kamesgeraghty
the output should be 0x121...212
- Input is
discord:metasudo#4209
the output should be 0x121...212
Accepting all these data types in a single Input
field component will require data fetching from multiple external sources. Reasonable defaults will be included, but we want to give developers the ability to override DID resolver APIs and caching services.
For example to resolve did:3
and linkage tokens like twitter:kamesgeraghty
will use as the default Disco API service. But developers should be able to easily override the default by passing in a new DID and DIDLinkage resolver service.
In addition to resolving the address
for the multiple Input
data types: account, domain and identifier, the component should also resolve a profile picture (PFP) when possible.
Protocols like ENS are already supported in libraries like wagmi/viem.
But a standard pattern for fetching profile pictures from DID providers like Disco and Orbis is an unsolved problem. Resolving decentralized identifiers is generally also more complicated than resolving ENS txt records.
Mockups
Initial designs are available in the BUIDL Figma document.
Technical Specifications
Required Functionality:
- Handle
address
, domain
and identifiers
as input.
- Fetch account metadata like name and pfp.
- Render profile picture and/or identicon.
- Dialog for expanded view and search
- Configurable domain and identifier API services.
Component Views
- Input
- Dialog with Input and Search
- Dialog with domain (i.e. ENS) API configuration
- Dialog with DID Resolver API configuration
Figma Component View Mockups
Input types
- address - Standard Ethereum address
- domain - Ethereum Name System domain
- identifier - Decentralized Identifier
- linkage - Verifiable Credential URN(Uniform Resource Name)
- twitter:[username]
- github:[username]
- discord:[username]
The Input
field should accept and validate all of the above input types.
Input Examples
- 0x761d584f1C2d43cBc3F42ECd739701a36dFFAa31
- kames.eth
- did:pkh:0x761d584f1C2d43cBc3F42ECd739701a36dFFAa31
- did:3:kjzl6cwe1jw149ofmn3uw261yxv5eio39po2auvgdjxyidmxvqufpnsxrgmo2oa
- did:web3:districtlabs.com
- twitter:kamesgeraghty
- github:kamescg
- discord:MetaSudo#5364
Linkages like twitter:kamesgeraghty
should be powered by DID resolver services like Disco account linkage service which consumes social aliases and returns decentralized identity documents and an associated Ethereum address.
Example of searching for addresses by using a linkage.
https://api.disco.xyz/v1/search/?handle=provenauthority
Below is an example of how the component structure might start. The final component structure will likely be much different.
import React, * as React from 'react'
import classNames from 'clsx'
type AddressError = {
code: number
message: string
}
type PfpError = {
code: number
message: string
}
type Props = React.HTMLAttributes<HTMLElement> & {
didResolver?: string
ensResolver?: string
pfpEnabled?: boolean
onAddressResolved?: () => `0x${string}`
onAddressError?: () => AddressError
onPfpResolved?: () => void
onPfpfError?: () => PfpError
}
export const InputAccount = ({
className,
didResolver = 'api.disco.xyz/resolver',
ensResolver = 'api.ens.app/resolver',
onAddressResolved,
onAddressError,
onPfpResolved,
onPfpfError,
}: Props) => {
const [address, setAddress] = React.useState<string>('')
const [pfp, setPfp] = React.useState<string>('')
/**
* TODO: Add domain resolver i.e. kames.eth
* TODO: Add identifier (DID) resolver i.e. did:3 or did:web3
*/
return <InputAccountRender className={className} address={address} pfp={pfp} />
}
type RenderProps = React.HTMLAttributes<HTMLElement> & {
address?: string
pfp?: string
isAddressFetching?: boolean
isPfpFetching?: boolean
}
export const InputAccountRender = ({ children, className }: RenderProps) => {
const classes = classNames(className, 'InputAccount')
return <div className={classes}>{children}</div>
}
๐ฐ Bounty Reward
The bounty reward is 250 tokens and TurboETH DevPass digital collectible.
TurboETH is the recipient of 18,271.88 OP Tokens from Optimism Retroactive Public Goods Funding. OP tokens earned from RPGF are helping fund TurboETH bounties.
Disclaimer
The final integration may not resemble the proposed integration - that's O.K - a natural part of software development.
During development you might discover an original hypothesis doesn't make sense. No problem. Make a comment and clearly explain why a new approach is better than old one. Get rewarded for thinking out of the box.
The final bounty reward can be increased to match new bounty tasks.
Resources