refac: renaming agent functions to deregister and removing payer key (#119)

Renames the permission terminology from Grantor/Grantee/Grant to
Delegator/Recipient/Delegate. This plays better with the terminology
throughout the project.

Author: saiintbrisson

Cargo.lock

@@ -112,15 +112,15 @@ pub struct NamespaceScope<T: Config> {
 }
 ```
 
-The namespace permission scope contains a set of paths that the grantee can access. The permission system's existing infrastructure handles the complexity of duration, revocation terms, and enforcement authorities. This means namespace permissions can be temporary, require multi-signature revocation, or include third-party controllers. Read more in [permission0.md](permission0.md).
+The namespace permission scope contains a set of paths that the recipient can access. The permission system's existing infrastructure handles the complexity of duration, revocation terms, and enforcement authorities. This means namespace permissions can be temporary, require multi-signature revocation, or include third-party controllers. Read more in [permission0.md](permission0.md).
 
 This integration creates composition possibilities. An agent running a data aggregation service could delegate read access to `agent.alice.data.public` while keeping `agent.alice.data.private` restricted, or delegate the entire data scope: `agent.alice.data`. The delegation could be time-limited, revocable by designated arbiters, or controlled by enforcement authorities who verify off-chain conditions.
 
 ## Practical Applications
 
 A memory service agent registers `agent.memory` and creates specialized sub-namespaces like `agent.memory.twitter`, `agent.memory.discord`, and `agent.memory.telegram`. Each represents a different data source with potentially different access requirements. The agent can delegate read access to `agent.memory.twitter` to analytics agents while keeping other sources private.
 
-A compute marketplace might use `agent.compute.gpu.nvidia.a100` to represent specific hardware resources. Delegating this namespace grants access to submit jobs to those specific GPUs. The hierarchical structure naturally represents the hardware taxonomy while permissions control access.
+A compute marketplace might use `agent.compute.gpu.nvidia.a100` to represent specific hardware resources. Delegating this namespace delegates access to submit jobs to those specific GPUs. The hierarchical structure naturally represents the hardware taxonomy while permissions control access.
 
 API versioning is viable with paths like `agent.api.v1` and `agent.api.v2`. Services can maintain backward compatibility by keeping old namespaces active while encouraging migration to newer versions. Permissions can be time-limited to enforce deprecation schedules.
 

docs/namespace.md

@@ -8,14 +8,14 @@ The concept draws inspiration from multi-level competency networks that self-org
 
 ## Permission Contracts
 
-A permission contract forms the foundation of the delegation relationship. Each contract defines the relationship between a grantor (who delegates emissions) and a grantee (who receives the delegation authority). The contract specifies allocation parameters, distribution controls, duration, and revocation terms.
+A permission contract forms the foundation of the delegation relationship. Each contract defines the relationship between a delegator (who delegates emissions) and a recipient (who receives the delegation authority). The contract specifies allocation parameters, distribution controls, duration, and revocation terms.
 
-Permission contracts are identified by a unique `PermissionId` generated deterministically from the grantor, grantee, scope, and creation block. This ensures contracts can be consistently referenced and avoids collision issues when multiple contracts exist between the same parties.
+Permission contracts are identified by a unique `PermissionId` generated deterministically from the delegator, recipient, scope, and creation block. This ensures contracts can be consistently referenced and avoids collision issues when multiple contracts exist between the same parties.
 
 ```rust
 pub struct PermissionContract<T: Config> {
-    pub grantor: T::AccountId,
-    pub grantee: T::AccountId,
+    pub delegator: T::AccountId,
+    pub recipient: T::AccountId,
     pub scope: PermissionScope<T>,
     pub duration: PermissionDuration<T>,
     pub revocation: RevocationTerms<T>,
@@ -62,11 +62,11 @@ pub enum EmissionAllocation<T: Config> {
 }
 ```
 
-With `Streams` allocation, portions of the grantor's incoming emissions from specific streams are diverted according to the percentages specified (0-100%). Each stream ID represents a distinct emission source, allowing for fine-grained control over different emission types. For `FixedAmount` allocation, a specific number of tokens is reserved from the grantor's account at contract creation.
+With `Streams` allocation, portions of the delegator's incoming emissions from specific streams are diverted according to the percentages specified (0-100%). Each stream ID represents a distinct emission source, allowing for fine-grained control over different emission types. For `FixedAmount` allocation, a specific number of tokens is reserved from the delegator's account at contract creation.
 
 The `targets` field identifies recipients with associated weights, determining how tokens are distributed among multiple targets. For example, with targets A (weight 1) and B (weight 2), target B receives twice the tokens of target A.
 
-The `accumulating` boolean determines whether emissions should actively accumulate for this permission. This flag can be toggled by the grantor or enforcement authorities to temporarily pause emission accumulation.
+The `accumulating` boolean determines whether emissions should actively accumulate for this permission. This flag can be toggled by the delegator or enforcement authorities to temporarily pause emission accumulation.
 
 ### Curator Scope
 
@@ -90,7 +90,7 @@ const WHITELIST_MANAGE   = 0b0000_0100;
 const PENALTY_CONTROL    = 0b0000_1000;
 ```
 
-> `ROOT = 0b0001` exists but is reserved for future use. For now, only the SUDO key is able to grant curator permissions.
+> `ROOT = 0b0001` exists but is reserved for future use. For now, only the SUDO key is able to delegate curator permissions.
 
 The `cooldown` option provides a rate-limiting mechanism for curator actions.
 
@@ -109,7 +109,7 @@ pub enum DistributionControl<T: Config> {
 
 The distribution control mechanism provides flexibility in how emissions flow through the network:
 
-- `Manual`: The grantee must explicitly call `execute_permission` to trigger distribution
+- `Manual`: The recipient must explicitly call `execute_permission` to trigger distribution
 - `Automatic`: Distribution occurs when accumulated amount reaches the specified threshold
 - `AtBlock`: Distribution triggers at a specific block number
 - `Interval`: Distribution occurs periodically at the specified block interval
@@ -132,7 +132,7 @@ Revocation terms define how a permission can be revoked before its normal expira
 ```rust
 pub enum RevocationTerms<T: Config> {
     Irrevocable,
-    RevocableByGrantor,
+    RevocableByDelegator,
     RevocableByArbiters {
         accounts: BoundedVec<T::AccountId, T::MaxRevokersPerPermission>,
         required_votes: u32,
@@ -141,7 +141,7 @@ pub enum RevocationTerms<T: Config> {
 }
 ```
 
-These terms create different security guarantees for the grantee, ranging from complete assurance (`Irrevocable`) to flexible arrangements (`RevocableByGrantor`). The `RevocableByArbiters` option allows for multi-signature revocation by designated third parties. The grantee can ALWAYS revoke a permission as it is the one being benefitted.
+These terms create different security guarantees for the recipient, ranging from complete assurance (`Irrevocable`) to flexible arrangements (`RevocableByDelegator`). The `RevocableByArbiters` option allows for multi-signature revocation by designated third parties. The recipient can ALWAYS revoke a permission as it is the one being benefitted.
 
 ## Enforcement Authority System
 
@@ -213,8 +213,8 @@ For example, a permission might require KYC verification before distributions ca
 
 Enforcement can be configured in two ways:
 
-1. During permission creation via the `grant_emission_permission` extrinsic
-2. After creation through the `set_enforcement_authority` extrinsic (only by the grantor or root)
+1. During permission creation via the `delegate_emission_permission` extrinsic
+2. After creation through the `set_enforcement_authority` extrinsic (only by the delegator or root)
 
 ```rust
 pub fn set_enforcement_authority(
@@ -233,12 +233,12 @@ The enforcement authority system transforms the permission framework from a simp
 
 The Permission0 pallet provides several extrinsics to manage the permission lifecycle:
 
-### grant_emission_permission
+### delegate_emission_permission
 
 ```rust
-pub fn grant_emission_permission(
+pub fn delegate_emission_permission(
     origin: OriginFor<T>,
-    grantee: T::AccountId,
+    recipient: T::AccountId,
     allocation: EmissionAllocation<T>,
     targets: Vec<(T::AccountId, u16)>,
     distribution: DistributionControl<T>,
@@ -248,24 +248,24 @@ pub fn grant_emission_permission(
 ) -> DispatchResult
 ```
 
-Creates a new emission permission from the signed origin to the specified grantee. The caller must be a registered agent, as must the grantee and all targets. Checks for valid allocation percentages, ensuring the total allocated percentage doesn't exceed 100% per stream.
+Creates a new emission permission from the signed origin to the specified recipient. The caller must be a registered agent, as must the recipient and all targets. Checks for valid allocation percentages, ensuring the total allocated percentage doesn't exceed 100% per stream.
 
-### grant_curator_permission
+### delegate_curator_permission
 
 ```rust
-pub fn grant_curator_permission(
+pub fn delegate_curator_permission(
     origin: OriginFor<T>,
-    grantee: T::AccountId,
+    recipient: T::AccountId,
     flags: u32,
     cooldown: Option<BlockNumberFor<T>>,
     duration: PermissionDuration<T>,
     revocation: RevocationTerms<T>,
 ) -> DispatchResult
 ```
 
-Creates a new curator permission, but can only be called with the Root origin. The `flags` parameter is a bitwise combination of curator permissions (APPLICATION_REVIEW, WHITELIST_MANAGE, PENALTY_CONTROL). The ROOT permission cannot be granted. 
+Creates a new curator permission, but can only be called with the Root origin. The `flags` parameter is a bitwise combination of curator permissions (APPLICATION_REVIEW, WHITELIST_MANAGE, PENALTY_CONTROL). The ROOT permission cannot be delegated.
 
-Only one curator permission can exist per grantee - attempting to create a second will result in a `DuplicatePermission` error. The optional `cooldown` parameter enforces a delay between successive uses of the permission.
+Only one curator permission can exist per recipient - attempting to create a second will result in a `DuplicatePermission` error. The optional `cooldown` parameter enforces a delay between successive uses of the permission.
 
 ### revoke_permission
 
@@ -277,8 +277,9 @@ pub fn revoke_permission(
 ```
 
 Revokes the specified permission if the caller meets the permission's revocation terms. This can be:
-- The grantee (always allowed)
-- The grantor (if RevocableByGrantor)
+
+- The recipient (always allowed)
+- The delegator (if RevocableByDelegator)
 - Root origin (always allowed)
 - Designated arbiters (with sufficient votes for RevocableByArbiters)
 - Anyone, after the specified block (for RevocableAfter)
@@ -294,7 +295,7 @@ pub fn execute_permission(
 ) -> DispatchResult
 ```
 
-Manually executes a permission with distribution control set to Manual. For emission permissions, this distributes accumulated tokens to the targets according to their weights. Can only be called by the grantor or root.
+Manually executes a permission with distribution control set to Manual. For emission permissions, this distributes accumulated tokens to the targets according to their weights. Can only be called by the delegator or root.
 
 ### toggle_permission_accumulation
 
@@ -306,7 +307,7 @@ pub fn toggle_permission_accumulation(
 ) -> DispatchResult
 ```
 
-Enables or disables accumulation for an emission permission. Can be called by the grantor, root, or enforcement controllers (with sufficient votes).
+Enables or disables accumulation for an emission permission. Can be called by the delegator, root, or enforcement controllers (with sufficient votes).
 
 ### enforcement_execute_permission
 
@@ -330,22 +331,22 @@ pub fn set_enforcement_authority(
 ) -> DispatchResult
 ```
 
-Sets or updates the enforcement authority for a permission. Can only be called by the grantor or root. The controllers and required_votes must form a valid multi-signature configuration (non-empty controllers, required_votes > 0, required_votes <= controllers.len()).
+Sets or updates the enforcement authority for a permission. Can only be called by the delegator or root. The controllers and required_votes must form a valid multi-signature configuration (non-empty controllers, required_votes > 0, required_votes <= controllers.len()).
 
 ## Permission Creation
 
 ```mermaid
 flowchart TD
-    A["Agent/Grantor"] -- grant_permission --> B["Create Permission"]
+    A["Agent/Delegator"] -- delegate_permission --> B["Create Permission"]
     B -- validate --> C["Check agent registration"] --> E["Check targets"] --> P{"Check Allocation Type"}
     P -- Fixed Amount --> K["Reserve Tokens"]
     P -- Streams --> D["Check stream percentages <= 100%"]
     B -- Generate ID --> F["Permission Contract"]
     F -- store --> G["Permissions Storage"]
     F -- index --> J["PermissionsByParticipants"]
-    F -- index --> I["PermissionsByGrantee"]
-    F -- index --> H["PermissionsByGrantor"]
-    B -- emit event --> M["PermissionGranted Event"]
+    F -- index --> I["PermissionsByRecipient"]
+    F -- index --> H["PermissionsByDelegator"]
+    B -- emit event --> M["Permissiondelegated Event"]
     D -- accumulate --> L["AccumulatedStreamAmounts"]
 ```
 
@@ -407,8 +408,8 @@ The Permission0 pallet uses several storage maps to track permissions and accumu
 ```rust
 pub type Permissions<T: Config> = StorageMap<_, Identity, PermissionId, PermissionContract<T>>;
 pub type PermissionsByParticipants<T: Config> = StorageMap<_, Identity, (T::AccountId, T::AccountId), BoundedVec<PermissionId, T::MaxTargetsPerPermission>>;
-pub type PermissionsByGrantor<T: Config> = StorageMap<_, Identity, T::AccountId, BoundedVec<PermissionId, T::MaxTargetsPerPermission>>;
-pub type PermissionsByGrantee<T: Config> = StorageMap<_, Identity, T::AccountId, BoundedVec<PermissionId, T::MaxTargetsPerPermission>>;
+pub type PermissionsByDelegator<T: Config> = StorageMap<_, Identity, T::AccountId, BoundedVec<PermissionId, T::MaxTargetsPerPermission>>;
+pub type PermissionsByRecipient<T: Config> = StorageMap<_, Identity, T::AccountId, BoundedVec<PermissionId, T::MaxTargetsPerPermission>>;
 pub type AccumulatedStreamAmounts<T: Config> = StorageNMap<
     _,
     (
@@ -423,7 +424,7 @@ pub type AccumulatedStreamAmounts<T: Config> = StorageNMap<
 This storage design allows efficient lookups for:
 
 - Finding all permissions between specific parties
-- Retrieving all permissions granted by an account
+- Retrieving all permissions delegated by an account
 - Retrieving all permissions received by an account
 - Tracking accumulated tokens for each permission by stream
 

docs/permission0.md

@@ -1,7 +1,7 @@
 [package]
 name = "torus-node"
 description = "Torus Substrate Node"
-version = "0.1.0"
+version = "0.2.0"
 license = "MIT-0"
 authors.workspace = true
 edition.workspace = true

node/Cargo.toml

@@ -40,7 +40,7 @@ pub mod pallet {
 
     /// Map of consensus members indexed by their keys. A consensus member is
     /// any agent eligible for emissions in the next epoch. This means
-    /// unregistered agents will also receive emissions.
+    /// deregistered agents will also receive emissions.
     #[pallet::storage]
     pub type ConsensusMembers<T: Config> =
         StorageMap<_, Identity, AccountIdOf<T>, ConsensusMember<T>>;

pallets/emission0/src/lib.rs

@@ -89,7 +89,7 @@ fn weights_are_filtered_and_normalized() {
         let mut member = ConsensusMember::<Test>::default();
         member.update_weights(BoundedVec::truncate_from(vec![
             (0, 0),  // self-weight is discarded
-            (1, 10), // unregistered agent still in members
+            (1, 10), // deregistered agent still in members
             (2, 20), // new agent not in members
             (3, 40), // unknown agent
         ]));
@@ -155,7 +155,7 @@ fn creates_list_of_all_member_inputs_for_rewards() {
         let validator = 0;
         let new = 1;
         let delegating_registered = 2;
-        let delegating_unregistered = 3;
+        let delegating_deregistered = 3;
         let delegating_unknown = 4;
         let miner = 5;
         let staker = 6;
@@ -166,7 +166,7 @@ fn creates_list_of_all_member_inputs_for_rewards() {
             register_empty_agent(id);
         }
 
-        for id in [miner, delegating_registered, delegating_unregistered] {
+        for id in [miner, delegating_registered, delegating_deregistered] {
             ConsensusMembers::<Test>::set(id, Some(Default::default()));
         }
 
@@ -179,7 +179,7 @@ fn creates_list_of_all_member_inputs_for_rewards() {
 
         for id in [
             delegating_registered,
-            delegating_unregistered,
+            delegating_deregistered,
             delegating_unknown,
         ] {
             WeightControlDelegation::<Test>::set(id, Some(validator));
@@ -231,9 +231,9 @@ fn creates_list_of_all_member_inputs_for_rewards() {
         );
 
         assert_eq!(
-            members[&delegating_unregistered],
+            members[&delegating_deregistered],
             ConsensusMemberInput {
-                agent_id: delegating_unregistered,
+                agent_id: delegating_deregistered,
                 validator_permit: false,
                 weights: vec![],
                 stakes: vec![],

pallets/emission0/tests/distribution.rs

@@ -30,7 +30,7 @@ fn curator<T: Config>() -> T::AccountId {
         T::AccountId,
         OriginFor<T>,
         BlockNumberFor<T>,
-    >>::grant_curator_permission(
+    >>::delegate_curator_permission(
         RawOrigin::Root.into(),
         curator_id.clone(),
         CuratorPermissions::all(),

pallets/governance/src/benchmarking.rs

@@ -440,7 +440,7 @@ pub mod pallet {
         ProposalExpired(ProposalId),
         /// A vote has been cast on a proposal.
         ProposalVoted(u64, T::AccountId, bool),
-        /// A vote has been unregistered from a proposal.
+        /// A vote has been deregistered from a proposal.
         ProposalVoteUnregistered(u64, T::AccountId),
         /// An agent account has been added to the whitelist.
         WhitelistAdded(T::AccountId),

pallets/governance/src/lib.rs

@@ -138,13 +138,13 @@ pub mod v5 {
             }
 
             for (curator, _) in old_storage::Curators::<T>::iter() {
-                let res = <<T as Config>::Permission0>::grant_curator_permission(
+                let res = <<T as Config>::Permission0>::delegate_curator_permission(
                     RawOrigin::Root.into(),
                     curator.clone(),
                     CuratorPermissions::all(),
                     None,
                     PermissionDuration::Indefinite,
-                    pallet_permission0_api::RevocationTerms::RevocableByGrantor,
+                    pallet_permission0_api::RevocationTerms::RevocableByDelegator,
                 );
 
                 match res {