Enhance NIP-XX Document with Event Kind Replication and Identity Tag Features

- Added new `K` and `I` tags to support event kind replication and identity verification in trust attestations.
- Expanded trust level definitions to include replication of custom event kinds specified in the `K` tag.
- Introduced detailed specifications for the `I` tag, including identity proof-of-control signature requirements and usage guidelines.
- Updated event synchronization and conflict resolution processes to incorporate identity verification and key delegation management.
- Enhanced security considerations to address identity tag verification and delegation limits, ensuring robust trust management among relays.

docs/NIP-XX-distributed-directory-consensus.md

@@ -135,7 +135,9 @@ Relay operators create trust attestations toward other relays they wish to enter
     ["trust_level", "high|medium|low"],
     ["relay", "<target-relay-url>"],
     ["expiry", "<unix-timestamp>"],
-    ["reason", "manual|automatic|inherited"]
+    ["reason", "manual|automatic|inherited"],
+    ["K", "1,3,6,7,1984,30023"],
+    ["I", "<npub-identity>", "<hex-nonce>", "<hex-signature>"]
   ]
 }
 ```
@@ -146,11 +148,20 @@ Relay operators create trust attestations toward other relays they wish to enter
 - `relay`: WebSocket URL of the target relay
 - `expiry`: Optional expiration timestamp for the attestation
 - `reason`: How this trust relationship was established
+- `K`: Comma-separated list of event kinds to replicate in near real-time (in addition to directory events)
+- `I`: Identity tag with npub, nonce, and proof-of-control signature (same format as Kind 39103)
 
 **Trust Levels:**
-- `high`: Full replication of all directory events
+- `high`: Full replication of all directory events plus all kinds specified in `K` tag
-- `medium`: Selective replication based on additional criteria
+- `medium`: Selective replication of directory events plus kinds specified in `K` tag based on additional criteria
-- `low`: Minimal replication, primarily for discovery
+- `low`: Minimal replication of directory events only, `K` tag kinds may be filtered
+
+**Event Kind Replication:**
+- **Directory Events**: Always replicated regardless of `K` tag (kinds 0, 3, 5, 1984, 10002, 10000, 10050)
+- **Custom Kinds**: Additional event kinds specified in the `K` tag are replicated based on trust level
+- **Specialization**: Enables relay operators to specialize in specific data types (e.g., long-form content, marketplace events, etc.)
+- **Near Real-time**: Events matching `K` tag kinds are replicated with minimal delay
+- **Bidirectional**: Replication occurs both to and from the trusted relay for specified kinds
 
 ### Group Tag Attestation (Kind 39102)
 
@@ -177,7 +188,7 @@ Relays can attest to arbitrary string values used as tags to create logical grou
 
 ### Public Key Advertisement (Kind 39103)
 
-Relays advertise public keys that will be used in future operations:
+Relays advertise public keys that will be used in future operations. Each relay MUST limit the number of unused key delegations to 512 per identity. Key delegations expire after 30 days if not used in any database operations:
 
 ```json
 {
@@ -189,7 +200,8 @@ Relays advertise public keys that will be used in future operations:
     ["purpose", "signing|encryption|identity"],
     ["valid_from", "<unix-timestamp>"],
     ["valid_until", "<unix-timestamp>"],
-    ["algorithm", "secp256k1|x25519"]
+    ["algorithm", "secp256k1|x25519"],
+    ["I", "<npub-identity>", "<hex-nonce>", "<hex-signature>"]
   ]
 }
 ```
@@ -201,6 +213,60 @@ Relays advertise public keys that will be used in future operations:
 - `valid_from`: When this key becomes valid
 - `valid_until`: When this key expires
 - `algorithm`: Cryptographic algorithm used
+- `I`: Identity tag containing npub, nonce, and proof-of-control signature
+
+**Key Delegation Limits:**
+- Maximum 512 unused key delegations per relay identity
+- Key delegations expire after 30 days without database usage
+- Expired delegations MUST be deleted to prevent unbounded growth
+- Usage is defined as the key being referenced in any stored directory event
+
+**Identity Tag (`I`) Specification:**
+The `I` tag provides an npub-encoded identity with proof of control that binds the identity to the delegate pubkey:
+
+1. **npub-identity**: The identity public key encoded in npub format (NIP-19)
+2. **hex-nonce**: A random nonce (recommended 16+ bytes) encoded as hex
+3. **hex-signature**: Signature proving the identity holder authorized the delegate pubkey
+
+**Identity Tag Signature Generation:**
+1. Extract the delegate pubkey from the event's `pubkey` field
+2. Decode the npub to get the identity pubkey as hex
+3. Concatenate: `nonce + delegate_pubkey_hex + identity_pubkey_hex`
+4. Compute SHA256 hash of the concatenated string
+5. Sign the hash using the private key corresponding to the npub identity
+6. Encode the signature as hex
+
+**Identity Tag Verification:**
+1. Decode the npub to extract the identity public key
+2. Extract the delegate pubkey from the event's `pubkey` field
+3. Concatenate: `nonce + delegate_pubkey_hex + identity_pubkey_hex`
+4. Compute SHA256 hash of the concatenated string
+5. Verify the signature using the identity public key and computed hash
+6. Reject the event if verification fails
+
+This binding ensures that:
+- The identity holder explicitly authorized this specific delegate key
+- The delegate key cannot be used with a different identity
+- The signature proves both identity control and delegation authorization
+
+### Identity Tag Usage
+
+The `I` tag serves multiple purposes in the consortium protocol:
+
+**Identity Lookup:**
+- Clients can search for events using npub identities instead of raw pubkeys
+- Provides a more user-friendly way to reference identities
+- Enables identity-based filtering and discovery
+
+**Spam Prevention:**
+- The proof-of-control signature prevents unauthorized use of identities
+- Only the holder of the private key can create valid `I` tags
+- Reduces spam by requiring cryptographic proof for each identity reference
+
+**Consortium Benefits:**
+- Relays can index events by npub identity for efficient lookup
+- Enables cross-relay identity resolution within the consortium
+- Supports identity-based replication policies
 
 ### Directory Event Types
 
@@ -225,23 +291,54 @@ The following existing event kinds are considered "directory events" and subject
 
 #### 2. Directory Event Synchronization
 
-When a relay receives a directory event from a user, it:
+When a relay receives an event from a user, it:
 
 1. Validates the event signature and content
-2. Stores the event locally
+2. If the event contains an `I` tag, verifies the identity proof-of-control signature
-3. Identifies trusted consortium members based on current trust attestations
+3. Stores the event locally
-4. Replicates the event to trusted relays using Directory Event Replication Requests (Kind 39104)
+4. Updates key delegation usage tracking (if applicable)
+5. Identifies trusted consortium members based on current trust attestations
+6. Determines replication targets based on event kind:
+   - **Directory Events**: Replicate to all trusted consortium members
+   - **Custom Kinds**: Replicate only to relays that have specified this kind in their `K` tag
+7. Replicates the event to appropriate trusted relays using Directory Event Replication Requests (Kind 39104)
 
-#### 3. Conflict Resolution
+**Event Kind Matching:**
+- Check each trust attestation's `K` tag for the event's kind number
+- Only replicate to relays that have explicitly included the kind in their attestation
+- Directory events are always replicated regardless of `K` tag contents
+- Respect trust level when determining replication scope and frequency
+
+#### 3. Key Delegation Management
+
+Each relay in the consortium MUST implement key delegation limits and expiration:
+
+**Delegation Limits:**
+- Maximum 512 unused key delegations per relay identity
+- When limit is reached, oldest unused delegations are removed first
+- Delegations become "used" when referenced in any stored directory event
+
+**Expiration Policy:**
+- Key delegations expire after 30 days without usage
+- Expired delegations MUST be deleted during periodic cleanup
+- Usage timestamp is updated whenever a delegation is referenced
+
+**Cleanup Process:**
+- Run cleanup at least daily to remove expired delegations
+- Log delegation removals for audit purposes
+- Notify consortium members of delegation changes if configured
+
+#### 4. Conflict Resolution
 
 When conflicting directory events are received (same pubkey, same kind, different content):
 
 1. **Timestamp Priority**: Newer events replace older ones
 2. **Signature Chain Validation**: Verify the complete signature chain
-3. **Consensus Voting**: For disputed events, trusted relays vote on validity
+3. **Identity Verification**: Validate `I` tag signatures if present
-4. **Byzantine Fault Tolerance**: System remains functional with up to 1/3 malicious nodes
+4. **Consensus Voting**: For disputed events, trusted relays vote on validity
+5. **Byzantine Fault Tolerance**: System remains functional with up to 1/3 malicious nodes
 
-#### 4. Trust Propagation
+#### 5. Trust Propagation
 
 Trust relationships can be inherited through the web of trust:
 
@@ -269,13 +366,29 @@ Relay A                    Relay B                    Relay C
 ### Security Considerations
 
 1. **Identity Verification**: Relay identity keys MUST be verified through the extended NIP-11 relay information document. The relay MUST prove control of the private key through the `nonce` and `sig` fields, and the same keypair MUST be used to sign consortium events, creating a cryptographic binding between network address and relay identity.
+
 2. **Trust Boundaries**: Operators should carefully configure trust levels and inheritance policies
+
 3. **Rate Limiting**: Implement rate limiting to prevent spam and DoS attacks
-4. **Signature Validation**: All events and attestations MUST be cryptographically verified
+
+4. **Signature Validation**: All events and attestations MUST be cryptographically verified, including `I` tag proof-of-control signatures
+
 5. **Privacy**: Sensitive consortium communications SHOULD use ECDH encryption
+
 6. **Address Binding**: The extended NIP-11 document serves as the authoritative source for relay identity verification. Relays MUST NOT accept consortium events from identities that cannot be verified through their NIP-11 document's signature mechanism. The `nonce` field SHOULD be regenerated periodically to maintain security.
+
 7. **Key Rotation**: If a relay rotates its identity key, it MUST update both its NIP-11 document and republish its Relay Identity Announcement to maintain consortium membership.
 
+8. **Delegation Limits**: The 512 unused key delegation limit prevents resource exhaustion attacks. Relays MUST enforce this limit strictly and implement proper cleanup mechanisms.
+
+9. **Identity Tag Security**: `I` tag signatures MUST be verified before accepting events. Invalid signatures MUST result in event rejection to prevent identity spoofing. The signature binds the identity to the specific delegate pubkey, preventing key reuse across different identities.
+
+10. **Expiration Enforcement**: The 30-day expiration policy for unused delegations MUST be enforced to prevent unbounded storage growth and maintain system performance.
+
+11. **Nonce Uniqueness**: Nonces in `I` tags SHOULD be unique per event to prevent replay attacks, though this is not strictly required due to the event-specific context.
+
+12. **Delegate Authorization**: The `I` tag signature cryptographically proves that the identity holder explicitly authorized the delegate key for this specific use. This prevents unauthorized delegation and ensures accountability for delegated actions.
+
 ### Implementation Guidelines
 
 #### Relay Operators
@@ -285,6 +398,11 @@ Relay A                    Relay B                    Relay C
 3. Implement Byzantine fault tolerance mechanisms
 4. Monitor consortium health and trust relationships
 5. Provide configuration options for users to opt-out of replication
+6. Implement key delegation tracking and cleanup mechanisms
+7. Enforce the 512 unused delegation limit per identity
+8. Run daily cleanup processes to remove expired delegations
+9. Validate `I` tag signatures on all incoming events
+10. Maintain usage statistics for delegation management
 
 #### Client Developers
 
@@ -292,6 +410,10 @@ Relay A                    Relay B                    Relay C
 2. Clients SHOULD respect user preferences for directory event replication
 3. Clients MAY use consortium information for relay discovery
 4. Clients SHOULD validate directory events from multiple sources
+5. Clients MAY generate `I` tags with proof-of-control for identity references
+6. Clients SHOULD validate `I` tag signatures when processing events
+7. Clients MAY use npub identities from `I` tags for user-friendly display
+8. Clients SHOULD implement proper nonce generation for `I` tag security
 
 ### Backwards Compatibility
 
@@ -311,6 +433,14 @@ This design draws inspiration from the democratic Byzantine Fault Tolerant appro
 3. **Automatic Synchronization**: Reduces user burden while maintaining decentralization
 4. **Byzantine Fault Tolerance**: Ensures system reliability even with malicious participants
 5. **Optional Participation**: Maintains Nostr's principle of optional protocol extensions
+6. **Event Kind Specialization**: The `K` tag enables relay specialization for specific data types
+
+**Specialization Examples:**
+- **Content Relays**: Specialize in long-form content (kind 30023), articles, and media
+- **Social Relays**: Focus on social interactions (kinds 1, 6, 7) and reactions
+- **Marketplace Relays**: Handle commerce events (kinds 30017, 30018) and transactions
+- **Developer Relays**: Sync code-related events (kinds 1617, 1618, 1621) and repositories
+- **Community Relays**: Manage community events (kinds 34550, 9000-9030) and moderation
 
 ## Reference Implementation