Versioned Nakama storage
Protects player data from conflicting updates and incorrect access. It defines ownership and version checks, separating trusted inventory or rewards from preferences the player may edit directly.
nakama-storage-versions
See how it helpsWhen is it useful?
Use it when inventory, preferences or persistent objects need different client permissions and conflict handling.
What does it help you do?
- Defines collection, key, owner and read/write rights.
- Uses version preconditions to reject conflicting inventory updates.
- Separates trusted rewards from client-editable preferences.
Try asking this
Two devices try to consume the last healing potion at once. Use the stored inventory version to detect the conflict, reread before any authorized retry and keep the item count valid. A separate settings update must not gain permission to change coins or inventory.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Nakama — storage versions
Use when implementing Nakama player data, inventory, save storage or concurrent writes.
Version and project gate
Inspect Nakama server and client SDK versions, chosen Go/TypeScript/Lua runtime, compiled module deployment, database topology, match handlers, RPC registrations, auth/session handling, storage collections and permission rules. Never turn a task into an engine upgrade without the user’s intent. Read the version-matching official reference when an API decision depends on it.
Work
Declare collection/key/owner and read/write permissions for every object. Use version preconditions or the documented atomic operations to protect concurrent changes. Validate server-side mutations and define schema migration and missing-object behavior. Keep trusted rewards separate from client-editable preferences.
Deliver
A storage/permission table and a race-aware mutation contract. Keep the change in the existing project structure; separate actual observations from the proposed acceptance scenario below.
Failure to prevent
Owner-write permission permits the owner’s client to edit the object; it is unsuitable for trusted rewards without server validation.
Acceptance scenario
Race two inventory updates, use a stale version and attempt a cross-user read/write with each permission combination. Follow the project’s execution and verification permissions. If execution or a target device is unavailable, provide the reproduction steps and name the remaining uncertainty; do not mark it passed.
Scope and sources
This skill belongs to Kairo. Agent selection is restricted by Orqestria’s assigned-agent policy, including forced skill selection; instruction text alone is not an access control. These are original task workflows researched from official documentation, not a copied or endorsed vendor skill.
Included files 1
SKILL.md