npub12s…yayqf on Nostr: Civilisation is fundamentally composed of human action (and *inter* action), so this ...
Civilisation is fundamentally composed of human action (and *inter* action), so this is the primitive we must work with to create Stackerstan.
The usefulness of a bucket exists due to 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 can humans take while remaining in the organisational structure.
**Centrally planned** organisations like companies or governments tend to restrict human action within them through a combination of:
* internal rules about what types of human action are permissible,
* internal rulers with the power to decide when to update the internal rules and when to break them, and
* excluding people who "don't fit the culture" or aren't a "team player".
Centrally planned organisations exist along a spectrum of just how centrally planned they are - from highly planned and executed military organisations to the **Teal** organisations as described by Frederic Laloux (well worth skimming through his book).
**Decentralised organisations** tend to restrict human action by:
* deciding ahead of time on all the possible types of human action that is permissible, and
* encoding the rules about these actions into some form of state machine (usually a smart contract).
Decentralised organisations are typically inflexible due to this architecture. Changing the set of human action that is permissible within the organisation usually requires smart contracts to be republished, which is where the community generally falls back to trusting a central team.
There are more flexible decentralised organisational structures, but they invariably require upfront consensus on what to do and how to do it. This precludes scaling because the more you need upfront consensus the less speedup you get by adding additional "workers". The flipside to precluding scale is precluding efficiency.
Something similar happens when any type of upfront funding is involved. It not only creates a honeypot with an associated overhead to defend it, but also precludes the ability to do anything without widespread agreement on what to do.
The metric we use to judge if Stackerstan 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* Stackerstan than they are by acting outside of it.
* Stackerstan must result in more value for Participants than any other opportunity available to them.
* Stackerstan must become, and actively remain, the most efficient organisational paradigm currently possible
* The mechanism by which work gets done within Stackerstan cannot require upfront agreement on what that work should involve or what the end result should look like
* Stackerstan cannot require any upfront funding and cannot retain any capital
* To remove any internal friction, Stackerstan must be radically fair to all Participants
* Stackerstan'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 Stackerstan 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.
###### Solution: a protocol for a universally applicable hill-climbing algorithm, executed by self-interested human action.
The core of Stackerstan 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 state of Stackerstan, but the algorithm itself is primarily executed by self-interested human action and not machine.
Human action within Stackerstan 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 paying them. A case in point: organic contributions to wikipedia vs. paid contributions.
The life-force (or fuel) of civilisation 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 more inefficient you will be at building it". For Stackerstan 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 Stackerstan is something we call the Stackerstan Superprotocolo. 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**.
1. Change follows the **Serbian method** - a continuous pattern of accurately identifying **Problems** that are relevant to *Stackerstan itself*, 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 Stackerstan 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 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.
* Stackerstan only solves problems that affect Stackerstan itself, it is not a problem-solver for hire or a freelancing market.
3. Any Participant MAY **Claim** (and solve, usually with a **Patch**) any unclaimed Problem. Any **Maintainer** can (and should) **Merge** any Patch that does **not** violate the Protocol.
* At this stage all the problems Stackerstan is likely to encounter will simply be with its own implementation, hence they will usually be solved with a Patch. However if the experiment is a success this will start to involve the physical world, things like meetup or conference related problems are likely to be some of the first examples.
4. A Participant who solves a Problem MAY create an **Expense** for their work, denominated in Satoshi.
* An Expense is **not** an instrument by which a Participant gets paid Bitcoin, it's merely a way for a Participant to tell other Participants how much time/effort they spent in solving the problem.
5. Participants with **Votepower** MAY vote to **Ratify** (approve) or **Blackball** (reject) an Expense.
* The Expense SHOULD be rejected unless it's along the route (or *critical path*) to more Participants, revenue, or lulz.
* 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 Participants with Votepower reject Expenses that comply with the Protocol and are reasonable amounts, others will see this and stop working, and the project will die.
* If Participants with Votepower approve Expenses that should not be approved, they are diluting their own Shares for no good reason.
6. If an Expense is **Approved**, new **Shares** are created for the Participant who logged the Expense (1:1 per Satoshi claimed in the Expense).
* Shares MUST NOT be created **any other way** (that would mean the experiment has **failed**).
* We have instantiated the system with a **single** share as this is technically the only way to initiate the process.
7. Participants own **all** revenue produced by anything Stackerstan builds. Whenever anyone pays for a product/service created (or more accurately: **discovered**) by Stackerstan, the Sats are streamed **directly** to Participants in proportion to the number of Shares they have and how long they've had them.
* When there's a pot of money available, Mallory finds a way to corrupt whatever is guarding it.
* Stackerstan MUST NOT retain any capital or raise any funds (and doing so is an anti-pattern that fundamentally precludes decentralisation).
The usefulness of a bucket exists due to 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 can humans take while remaining in the organisational structure.
**Centrally planned** organisations like companies or governments tend to restrict human action within them through a combination of:
* internal rules about what types of human action are permissible,
* internal rulers with the power to decide when to update the internal rules and when to break them, and
* excluding people who "don't fit the culture" or aren't a "team player".
Centrally planned organisations exist along a spectrum of just how centrally planned they are - from highly planned and executed military organisations to the **Teal** organisations as described by Frederic Laloux (well worth skimming through his book).
**Decentralised organisations** tend to restrict human action by:
* deciding ahead of time on all the possible types of human action that is permissible, and
* encoding the rules about these actions into some form of state machine (usually a smart contract).
Decentralised organisations are typically inflexible due to this architecture. Changing the set of human action that is permissible within the organisation usually requires smart contracts to be republished, which is where the community generally falls back to trusting a central team.
There are more flexible decentralised organisational structures, but they invariably require upfront consensus on what to do and how to do it. This precludes scaling because the more you need upfront consensus the less speedup you get by adding additional "workers". The flipside to precluding scale is precluding efficiency.
Something similar happens when any type of upfront funding is involved. It not only creates a honeypot with an associated overhead to defend it, but also precludes the ability to do anything without widespread agreement on what to do.
The metric we use to judge if Stackerstan 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* Stackerstan than they are by acting outside of it.
* Stackerstan must result in more value for Participants than any other opportunity available to them.
* Stackerstan must become, and actively remain, the most efficient organisational paradigm currently possible
* The mechanism by which work gets done within Stackerstan cannot require upfront agreement on what that work should involve or what the end result should look like
* Stackerstan cannot require any upfront funding and cannot retain any capital
* To remove any internal friction, Stackerstan must be radically fair to all Participants
* Stackerstan'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 Stackerstan 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.
###### Solution: a protocol for a universally applicable hill-climbing algorithm, executed by self-interested human action.
The core of Stackerstan 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 state of Stackerstan, but the algorithm itself is primarily executed by self-interested human action and not machine.
Human action within Stackerstan 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 paying them. A case in point: organic contributions to wikipedia vs. paid contributions.
The life-force (or fuel) of civilisation 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 more inefficient you will be at building it". For Stackerstan 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 Stackerstan is something we call the Stackerstan Superprotocolo. 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**.
1. Change follows the **Serbian method** - a continuous pattern of accurately identifying **Problems** that are relevant to *Stackerstan itself*, 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 Stackerstan 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 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.
* Stackerstan only solves problems that affect Stackerstan itself, it is not a problem-solver for hire or a freelancing market.
3. Any Participant MAY **Claim** (and solve, usually with a **Patch**) any unclaimed Problem. Any **Maintainer** can (and should) **Merge** any Patch that does **not** violate the Protocol.
* At this stage all the problems Stackerstan is likely to encounter will simply be with its own implementation, hence they will usually be solved with a Patch. However if the experiment is a success this will start to involve the physical world, things like meetup or conference related problems are likely to be some of the first examples.
4. A Participant who solves a Problem MAY create an **Expense** for their work, denominated in Satoshi.
* An Expense is **not** an instrument by which a Participant gets paid Bitcoin, it's merely a way for a Participant to tell other Participants how much time/effort they spent in solving the problem.
5. Participants with **Votepower** MAY vote to **Ratify** (approve) or **Blackball** (reject) an Expense.
* The Expense SHOULD be rejected unless it's along the route (or *critical path*) to more Participants, revenue, or lulz.
* 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 Participants with Votepower reject Expenses that comply with the Protocol and are reasonable amounts, others will see this and stop working, and the project will die.
* If Participants with Votepower approve Expenses that should not be approved, they are diluting their own Shares for no good reason.
6. If an Expense is **Approved**, new **Shares** are created for the Participant who logged the Expense (1:1 per Satoshi claimed in the Expense).
* Shares MUST NOT be created **any other way** (that would mean the experiment has **failed**).
* We have instantiated the system with a **single** share as this is technically the only way to initiate the process.
7. Participants own **all** revenue produced by anything Stackerstan builds. Whenever anyone pays for a product/service created (or more accurately: **discovered**) by Stackerstan, the Sats are streamed **directly** to Participants in proportion to the number of Shares they have and how long they've had them.
* When there's a pot of money available, Mallory finds a way to corrupt whatever is guarding it.
* Stackerstan MUST NOT retain any capital or raise any funds (and doing so is an anti-pattern that fundamentally precludes decentralisation).