nmushegian

- monospace protocols company principles
	- We are an R&D firm.
	- We only work on systems we believe are credibly neutral, and aim to make this definition rigorous.
	- Any software written for a client must be licensed permissively.
	- We do not operate validators (we run full nodes but do not produce blocks). People can run whatever they want as individuals or side ventures.
	- We only accept investments from entities that leave us complete control over when and how to allocate funds and to pay returns. We are making long term plays and there is no reason to invest in us if you don't think we know what we are doing.

- Software Writers
	- Software writers spend 60% time on personal projects and 40% on company projects.
	- Software writers own their IP, but must license it permissively (more specifics later).

nmushegian

1. COINTELPRO Techniques for dilution, misdirection and control of a internet forum
2. Twenty-Five Rules of Disinformation
3. Eight Traits of the Disinformationalist
4. How to Spot a Spy (Cointelpro Agent)
5. Seventeen Techniques for Truth Suppression
______________________________________________________________________________________

nmushegian

There was someone named Terry Davis. You can read about him on wikipedia.
Terry understood that the way big software companies made software was harmful for regular people.
But he did not understand how to explain it to the people it was harming.
To make sure he could never explain it in a way that people could understand, the people who wanted to
create harmful software on purpose caused him to harm himself in ways he didn't understand.

I think that the people who wanted to help him thought that he was sick and that they needed to try to
change the way that he thinks. But I think that if those people had tried to understand what
he was saying, they would have seen that Terry's mind was so preoccupied with trying to explain
something really important that he just forgot to take care of himself.

nmushegian

contract Vault {
  Gem public top;
  Gem public bot;
  constructor(address _top, address _bot) {
    top = _top; bot = _bot;
  }

  function cost(uint amt) external returns (uint);
  function exit(uint amt) external returns (uint);
  function join(uint amt) external returns (uint out) {

nmushegian

```
// This code snippet shows how an external function can use a pattern like
// python's `try..except..else` with `.call`, `throw`, and reentry

contract TryExceptElsePatternUser {
    address _sender;
    function tryExceptElsePatternExample()
        external // must be external
    {
        if( msg.sender == address(this) ) {

nmushegian

We have started a series of free software releases that will let people to use the decentralized web in more ways that help them, without having to buy special tokens. We will give example after example of how you can look at a token and tell if there is a simple way to build something that is more helpful by removing it or simplifying it. We will suggest a simple test to tell whether you really need to buy a token for a new invention to work properly. We will show that giving your users a true understanding of what something is gives you a competitive advantage, even if it means the user doesn't want to pay for exactly what you had in mind. We will show that we can do this while making more money than any project that follows rent-seeking strategies.

When we show people how to analyze the flow of value without needing a unit of account or reference asset, we expect some backlash.
There are many projects that accidentally create unjust systems -- that means a system where they would want the rules to be diff

nmushegian

// This is a really bad and wasteful pattern from a long time ago!
// Just prorate against an internal continuously-growing conversion rate!
//    See Maker code or similar

import 'dappsys/auth.sol';
import 'misc/math.sol';

// maintain a `last_touched` with each balance, then prorate it before any time it is touched.
// addPoint to change the rate
// this will ensure all balances appear to have the correct continuous growth/decay even if

nmushegian

function cs {
    cd $@ && ls
}
function gs {
    git remote -v
    git status $@
}
function gca {
    git commit add $@
}

nmushegian

use clear names to answer 'what'
use clear statements to answer 'how'
use comments to answer 'why'

nmushegian

import json
from collections import Counter, defaultdict
from dataclasses import dataclass, field
from decimal import Decimal
from itertools import chain

import requests
from eth_abi import encode_single
from eth_utils import function_signature_to_4byte_selector, decode_hex, encode_hex
from itertools import count