Good idea, well documented and written code. While I was reading the code, I discovered these questions/issues:

1. use PhoenixLiveState, :client is essentially a noop. It raises no error, but it also exports no hooks or anything. Why?
2. If I understood the code correctly, this solution appears to be none from CAP. It’s not consistent or partition tolerant because state server is started under the global name, and when split happens and some new live view mounts in the partition without state server, it will spawn a second server with the same name, which will result in two servers having different state. When split is resolved, one server will be just killed, since server does not implement any callbacks for state handover. It is also not available, because when cluster splits, the views which are in different partition then the state server, will just crash during the GenServer.call to the state server.
3. When two views do the same action (consider the messages list from the README example), their order will be indefinite and it’s even worse, cause the action which will hit the state server first will be just overwritten by the second one.
4. Why add ACL to this solution?
5. It seems that state server spawning is unbalanced, in a sense that the state server always spawns on the node where the first live view with this key mounts

But I like the idea and most of the interface, so I have these suggestions about how to improve the solution:

1. Decide on CAP. There are AP and CP solutions which I can suggest. First is AP, investigate Delta CRDT algorithms, Merkle Map versions, You can use library Horde (or is it Swarm) which utilizes this algorithm as a reference. If you want to have CP solution, I would suggest to not use the global and implement some persistent hashring to decide on the node where the state server spawns (no matter where the liveview was first mounted).

2. I don’t see the use case for ACL, but even if there is one, it’s not that hard to implement it on top of the key-valye sync. Doing it inside the library just blurs the scope and, personally for me, looks odd.

3. Make most logs debug or at least add some metadata so that users of the library could filter these messages out

4. I believe that every distributed algorithm must have a good doc with implementation details and choice it makes in order for users to understand the possible drawbacks and failure scenarios.