Complete Delegate Capabilities

[sanity]

Overview

Delegates are documented as being able to perform several capabilities that are currently stubbed or missing entirely. This parent issue tracks the implementation of full delegate capabilities.

Current State

From delegate_interface.rs:366-373:

A Delegate is a webassembly code designed to act as an agent for the user on Freenet. Delegates can:

• Store private data on behalf of the user ✅ Implemented
• Create, read, and modify contracts ❌ Not implemented
• Create other delegates ❌ Not implemented
• Send and receive messages from other delegates and user interfaces ⚠️ Partial (UI only, not delegate-to-delegate)
• Ask the user questions and receive answers ❌ Stubbed (runtime auto-approves with Response::Allowed instead of routing to user)

Child Issues

Issue	Description	Dependencies
#2828	Contract GET from delegates	None
#2829	Contract PUT from delegates	None
#2830	Contract SUBSCRIBE from delegates	None
#2831	Contract UPDATE from delegates	None
#2832	Delegate-to-delegate messaging	None
#2833	Delegate creation by delegates	None (but see security discussion)
TBD	User input requests from delegates	Requires OS notification integration - do last

No hard dependencies between child issues - they can be implemented in parallel. However, implementing GET first may be useful for verification/testing of other operations.

Note: User input requests should be implemented last as they require integration with OS-specific notification systems (macOS, Windows, Linux each handle notifications differently).

Key Design Principles

1. Authorization is the Contract's Responsibility

Delegates should be able to interact with any contract. The contract is responsible for authorization (e.g., verifying signatures against a public key). The delegate may hold the private key needed to authorize operations, but that's up to the contract's implementation.

2. Sender Attestation is Critical

Every message received by a delegate must include where it came from:

• If from a contract: include ContractInstanceId
• If from another delegate: include DelegateKey
• If from a UI/application: appropriate identifier

This allows delegates to verify the source and understand the sender's capabilities/trust level. The existing attested field should be leveraged and potentially strengthened for this purpose.

3. Local Mode Must Support Full Functionality

freenet local is critical for testing. It should support all delegate functionality except actual network communication. This includes simulating contract notifications for subscriptions.

4. Security Against Malicious Delegates

Delegates run user-provided WASM code. We must protect against:

• Fork bombs (delegate creates infinite child delegates)
• Resource exhaustion
• Unauthorized access attempts

Resource limiting similar to the contract system may be needed for delegates.

Naming Considerations

The term "ApplicationMessage" is outdated (originally referred to UI applications). Since we're still in alpha, now is the time to reconsider naming:

• ApplicationMessage → DelegateMessage? PeerMessage?
• The app field targeting ContractInstanceId needs to also support DelegateKey

Testing Strategy

Each child issue should include:

1. Unit tests for the new message types
2. Integration tests using freenet local
3. Example delegate demonstrating the capability

Related Code

• API definition: freenet-stdlib/rust/src/delegate_interface.rs
• Runtime: freenet-core/crates/core/src/wasm_runtime/delegate.rs (see get_outbound() for the stubbed user input handling)
• Executor: freenet-core/crates/core/src/contract/executor/runtime.rs
• Example delegate: freenet-core/tests/test-delegate-1/

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-tracking (98% confidence)
• E-hard (85% confidence)
• A-contracts (95% confidence)
• A-developer-xp (88% confidence)
• S-needs-design (86% confidence)

Reasoning: This is a parent/meta issue that tracks implementation of multiple related delegate capabilities (so T-tracking). The work is architecturally complex across the contract/wasm runtime, security and testing, so E-hard. Primary area is contract runtime and delegate integration (A-contracts); it also touches developer workflow and testing (freenet local, example delegates) so A-developer-xp, and includes naming/docs/testing requirements so A-documentation. The issue outlines design principles and security considerations, indicating further architectural design discussion is needed (S-needs-design). Confidence scores reflect the clarity of the issue and scope.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.