📡 Authority

Runtime, netcode-agnostic authority hooks that determine who may mutate an inventory. Used internally by SceneInventoryService to gate all write operations (add / remove / swap / split / move / transfer / resize / sort).

⚠️ Not a multiplayer framework.
These files provide authority interfaces and resolvers only — you implement replication, prediction, reconciliation, and rollback in your chosen netcode.

✅ Works in single-player and multiplayer
✅ No dependency on any specific netcode SDK
✅ Integrates via one tiny interface: IInventoryAuthority

---

Purpose

All service-level mutation methods in the inventory system call an internal RequireAuthority(owner) gate before executing.

If no IInventoryAuthority implementation is found, service-level mutations default to allowed. This is an intentional, single-player-friendly design choice.

This folder defines: - The IInventoryAuthority interface you implement to express your policy - The static InventoryAuthority resolver and cache - A default InventoryAuthorityBinder for single-player / local testing

---

Components & API

IInventoryAuthority

Minimal policy interface:

public interface IInventoryAuthority
{
    bool HasAuthority(UnityEngine.GameObject owner);
}

Implement this on any component that can answer:

“May this caller mutate the given owner’s inventory?”

For best performance, attach it to the same GameObject as the inventory owner.

---

InventoryAuthority (static resolver)

Scene-scoped resolver and cache.

Resolution order 1. Cached binder (validated active/enabled) 2. Local component on the same GameObject 3. Parent transforms 4. Scene root objects (prefers active/enabled) 5. Global scene scan (fallback)

Key methods

IInventoryAuthority Resolve(MonoBehaviour ctx);
IInventoryAuthority Resolve(Component c);
IInventoryAuthority Resolve(GameObject go);
void Invalidate(); // clears cached binder

• Cache resets automatically on domain reload (SubsystemRegistration).
• If you spawn or destroy binders at runtime, call InventoryAuthority.Invalidate().

Only one resolved binder is used at runtime — the first valid match wins.

---

InventoryAuthorityBinder (local / single-player)

Built-in permissive binder:

[AddComponentMenu("RevFramework/Inventory/Inventory Authority Binder")]
[DefaultExecutionOrder(-500)]
public class InventoryAuthorityBinder : MonoBehaviour, IInventoryAuthority
{
    public bool alwaysTrue = true;

    public bool HasAuthority(GameObject owner)
    {
        if (!owner) return false;
        return alwaysTrue;
    }
}

• Attach to your inventory owner for single-player or local testing
• Multiplayer projects should replace this with a network-aware binder

---

How Inventory Uses Authority

• Every write path in SceneInventoryService (GiveExact, RemoveByGuid, SplitResult, Move, ResizeContainer, etc.) calls RequireAuthority(owner) before mutating state

• That gate:

• Resolves an IInventoryAuthority

• Calls HasAuthority(owner)

• If denied, the operation fails with:

InvOpResult.Fail(
    InvOpCode.NoAuthority,
    "No authority to mutate this inventory."
);

Reads (Get, Search, CountOf, etc.) are always allowed and never gated.

---

Quick Start

Single-player

1. Add SceneInventoryService and assign an ItemDatabase
2. Add InventoryAuthorityBinder to your player object
3. Leave alwaysTrue = ON

Multiplayer

1. Implement an IInventoryAuthority binder that reflects your ownership rules
2. Forward client requests to the authoritative instance (server / host)
3. Call inventory service mutations there
4. Replicate resulting state via your netcode

---

FAQs

Question	Answer
Where should the binder live?	On the same GameObject as the inventory owner. Parents and scene/global scans are slower fallbacks.
Do I need to call Invalidate()?	Only if binders are added or removed dynamically at runtime.
Does this replicate inventory automatically?	No. Authority only gates changes. Replication is your responsibility.
Can I have multiple binders?	Only one is used — the first valid resolver match wins. Consolidate logic in one component.
Do reads require authority?	No. Reads are always allowed.

---

Troubleshooting

• NoAuthority → binder missing or returned false
• ServiceMissing → no SceneInventoryService in the scene
• Clients not seeing changes → replicate inventory state via your netcode

---

See Also

• Services → SceneInventoryService authority gates
• Abstractions → InvOpResult / InvOpCode result contracts

---

Support Stance

These files are illustrative, not a full multiplayer solution.

• Single-player: use the local binder or rely on default-allow behaviour
• Multiplayer: implement a network-aware binder and replicate state yourself

RevFramework does not ship replication, prediction, rollback, or reconciliation logic.