Impact: High
Likelihood: Low
According to the discussion with the team, it is expected that in Space
contracts, only one Role can have the Permissions.Owner permission.
Currently, multiple Roles can be created containing this permission.
This is caused by Space.sol’s createRole() function allowing the
OpenZeppelin owner to create new owner-permissioned roles without limit.
Remediations to consider:
Do not allow multiple roles to be created with the ownership permission.
This could be done with something like: if Space.sol’s ownerRoleId is
set, do not allow new roles to be created with the Permissions.Owner
permission.
Fixes HNT-703 as well
Removing the OpenZeppelin ownership logic, and, checking directly for
the ownership of the Space’s SpaceOwner NFT. The SpaceFactory could be
the owner during the bootstrapping phase, and afterwards, could transfer
the NFT to the proper owner. Doing a direct check like
_spaceOwner().ownerOf(tokenId) == _msgSender() would be safe because
that’s what the owner entitlement is going to check eventually.
---------
Co-authored-by: Kerem Kazan <kerem.kazan@gmail.com>
Overloaded isEntitled func in ISpace.sol and Space.sol caused the generated client types to turn into string names. Renaming one of them to isEntitledToChannel.
- Add new functions to modify role name, permissions, token entitlement
and user entitlement with a single call
- Add new solidity tests for the new functions
- Re-generated TypeScript and Go types for both localhost and goerli
Issue: matrix room id does not always resolve to spaceId or channelId
correctly.
Root cause: The clientApi routing endpoint and the syncapi routing
endpoint uses different stores to query for the current room states.
One is correct, the other has incomplete events. Fix the issue by using
the correct store in both routing code paths.
- space manager catches error when adding roleId to channels so that
client can get meaningful error
- Update the createChannel tests to expect the new error AddRoleFailed
- Re-generate localhost and goerli types
Closes HNT-244.
The following PR implements Space,Channel soft deletion using on-chain
`disabled` flag scope to space, channel respectively. On message sync,
dendrite will now gate disabled rooms by performing a leave on the user
attempting to sync unless the user is the owner (more on this later). To
re-join, given rooms (spaces,channels) are created by default using
`invite` membership state, the owner will need to undo the on-chain
`disabled` flag, setting it false then re-invite users that left the
room as a side effect of it becoming disabled previously.
The owner does not leave the space, channel because if they did then
there would be no one left to invite users let alone themselves back in
if the action is ever undone.
What is not implemented in this PR:
1. **Transitive leaves on channels in a space** - If a space is
disabled, users will leave the space but not the channels within the
space. To allow for fully disabling a space and all its' channels, the
client can offer a view to the owner that iterates over the channels and
space to disable all on-chain. Furthermore, we could implement a batch
on-chain method that fully disables all channels within a space (plus
the space) in one on-chain call to save the owner gas.
2. **Data deletion** - No data is remove from the DAGs or on-chain.
Therefore deletion is soft and reversible.
3. **New hook to check if a room is disabled** - the client can leverage
existing on-chain public read only methods `getSpaceInfoBySpaceId`,
`getChannelInfoByChannelId` to read the state of each in order to remove
spaces, channels from a member's view that are disabled.
Need the address to implement the ZionRoleManagerShim
I ran this in zion-governance/ and it worked :
forge script scripts/Local.s.sol:DeployLocal --rpc-url
http://localhost:8545/ --private-key … --broadcast
space-manager.json has the rolemanager address
This PR finishes changing all the public interfaces at the moment for
space creation and updates the client.
All integration and forge tests passing.
Local and Goerli ABIs generated.
Co-authored-by: g <5714678+giuseppecrj@users.noreply.github.com>
This change updates token entitlement data structures and allows for
multiple tokens to be set for a single role, permitting the AND
operation for multiple token requirements.
It also decodes structs when creating a space and setting a new token
entitlement.
Added new tests for multiple tokens gating a role.
Also generates localhost AND Goerli ABIs.
Forge and integration tests all pass
