Not logged in

Version 0.9.9-20240704.

net2o separates data and commands. Data is passed through to higher layers, commands are interpreted when they arrive. For connection requests, a special bit is set, and the address then isn't used as address, but as IV for the opportunistic encoding.

The command interpreter is a stack machine with two data types: 64 bit integers and strings (floats are also suppored, but used infrequently). Encoding of commands, integers and string length follows protobuf conceptually (but MSB first, not LSB first as with protobuf, to simplify scanning), strings are just sequences of bytes (interpretation can vary). Command blocks contain a sequence of commands; there are no conditionals and looping instructions.

Strings can contain encrypted nested commands, used during communication setup.

List of Commands

Commands are context-sensitive in an OOP method hierarchy sense.

base commands

reply commands

connection generic commands

connection setup commands

connection commands

file commands

ack commands

log commands

key storage commands

address commands

dht commands

vault commands

message commands

group description commands

messaging commands

DVCS patch commands

DVCS metadata is stored in messages, containing message text, refs and patchset objects. Patchset objects are constructed in a way that makes identical transactions have the same hash.

payment commands


Contracts are state changes to wallets. A serialized wallet is a contract that contains all the changes from an empty wallet to fill it; it is not checked for balance.

A dumb contract is checked for balance. It consists of several selectors (source/account, asset), transactions (amounts added or subtracted from an asset), comments (encoded for the receiver, with a ephermeral pubkey as start and a HMAC as end). Comments are fixed 64 bytes, either plain text or hashes to files. Transactions have to balance, which is facilitated with the balance command, which balances the selected asset.

The signature of a contract signs the wallet's state (serialized in normalized form) after the contract has been executed. The current contract's hash is part of the serialization.