- How to move from scarcity to abundance?
- "Network technology provides a disintermediating layer where you may not know what’s on the other side"
- Decentralized networks that enable social scalability are also public utility networks
- Software's anti-fragileness: if a piece of software is attacked (and survives), it'll be patched later and be stronger than before
- Blockchains as a new life form: it survives because it can pay people to keep it alive, and performs a useful service to incentivize that
- AI DAOs live and evolve rather than being simulations
- XOR swap can be incredibly efficient (way more than
(arr[uint(i)], arr[uint(j)]) = (arr[uint(j)], arr[uint(i)]))
- Fat protocols:
- Enable more experimentation; network effects don't lie inside the client itself so more are built
- Better UX comes in varieties: interfaces, supporting more networks, additional features, etc.
- These differentiating clients have sovereignty; they are able to do anything the underlying protocol supports, and the protocol owners can't censor them
- Live by themselves, outside of their original creators
- Enable more experimentation; network effects don't lie inside the client itself so more are built
- Protocols split product / market fit into two:
- Protocol / market fit: is the protocol powerful and general enough?
- Evolve democratically in civil communities
- Fork when relationships feel adversarial
- Application / consumer fit: does the application optimize how the user wants to use the protocol?
- Finding this fit may be embarrassingly parallel
- These applications can find their fit by narrowing the use case of a protocol (e.g. video instead of all media)
- Protocol / market fit: is the protocol powerful and general enough?
- The "right way" maximizes on all fronts:
- Simplicity
- Correctness
- Consistency
- Completeness
- The "worse-is-better" approach:
- Simplicity: most important
- Correctness: in all observable aspects; better to be simple than correct
- Consistency: not overly inconsistent, best to drop parts that deal with less common parts that introduce complexity or inconsistency
- Completeness: as much as practical; never sacrifice for simplicity, can sacrifice consistency for completeness (especially for interface consistency)
- Simplicity means it's easier to spread to areas that are below the median (e.g. simpler implementation means it's easier to port to slow machines)
- Condition users to accept worse than the right thing, if the initial product is good
- It is better to get half of the right thing available so that it spreads like a virus.
- Afterwards, the community will improve upon it naturally