what kinds of human problems become solvable when society becomes synchronised, and what new problems emerge precisely because it is synchronised?
I think it’s easy to see once you understand that we are entering Synchronized States whether we like it or not. Society Protocol just happens to be the implementation that fully empowers the individuals using it.
The closed, top-down path is CBDCs. Permissioned accounts. Central bank controls the Parameters. No Portal. No fork. No modular governance. One instance per jurisdiction, controlled from the top. It gives you synchronization without plurality. That is techno-feudalism with better accounting.
The open path is Society Protocol. Source-available codebase. Modular Parameters, modular Governance, modular Value Functions. Portal for exit. Permissionless instance creation. Any community can spin up an instance. Any community can fork. The Parameters are the “physics” of each instance, and they’re configurable. That’s the whole point.
So the choice isn’t between “synchronized” and “not synchronized.” Both paths synchronize. The choice is between one synchronized state controlled from the top, and many synchronized states, each forkable, each exit-able. Our handbook is the specification for the second.
1 Like
so the real question is not whether society synchronises…
but who controls that synchronised state, how its rules can change, and whether people can genuinely exit or fork…
1 Like
Do you about the Portal function? That’s our Exit. All SP instances will have that function by default. That’s part of they key functions that should remain always with SP instances. If someone forks the code and remove that functions… you should’t join that instance.