Problem: we don't have a good way to focus the action of multiple humans while remaining sovereign
When Bitcoiners organise around shared goals, they tend to rely on the State to anchor their organisational structures and serve as the mediator of last resort between all stakeholders. Coinkite and OpenSats, for example.
All human organisational structures are fundamentally composed of human action (and **inter** action) because human action is the **only** primitive by which humanity can influence how the present reality is brought forth from the infinite potential of the future.
Families, tribes, companies, governments, civilisations, etc are all examples of organisational structures composed of human action.
#### Composing human action through boundary conditions
The usefulness of a bucket is created by the limitations or restrictions imposed by its base and sides. A bucket is useful because it holds water by creating **boundary conditions** on what the water **cannot** do while **remaining in the bucket**.
Human organisational structures are useful because what they do with humans is analogous to what a bucket does with water. These structures are defined by their boundary conditions on human action - what type of action humans can take while remaining within the organisational structure.
**Centrally planned** organisations like companies or governments tend to create boundary conditions on human action through a combination of:
* internal rules about what types of human action is permissible,
* internal rulers with the power to decide when to change the rules, and when to break them, and
* excluding people who don't submit to the rules and rulers ("don't fit the culture" or aren't a "team player").
Human action within organisations is also restricted by the underlying security model. Investors tend to rely on the State to enforce contracts, and so any organisation that wants to raise money tends to be nested under the State. All humans within such an organisation are therefor ultimately responsible to the State for their actions. For example, the CFO is responsible to the State for all financial activity performed within the organisation, and all humans within the organisation are responsible to the CFO when their action involves money. The same is true for all aspects of the organisation. It's therefor impossible for an organisation to be nested under the State without being centrally planned.
Centrally planned organisations exist along a spectrum of just how centrally planned they are - from highly planned military organisations to the **Teal** organisations as described by Frederic Laloux (well worth skimming through his book).
So-called **Decentralised organisations** tend to restrict human action by:
* deciding ahead of time on all the possible types of human action that shall be permissible within the organisation, and
* encoding the rules about these actions into some form of state machine (usually a "smart" "contract").
These organisations are typically inflexible due to this architecture. Modifying the set of human action that is permissible within the organisation requires smart contracts to be republished, which is where the community generally falls back to trusting a central team.
#### Mutexless organisations
The more you need upfront consensus or agreement on what to do, the [less speedup you get](https://en.wikipedia.org/wiki/Amdahl%27s_law) by adding additional "workers".
The more sequential operations or mutexes you have, the less speedup you get by adding additional threads or workers because all of those threads need to pause execution and wait for the sequential parts of the process. It's a non-linear relationship: a tiny increase in wait-states drastically reduces the speedup gained when adding more threads. At some point, adding more threads does not result in any speedup.
In human organizations, we have the same thing. Individuals within the organization are workers or threads. Human organizations have a ratio of sequential to parallel operations, just like computer programs. The more a team needs to stop and synchronize, the less work they get done and the smaller the maximum team size, after which adding more people does not result in any additional productivity.
Requiring permission or agreement over what to do within an organisation is a sequential operation. Meetings are the mutexes of human organisations.
Thus, the most efficient organisational structure is one where participants can do productive work without requiring any permission or agreement with others over what work to do.
#### Sovereign organisations
Sovereign human action is human action taken by a **sovereign individual**.
Sovereign human action does not **require** permission from others. It does not **require** upfront consensus or agreement. The sovereign individual MAY seek agreement or permission before taking some action, but this is not **required**, it's entirely their own decision.
A sovereign organisation is one where individuals may participate while remaining sovereign. A better term for this is a sovereign unorganisation.
The organisational structure of a sovereign unorganisation MUST be composed of sovereign human action.
A sovereign civilisation is probably some form of meta sovereign unorganisation composed not only of sovereign human action but also many sovereign unorganisations, and inhabited by sovereign individuals.
#### How do we focus sovereign human action?
If an organisation is sovereign, it's also mutexless because participants can do productive work without requiring any permission or agreement with others over what work to do.
The implication is that participants within such an organisation can do work without anyone knowing what they are working on, because work can be done without any upfront agreement on what is being built.
How do we create an organisational structure which allows individuals to remain sovereign and work towards building something without requiring any agreement on what we are building?
What are the boundary conditions on sovereign human action that create the conditions for such an organisational paradigm?
The metric we use to judge if Nostrocket has optimal boundary conditions on human action within it is the community size - are humans being attracted to it faster than any alternative?
* Humans with something to contribute must be better off by acting **within** the structure of Nostrocket than they are by acting within any other structure.
* Nostrocket must result in more value for Participants than any other opportunity available to them.
* Nostrocket must become, and actively remain, the most efficient organisational paradigm possible with the current technology
* The mechanism by which work gets done within Nostrocket cannot require upfront agreement on what that work should involve or what the end result should look like
* Nostrocket cannot require any upfront funding and cannot retain any capital
* To remove any internal friction, Nostrocket must be radically fair to all Participants, more fair than any other organisational structure
* Nostrocket's rules and ideology must be as pristine and *credibly neutral* as possible
* It's not possible to be as pristine and neutral as Bitcoin because Nostrocket is an organisational structure while Bitcoin is property, but Bitcoin is the standard to judge against.
* The boundary conditions or limitations should be simple, explicit, clear, and graduated such that there's no overhead required to onboard new Participants, and Participants may advance at their own speed along their own zone of proximal development.
---
### Possible Solution: an unprotocol for a universally applicable hill-climbing algorithm, executed by sovereign human action.
The core of the solution is a hill-climbing algorithm which optimises for increasing the number of Participants.
Software can be used to make things more efficient and to provide continuity of the current state of Nostrocket, but the algorithm itself is executed by self-interested sovereign human action and not machine.
Human action within Nostrocket must be executed for purely self-interested reasons in order for it to be optimally efficient, accurate, scalable, and to minimise any social attack surface. When people solve problems for their own reasons, the solutions are more accurate than when they are doing it because someone is coercing them with money. A case in point: organic contributions to wikipedia vs. paid contributions.
The life-force (or fuel) of an organisational structure is human action that yields **surplus** - that means production of surplus is in the critical path to more Participants, and so our algorithm must optimise for this.
Amdahl's law can be restated as "the more you need consensus about what to build, the less efficient you will be at building it". For Nostrocket to be the most efficient problem solver and builder, it must require the least amount of consensus on what to build and how to build it.
Projects like ZeroMQ have proven that it's possible for valuable products/services (i.e. powerful and effective solutions) to evolve from simple rules with **no upfront planning** or consensus. This is core to our approach to innovation and surplus without requiring any consensus on what to build or how to build it - no upfront planning and no leadership.
The set of boundary conditions for human action within Nostrocket is defined by the Nostrocket Unprotocol. It's rather long, so here's a summary:
0. Anyone who's not already a **Participant** MAY become a Participant by being validated by an existing Participant. This results in a **tree of Participants** called the Identity Tree.
1. Change follows the **Serbian method** - a continuous pattern of accurately identifying **Problems**, and applying the **simplest possible solution** to each Problem.
* This project is currently applicable only to a *very* tiny subset of humanity who are able to understand the concept and do something useful with it, but this subset should get *less tiny* with each problem solved.
* As these problems and minimal solutions pile on top of each other, novel and valuable products/services will evolve (read the protocol to get a more complete picture of how this works).
* There's nothing that inherently limits Nostrocket to producing software based solutions, it could also produce hardware, houses, food, etc.
2. Any Participant MAY log a **Problem** (an observed matter or situation regarded as unsatisfactory).
* There are no bug reports or feature requests, these are just problems (or they aren't).
* There are no priority levels for problems, there are just problems that are worth solving (or not).
* Problems should be reasoned about and broken down into smaller problems until they are objective or replicable, and actionable.
* Problems should be broken down until they are small enough that they can be solved very quickly - anything longer than 6 hours of working time is probably too big.
* Problems MUST be relevant to Nostrocket itself. Nostrocket is not a freelancing market or a problem-solver for hire.
* Problems MUST be nested under another Problem, creating a Problem Tree.
3. Any Participant MAY **Claim** (and solve, typically with a **Patch**) any unclaimed Problem. Any **Maintainer** can (and should) **Merge** any Patch that does **not** violate the Unprotocol.
* At this early stage most of the problems Nostrocket is likely to encounter will simply be with its own implementation, hence they will typically be solved with a Patch. However, if the experiment is a success this will start to involve the physical world, things like Nostrocket meetup or conference related problems might be some of the first examples.
4. A Participant who solves a Problem MAY indicate the value of their work by creating a **Dispendium**
* A Dispendium MUST be denominated in Satoshi
* A Dispendium is **not** an entitlement or guarantee to be paid
* An Dispendium is how a Participant SHOULD communicate the sacrifice they have made in solving the problem
* An Dispendium allows Participants to peer review the value being claimed by comparing individual solutions and their associated Dispendiums
5. Participants with **Votepower** MAY vote to **Ratify** (approve) or **Blackball** (reject) a Dispendium.
* The Dispendium SHOULD be rejected unless it's along the route (or **critical path**) to more Participants.
* Votepower is a measure of a Participant's **skin in the game**.
* `Votepower = Shares * Leadtime`
* Every Participant's `Leadtime` starts at `0`.
* A Participant's Shares **cannot** be spent/transferred if their `Leadtime > 0`.
* A Participant MAY increase or decrease their Leadtime by `1` every 2,016 blocks (but can't become negative)
* If more than 50% of Nostrocket's Votepower approves a Dispendium, and less than 5% reject it, its Approved.
* If Participants with Votepower reject Dispendiums that comply with the Unprotocol and are reasonable amounts, others will see this and stop working, and Nostrocket will die or be forked.
* If Participants with Votepower approve Dispendiums that should not be approved, they are diluting their own Shares for no good reason.
6. If a Dispendium is **Approved**, new **Shares** are created for the Participant who logged the Dispendium (1:1 per Satoshi claimed in the Dispendium).
* Shares MUST NOT be created **any other way** (that would mean the experiment has **failed**).
* Nostrocket has been instantiated with a **single** share as this is technically the only way to bootstrap the process.
7. Participants own **all** revenue produced by anything Nostrocket builds. Whenever anyone pays for a product/service created (or **discovered**) by Nostrocket, the Sats are streamed **directly** to Participants in proportion to the number of Shares they have and how long they've had them.
* Revenue distribution MUST be fair for everyone. Potential Participants who take more risk by making sacrifices before it's clear if the experiment will work or not need to agree that it's fair. Potential Participants who want to do work after the concept is well established and revenue is being generated must also agree that revenue distribution is fair.
* When there's a pot of money available, Mallory finds a way to corrupt whatever is guarding it.
* Nostrocket MUST NOT retain any capital or raise any funds (and doing so is an anti-pattern that fundamentally precludes decentralisation).
