Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
In partnership with Protocol Labs, we’re excited to welcome builders from everywhere to APOLLO, your mission control to engage with the builder…
We’re excited to publically announce that Matic Network is partnering with Gitcoin to launch the Build-n-Earn Program – assisting dApps t…
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
Currently when you approve a new device to use your app, it is by default a "management key" which means that it has unlimited powers to do anything they want to the contract. The only limits on keys are given by the `purpose` and the `requiredApprovals` number set by ERC725 standard. This is insufficient.
Consider the case in which you might want to add a phone that is able to add and approve new devices on the contract, but you want to set limits on how many new keys they can add in one day to prevent abuse. Or maybe you want to be able to add access to a very limited scope, maybe a key that can only interact with a single contract. To do that we need to either replace or improve the `key purpose` concept with an "authorization contract" that authorizes a key to do things according to a given set of rules.
We want to keep the types of authorization contracts open, so for the purpose of this issue we would simplify with 2 example authorization contracts:
* a contract that limits which contracts that key can interact with. It can be set to no contracts, only one specific contract, or any contract
* a contract that limits the amount of "addKey" operations that each key can do, on the identity contract, per day. By default the logic would be: after adding N new keys, no new "addKeys" operations are accepted for N days
A proposed layout for how this would look for the user would be similar to the authorization screens of android or facebook apps, to be added on the "pendingAuthorization" screen: