Turret access control via pre-computed dynamic fields + watcher service

[martinjms]

Summary

Turret extensions cannot receive custom objects (binding, condition proofs) from the game server at targeting time. This blocks real-time condition evaluation.

Proposed solution

Pre-compute access decisions and store them as dynamic fields on the binding or turret config. A watcher service keeps them up to date.

Architecture

1. Watcher service monitors players in the same solar system as the turret
2. Evaluates conditions for each player (tribe, character, attestation, etc.)
3. Writes results to dynamic fields: dynamic_field::add(binding, player_address, AccessResult)
4. Turret extension reads dynamic_field::borrow(binding, player_address) at targeting time — no proofs needed

Tradeoffs vs real-time conditions

• Rules: 1 gas payment, infinite players. Dynamic fields: 1 gas payment per player, ongoing updates
• Latency: 5-10 seconds for new players entering range
• Only justified because turrets can't receive custom objects at call time

Prerequisites

• Determine if datahub API or chain events expose player locations or system presence
• Pre-compute at system level (all players in solar system) rather than proximity

Relationship to other approaches

• Attestation server could double as the watcher
• Same pattern could support ZK proofs in the future (write proof result, not raw data)
• Does NOT replace the condition module system — conditions remain primary for gates/SSUs

🤖 Generated with Claude Code