• Create groups for specific POAP tokens, e.g. ETH2 stakers, or Devcon IV attendees.
• UI should connect to web3 provider, confirm POAP is held for the account, then allow the account to join.

Primary

• R1
• Revise POAP flow
• Revise Social Network flow
• Tag Cedoor on R1 (Revision 1)
• Review Cedoor's feedback
• R2
• Revise POAP flow
• Revise Social Network flow
• Tag Cedoor on R2 (Revision 2)

Secondary
These task may be put on hold in order to meet the March 18th deadline. We could "release them as additional features" if we need to give ourselves that option

• Complete Phone flow
• Complete email flow
• Tag Cedoor on phone/email flows

Ongoing

• Text updates
• Value Prop convo in Notion.

• The group will be maintained on-chain in a smart contract
• Additions/modifications to group membership would be conditionally permitted by, for example, a DAO multisig.
• Group membership queries should be accessible via the APIs to client apps. It should be transparent to the client app that the data is on-chain.

Maybe not for v1 but something to look into for more decentralization:
https://blog.chain.link/oauth-and-api-authentication-in-smart-contracts-2/

Add image in badge URI containing image

To associate with accounts or other data

Ask to connect to wallet

Get a signature from their wallet to ensure they control the address

• Define a data structure for storage in mongodb.
• Code to initialise above
• Code to Insert nodes
• Code to retrieve paths
• API to get groups
• API to retrieve paths
• Save root hashes in the contract

Goerli will be the only surviving test network after the merge, with kovan and rinkeby slated to see EOL by EOY.

What would it take to get a deployment on Goerli?

Thanks!

• Create more user-friendly reputation levels
• Draw up Github reputation criteria
• Update next-auth configuration
• Create new Github db entities
• Create Github service to get reputation parameters
• Create Github Reputation Badge contract
• Make InterRep functions provider-agnostic
• Add Github auth on frontend
• Final tests

• Create a library to derive Semaphore identities
• Integrate the library into front-end
• Create a section to allow users to join Semaphore groups
• Create an API to add Semaphore identities to groups (Merkle trees)

Offchain groups will be managed exclusively offchain. However, the root hashes of the groups will be published as Ethereum logs to ensure the integrity of the Merkle trees used for the groups. To save ethers we wil publish the root hashes once a day. Costs on Arbitrum should be about ~1 USD per day for 20 groups.

Resources:

• node-cron
• node-schedule
• toad-scheduler

Legitimacy of these badge relies on the security of the server, so we should make sure the deployed version is properly secured. firewalls, monitoring, etc.

contract management keys offline

Start to build our own db, starting with users who are

• obviously a bot: has no profile picture, no followers, no or few posts
• obviously not a bot: curated list of people we know from crypto, and who they follow (1 degree out)

Only send the rest to botometer. Use botometer as one info source.

Want to give our own score, to which botometer is an input, not the only source of data.
API - what do we return for both? A score, a boolean? ("Verified: true")

Primary

• Landing page
• Review outline
• Chunk content by "big idea"
• refine layout
• source illustrations
• refine copy
• App
• Requested updates

Subgraphs should:

• return leaf node details (path, index), given a group and ID commitment
• return all ID commitment leaf nodes for a group

• Could be a list issued by email, or
• Telegram bot, issuing codes to members of a group

Users should be aware of the size of the group they are joining, as the size of the group has implications for the extent of privacy offered by group membership.

MongoDB is running on: Atlas
Have to whitelist IPs

Vercel - nextJS

Research: What do we need to anchor on chain?

• Manage a smart contract
• Sidechain like Matic/Polygon, or L2, Optimism?
• Or our own merkle tree served from our server?

Might be better to run our own VPS to run these services on same box.

• Update documentation structure
• Add guide: Using onchain groups
• Update subgraph section
• Add guide: Creating Semaphore proofs
• Add section: Quick setup (Reputation NFTs)
• Highlight differences between groups

- Estimated time (days): 3
- Actual time(days):

Primary

• R3 (if necessary)
• Revise POAP flow
• Revise Social Network flow
• Tag Cedoor on R3 (Revision 3)
• Review Cedoor's feedback
• Brand
• Ask for list of requested lockups
• Create icon
• Organize logo assets for export
• Create logo asset that incudes value prop
• Source or create illustrations
• Copy
• Refine text when flows are complete
• Add any remaining tooltips, error messages, etc

Secondary
These task may be put on hold in order to meet the March 18th deadline. We could "release them as additional features" if we need to give ourselves that option

• Complete Phone flow
• Complete email flow
• Tag Cedoor on phone/email flows

Ongoing

• Text updates
• Value Prop convo in Notion.

InterRep should allow users to leave groups and then to remove their id commitment.

• Telegram groups
• POAP groups
• OAuth groups

• utils
• core
• controllers

• Draw up Reddit reputation criteria
• Update next-auth configuration
• Wrap Reddit APIs in a function to get reputation parameters
• Create Reddit Reputation Badge contract
• Add Reddit auth on frontend
• Final tests

Change the project name from interrep to interep as part of redesign and logo adoption

• Switch web site to interep.link
• Change github repo name(s)
• Change telegram group name
• Change subgraph name & links
• Change occurrences in code and documentation

• APIs
• Update next and next-auth
• New API design

Web3-react is a minimized React framework for building modern Ethereum DApps. It can be used for managing wallets. UI will be custom and in line with InterRep design.

ZK-keeper is a Chrome extension for secure Semaphore operations. Interep should allow users to use both Metamask and ZK-keeper. If both extensions are active the priority must be ZK-keeper's.

Useful links:

• https://github.com/autism-org/ui/blob/main/src/ducks/zkpr.ts

@0xtsukino

• "mint button" should become disabled after clicking on it
• There should be some indication that minting is in progress

• #87
• #90
• Update Interep subgraph
• Update docs configuration files
• Add check for tree depth on contract functions to create/add groups
• Update Merkle proof parameter names
• Integrate Interep subgraph in @interep/api package for onchain groups
• Create new Interep @interep/proof package
• Update js monorepo configuration files
• Disable feature for leaving groups
• Add not_sufficient group for staging & dev envs only
• New APIs
• #109
• #106
• Define right interval for updating offchain roots on contracts
• Update reputation criteria
• Production deploy

- Estimated time (days): 3
- Actual time (days):

Should we be opinionated about token expiration?
If instead of an expiration date we add to a token its issuance date and write that on-chain, we could leave it to the consumer apps (like faucets) to decide if they accept only addresses with tokens issued in the last year, or 6 months, or 3 years...

• Integrate SemaphoreGroups.sol
• Integrate SemaphoreCore.sol
• Remove OpenZeppelin proxies
• Update tree depth to 20
• Integrate new zk-kit libs

The server is trying to store as little user data as possible, but it must ensure that a Web2 account is only ever linked to one Web3 address at a time, otherwise it defeats the anti-sybil purpose.

Considerations: In case the db is leaked, don't want a record of exactly which Web2 accounts are associated with particular on-chain addresses.

However, when a user links a Web2 account, must have a quick db check to ensure it is not already linked to an address on-chain. Storing a boolean for that account isLinkedToAddress might suffice, but now this data lives in multiple places and would need to be updated to be consistent with on-chain records (expiry periods, revocations, etc.).

Need to think through best way to do this.

Spec docs can live on contracts github repo wiki, announcements published in medium post. Need to explain what we did and why, and what's on the roadmap, before publicizing.

• why we did transferrable tokens, what apps can do if they want non-transferrable
• how we imagine this might be used
• what L2 we chose, why, what we can do in future
• Our human-ness criteria: Why twitter botometer, what we added, what we'll do for Github
• Future ideas: phone number, email, github
• Privacy ideas. How we've encrypted on server. How one could use semaphore
• Why we didn't do keybase style with public attestation on twitter

• Create Telegram Bot (@InterRepBot)
• Create interrep/telegram-bot project
• Create help command
• Create join command and 'join flow'
• Add user hash entry on MongoDB
• Set up Mongoose
• Create leave command
• Refactoring & tests
• Create README usage section
• Create @interrep/telegram-bot npm package

#56

• Introduction
• Reputation criteria
• Tutorials - API integration
• API
• Tech overview - Introduction
• Tech overview - Reputation badges

if possible, can you add *.vercel.app as a whitelisted address for development purposes?

Cheers

To complete

Have Oauth with Twitter to prove users own account

• #98
• #102
• Set new header image (Github)
• Set new icon (Github, Discord, web app)
• Update documentation theme (colors & font)
• General review

- Estimated time (days): 10
- Actual time (days):

How to anchor user addresses and reputation proofs on-chain?

Quick check on-chain for a non-transferable NFT:
https://github.com/ethereum/EIPs/issues

• More decentralized

Reputation proofs in merkle tree relies on server being reponsive

Name brainstorm:

Reputable
NoSybil
Chain auth
Verisky
Verif
RepCheck
RefCheck
CheckSome
InterRep
InterAuth
Inter Verify
Cross Verify

• Create Material UI components
• Add theme colors
• Add a link to the project
• Split big components
• Create abstraction for calls to API and error handling
• New Twitter reputation service page
• Better organize React components
• Add Etherscan contract links
• Create new UX
• Handle web3 React context
• Add minted token references