Shunkichi Sato

> ## Phase 2: Trigger Scope Restriction via Subscribe Permissions > > - Introduce "subscribe permissions" to control which state changes a trigger can listen to. > - Prevents unintended...

Query permissions (Visibility Control 1)

2

This makes sense even if transaction payloads are not encrypted, as long as: - Access to the block streaming endpoint is restricted to certain IP addresses - The permissions for...

Is it acceptable that time triggers can fail without offering a retry opportunity, unlike user-submitted transactions?

https://github.com/hyperledger-iroha/iroha/pull/5354#discussion_r2007110577

feat: generic structure through execution cycle

1

## Context Tracking issue: - #5356 This PR introduces an abstract structure applicable to executables, events, event filters, and permissions to streamline the execution cycle. - No API changes are...

Namespace dimension vs. lightweight IDs

4

### Current Design - Account keys and domain names are orthogonal in `AccountId` - Asset names and domain names are orthogonal in `AssetDefinitionId` - `AssetId` is a cartesian product of...

#5355 is enabling an arbitrary expression of permissions. This may lead to the removal of the executor's role in __defining__ permissions, leaving it solely responsible for __interpreting__ them.

Grant/Revoke rules

1

In the current default permission system, Grant and Revoke instructions follow a single rule: users can only grant or revoke permissions they already possess. While granting is straightforward, revoking introduces...

> I don't think those revokes are currently expected to be infallible. For example, who `CanUnregisterDomain` can fail to revoke `CanModifyDomainMetadata` in `visit_unregister_domain`. > Or we could consider this as...

Multisig dedicated tables

2

The current multisig implementations, which fully utilize metadata for storage, may lead to inconsistencies between roles and account metadata. --- Suppose that there are: - multisig account `msa01` whose signatories...