---
# System prepended metadata

title: InterRep Roadmap

---

# InterRep Roadmap


## Internal improvements
- Add Github badge
    - Determine criteria for what makes a github account reputable enough
    - Add Github as reputation provider
        - new DB schema, add GitHub to Next-Auth, implement reputation checks and new controller / API routes, adapt methods related to current badges
        - Same smart contract as for Twitter could be re-used
        - UI update (incl. refactoring of homepage for better upgradability)
    - **Output:** Similar functionalities as for Twitter currently but with GitHub

- Update minting process
    - **Output**: Update InterRep to have batch minting (with gas being paid by the server) while still allowing users to mint directly themselves (gas paid by the user)
    - Setup a queue system
    - Trigger batch minting every 1 hour? 4 hours? once a day?
    - Update UI
    - *Considerations*: Need to keep track of the option chosen by the user. This could be added to the token schema in DB. It's probably safer and easier not to allow users to change their mind. BUT someone might accidentally pick direct minting and not be able to pay for gas (0 balance for instance). 

- Place users in semaphore groups based on number of Twitter followers
    - **Output**: Without revealing who they are, users will be able to prove they have a high reputation on Twitter as signaled by the number of followers, i.e prove that they have more than 1000 followers, 10000 followers etc...

- Multi chain support
    - We're headed towards a multi-chain world and InterRep should let users have their badge where they need to use them. 
    - *Considerations*: Unlike some other DeFi apps that can have different instances launched on different chains and running in isolation, InterRep needs to keep track of users' badges and ensure 1 badge per (Twitter for example) account. Currently the way users can unlink their Twitter account is by burning their badge first. We can track the unique badge id across chain but migrating a badge should be done by locking a badge on one side and not burning it, otherwise someone would be able to unlink their account during the migration process. 
Maybe we can keep track of whether a specific badge id is associated with an address in a canonical merkle tree. If it is, minting is allowed on any supported chain. 
In case the badge is revoked it is marked as such in the merkle tree.
    - **Output**: InterRep upgrade allowing InterRep's badges to be on several L2 and side-chains (list TBD, Optimism, Arbitrum, Polygon?)

- Export reputation from Reddit (karma) on chain
- Aadhaar integration

- Verification via payment (Cardholder badge?)
    -  **Output**: Users would be able to get an on-chain proof that they made a small payment to InterRep.
    -  *Considerations*: Need to make sure it relies on customer info and not CC number because some neo-banks such as Revolut lets you generate new disposable credit cards (~= sybil attack!) 
    -  Integrate Stripe? (Not available in all countries) Need a legal entity? 

- Deploy an InterRep subgraph
    - Using The Graph, it would make it easy for applications to query on-chain data from InterRep smart contracts. It will be even more relevant later down the road when there will be multiple badges and you want to quickly lookup all the badges owned by an address.

- Decentralization (not a priority)
    - Is a centralized database really necessary (or is there a way to decentralize that part)? Today, it is used to mark a Twitter account as being linked to an address and allows someone to unlink it.
    - Replace centralized server with Chainlink and/or potentially [Aleph](https://aleph.im/#/)?

## Integrations on top of InterRep
- Testnet faucet
    - **Output**: Create a faucet on Ropsten that only authorizes addresses with a (ropsten) interRep badge and allows to withdraw X amount of ropsten ETH every Y blocks.

- [Semaphore Auth](https://github.com/ChihChengLiang/semaphore_auth)

- [OneOfUs](https://github.com/weijiekoh/oneofus)


## Current existing threats
- Scenario: a hacker gets access to a user's Twitter account and gets an InterRep badge for their own address. Said user  has their account linked to an address they don't control and no way to get a badge anymore. InterRep can't burn a badge, only owners or approved addresses can.