OctoMY™'s trust system controls what nodes can do with each other using a capability-based model.
Rather than a single trust level, OctoMY™ uses specific capability tokens that define exactly what a node can do:
Design Decision: Capability-based vs role-based trust
OctoMY™ uses capability tokens instead of hierarchical trust levels (like "full trust", "partial trust", "no trust"). This provides fine-grained control while remaining simple for users.
Alternatives considered: Role-based hierarchy, numeric trust scores, time-limited trust Tradeoff: Slightly more complex implementation Benefit: Precise control, easy to understand, node-type awareness, instant revocation
| Level | Description |
|---|---|
| Trust | Normal operational relationship with appropriate capabilities |
| Ignore | Node exists but no capabilities granted (default for new nodes) |
| Block | Complete communication blackout |
| Remove | Permanently delete node from address book |
The TrustList manages specific capabilities:
| Token | Description | Applied When |
|---|---|---|
give-control |
Node can accept control commands | Agent/Hub at Trust level |
take-control |
Node can send control commands | Remote/Hub at Trust level |
block |
All communication blocked | Block level |
When you set trust to Trust level, different capabilities are granted based on node type:
| Node Type | Capabilities Granted |
|---|---|
| Agent | give-control (accepts commands) |
| Remote | take-control (sends commands) |
| Hub | give-control + take-control (both) |
This means:
Purpose: Normal operational relationship.
Behavior:
Use cases:
Purpose: Acknowledge existence but don't engage.
Behavior:
Use cases:
Pro Tip
Use Ignore level when you're not sure about a node yet. It lets you monitor the node and inspect its identity before granting Trust. This is safer than immediately blocking unknown nodes, which might be legitimate devices you haven't configured yet.
Purpose: Complete isolation from a node.
Behavior:
Use cases:
Security Consideration
Once a node is blocked, it cannot communicate with you at all - even discovery packets are ignored. Use this level for known malicious nodes. For unknown nodes, use Ignore instead to maintain visibility.
Purpose: Permanently delete a node.
Behavior:
Use cases:
| Capability | Block | Ignore | Trust |
|---|---|---|---|
| Discovery | ✗ | ✓ | ✓ |
| Session | ✗ | ✗ | ✓ |
| Commands | ✗ | ✗ | ✓ (with capability) |
Trust is not automatically reciprocal:
Agent trusts Remote at Trust level
Remote trusts Agent at Ignore level
Result:
- Remote can discover Agent
- Remote CANNOT send commands to Agent (no take-control capability)
- Agent has give-control but Remote has no capability to use it
The effective trust for any interaction depends on both sides having appropriate capabilities.
Did You Know?
Asymmetric trust is intentional, not a bug. It allows scenarios like "I want to see you, but I don't want to accept commands from you yet." This is common during initial pairing when you're still evaluating a new node.
Each relationship is independent:
Agent's trust settings:
Remote-A: Trust (give-control)
Remote-B: Ignore (no capabilities)
Remote-C: Block (blocked)
Hub-1: Trust (give-control)
Trust can be changed at any time:
Newly discovered nodes start at Ignore level. Users must explicitly grant Trust to enable operational capabilities.
Security Consideration
OctoMY™ never grants trust automatically. Even if a node successfully completes cryptographic authentication during pairing, you must explicitly set the trust level. This ensures human oversight for all trust decisions.
The trust system is implemented in:
TrustLevel - Enum: IGNORE, TRUST, BLOCK, REMOVETrustList - Capability token management