Fix typo

Author: mycognosist

_posts/2025-07-28-access-control.md

@@ -66,7 +66,7 @@ The aforementioned group actions are published as group control operations; each
 
 Membership state for a group is maintained locally using a Causal-Length CRDT based on grow-only sets which allow for efficiently merging states across graph branches. However, it's simplicity does not allow us to fully handle conflicting group states emerging from some concurrent scenarios. In such cases, all operations in the DAG are walked in a depth-first search so that any "bubbles" of concurrent operations may be identified. Resolution rules are then applied to the operations in these bubbles in order to populate a filter of operations to be invalidated. Once the offending operations have been invalidated, any dependent operations are then invalidated in turn.
 
-We have defined the `Resolver` as a Rust trait to allow for multiple implementations with contrasting rulesets for identifying which concurrent operations are to be considered invalid. This approache arises from the understanding that applications have different requirements around trust and security; some may operate in high-stakes contexts where the most cautious implementation is always preferred, while others may operate in low-stakes contexts without the need for strict conflict resolution. The initial offering of our `p2panda-auth` crate offers a single resolver implementation which we refer to as a "strong removal" resolver. The ruleset is as follows:
+We have defined the `Resolver` as a Rust trait to allow for multiple implementations with contrasting rulesets for identifying which concurrent operations are to be considered invalid. This approach arises from the understanding that applications have different requirements around trust and security; some may operate in high-stakes contexts where the most cautious implementation is always preferred, while others may operate in low-stakes contexts without the need for strict conflict resolution. The initial offering of our `p2panda-auth` crate offers a single resolver implementation which we refer to as a "strong removal" resolver. The ruleset is as follows:
 
 1) Removal or demotion of a manager causes any concurrent actions by that member to be invalidated
 2) Mutual removals, where two managers remove or demote one another concurrently, are not invalidated; both removals are applied to the group state but any other concurrent actions by those members are invalidated