IERC721Roles & IERC721RolesManager

[ArthurBraud]

Introducing 2 new interfaces IERC721Roles and IERC721RolesManager inspired from the feedbacks from ERC-4400: ERC-721 Consumer Extension and ERC721 extension to enable rental.
This aims to provide a general framework to define token roles with on-chain guarantees that roles attribution terms are fulfilled.

IERC721Roles

• Enables to define ERC721 user roles by tokenId. We expect standard nomenclatures for roles to be defined such as bytes4(keccak256("ERC721Roles::Renter")).
• Applications will call roleGranted to check whether a user has been granted a specific role.
• The role attribution logic is delegated to an IERC721RolesManager contract, that is set at the tokenId level. Note that we could have implementations where the role manager contract is defined at the ERC721 contract level to guarantee that roles definitions are consistent across each token.
• Token'sowner is never changed and can be updated independently from the roles

IERC721RolesManager

• This contract holds the logic and terms to acquire and revoke roles.
• It guarantees that roles are honored on-chain, by using callback afterRoleRevoked and afterRoleGranted when someone tries to update a role.
• The IERC721RolesManager is set at the tokenId level in this example, but we could have one unique role manager contract for all tokens as mentioned above.
• When someone tries to update the IERC721RolesManager contract, a callback is made to IERC721RolesManager.afterRolesManagerRemoved so that the manager can revert if a role agreement is ongoing.

Examples:
See ERC721Roles and ERC721RolesRentalAgreement for examples of implementation.
The later is a simple contract to allow NFT rental by granting Renter role

IERC721Roles & IERC721RolesManager interactions

[peroket]

Why did you decide to have an agreement per contract and not per token like we did before? This removes a lot of flexibility, and basically does not allow for renting a token anymore, since everything has to go through that central authority.

Like if I want to rent my token, first the contract creator has to allow it, and then I have to ask them to start and stop the "renter" role. Or did I miss something?

We also loose the flexibility of having a contract agreement per token, everybody has to follow the same rules. No?

[ArthurBraud]

@peroket it's a good question. When writing the contract, I had in mind an application issuing a token with pre-set and fixed roles. For example, a land item in Axie Infinity could have the roles owner, manager, farmer, and consumer. In this case, having the role management defined at the contract level allows the application to deploy the RoleManagement once and have roles consistency.
But I agree it removes a lot of the flexibility plus it requires the contract to define a roles manager. I'll see if I can come up with an hybrid approach