Composability: let the NFT asset react to permissions being set #12
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the NFT has state that depends on the SACD permissions, currently there's no way for it to know the permissions changed (before someone calling it after permission change). This is similar to a contract receiving ERC20 tokens: the contract doesn't get notified. It's in contrast to a contract receiving ether: the receiving contract gets a chance to update its state (fallback / receive function). This is quite beneficial to composing smart contracts: if setting SACD permission activates the target NFT as well, it can keep its own state updated, so that all contracts stay in sync.
jtakalai
pushed a commit
to jtakalai/dimo-identity
that referenced
this pull request
Feb 17, 2025
…gistry when SACD permissions change * designed such that adding more (similar) integrations doesn't require any further changes to SACD or VehicleId, only to the specific module, plus misc integration specific contracts * "similar" meaning integrations that only need to know when the permissions change. More hooks to SACD may be needed for integrations that have other needs. This change (including the SACD change in DIMO-Network/sacd#12 ) doesn't try to look into the future, only adding the minimal required for restoring the Streamr integration. * added complexity: deployment of a new StreamrSacdListener contract. Reason is: we add callbacks to the VehicleId NFT by address only. All modules in DimoRegistry share the same address, so if in the future we want to add more listeners that talk to different integration modules, they can't clash. An option to deploying a new contract is to add both address and selector as callbacks. This one is more readable, and not really more expensive either to deploy. There is one more hop when calling it, so the address+selector callback could be a gas optimization later. * added the deployment and setup of the StreamrSacdListener to deploy.ts as well as the test. This needs to be updated in production later (including SACD upgrade), should be straightforward.
elffjs
reviewed
Apr 9, 2025
| * @param permissions The uint256 that represents the byte array of permissions | ||
| * @param expiration Expiration of the permissions | ||
| */ | ||
| function onSetPermissions(uint256 tokenId, address grantee, uint256 permissions, uint256 expiration) external; |
There was a problem hiding this comment.
@zer0stars Our Vehicle NFT will have to be updated every time we want to handle a certain permission on a vehicle in a certain way. Unless we invent some other contraption. Are we okay with this?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the NFT has state that depends on the SACD permissions, currently there's no way for it to know the permissions changed (before someone calling it after permission change). This is similar to a contract receiving ERC20 tokens: the contract doesn't get notified.
It's in contrast to a contract receiving ether: the receiving contract gets a chance to update its state (fallback / receive function). This is quite beneficial to composing smart contracts: if setting SACD permission activates the target NFT as well, it can keep its own state updated, so that all contracts stay in sync.