cryptogen spec

information centric networking

a network architecture dealing primarily with logical packets of information, rather than virtualized point-to-point channels like in tcp/ip. this insight from named data networking has important consequences for mobile adhoc networking as well. we hypothesize that the efficiency gains that come from this broadcast-friendly architecture are critical for the success of mesh networking.

similar to "data packets" in NDN, each message has multiple names. a true name, which is an encoded cryptographic hash of the file itself. we call this kind of information "self-certifying". given a true name, you can find a file and verify its integrity. additionally, agents can associate a self-certifying name with a "pet name" or "subjective label" of their choosing and share it with their friends/peers. zoko's triangle can suck it.

a message represents a logical bundle of information. the following three packet types allow for a variety of discovery paths. for example, amandine can broadcast an interest like `/a-friends-key-sha256/blog/*` to listen for updates to her friend's log and send out a ping when her own log changes so it can be pulled into the network by online interested parties. variations such as eager-push may append the complete data packet to the announce trasmission to avoid chatter.

ANNOUNCE says to all known peers, "i have data in these prefixes"

SUBSCRIBE says to all known peers, "i want data for these prefixes"

SEND selects between --/--> and --//-> depending on the available interfaces

broadcast interest in a particular name
╔═════════════════╦═════════════════════════════════════════╗
║ type: subscribe ║ value: /<key.sha256>/<path:name>        ║
╚═════════════════╩═════════════════════════════════════════╝
proposed additional "announce" packet
╔═════════════════╦═════════════════════════════════════════╗
║ type: announce  ║ value: /<key.sha256>/<path:name>        ║
║                 ║        /<prefix0-key.sha256/<path:name> ║
║                 ║        /<prefix1-key.sha256/<path:name> ║
╚═════════════════╩═════════════════════════════════════════╝
logical data packet
╔═════════════════╦═════════════════════════════════════════╗
║ type: data      ║ value: /<key.sha256>/<path:name>        ║
║                 ║        <blob.sha256>                    ║
║                 ║        <blob>                           ║
╚═════════════════╩═════════════════════════════════════════╝

interfaces with venti and offfs to replicate messages over the network, up to 56KiB in size. cryptogen peers send broadcast/multicast messages (NOT replicated unicast) to search for (interest) logical block names and announce physical and logical block names. if a match is found, the responding peer broadcasts the requested data blocks. depending on the network config, cryptogen can send raw ethernet frames to `ff:ff:ff:ff:ff:ff`, zero or more UDP broadcast addresses, or zero or more UDP multicast addresses.

data mesh blocks may be encrypted at rest, traffic is otherwise protected only by the limit of physical broadcast domains. unicast channels MUST BE encrypted. bridge channels are a secondary feature of the system. the primary objective is physical mesh routing. ipv6 is required for all bridge channels.

network capabilities are optional secret values that are used to create true names that cannot be validated without the shared secret. these should be easy to rotate. internally we may have public and private aliases to the same data so we can simply re-compute restricted names to apply to sigil transformations. these are also used to define the parameters of the search space used by the network.

content-addressed network cache

when it comes to the magical world of incentives, people like to think about payments. this is a very limited way of thinking. instead, we must think about abundance, cooperation, and symmetrical assistance. a brightnet design inspired by Owner-Free Filesystem gives us a vision of a useful public storage system.

offs

subjective networking

cryptogen has no standard library, instead we define *conventions* to fill the same role. no single convention is meant to dominate the network. basic interop is maintained by the low level structure, but each convention is free to interpret the buffered state as it wishes. flexible versioned netcode!

events from the network and messages from other processes are dispatched to handler functions for storage and additional processing. this behavior is controlled with a pattern matching document in /lib/cryptogen/plumbing. each of these contracts describes a behavior of the network with data-parallel semantics. baseline contracts define transmission and sampling behaviors on network interfaces, state buffering, and gossip routing.

gossip

XOR filters are used to create compressed indexes of known keys.

record format

bencoding

d3:cow3:moo4:spam4:eggse =  { :cow "moo" :spam "eggs" }
d4:spaml1:a1:bee = { :spam [ "a" "b" ] }
de = {}
le = []

binding name system

> ring << chirp, chirp >>

> hoo hoo hoo = hoo hoo

every chunk of data has a subjective name, a nickname, or handle if you will. these are used to identify truly-named objects in a human-readable way, easily defeating zoko's triangle. these names are shared using a simple protocol that demonstrates the call window concept discussed above. each peer publishes a list of bindings they control.

sys/actors
	name
		key1
		key2
name
	mu
	qi

binding table index (true name of all bound names)

search index (true name of all subscriptions and interests)

content index (all known true names)

a partition function is used to sort index records into groups. each group is used as the input for `≠˝𝕩` to compute an XOR filter identifying all known keys in each partition. for the simple case, one filter is generated for each index.

# binding table
dn=<name>
	xt=urn:<hash_type>:<hex_digest>    # exact topic "true name"
	x.sig=urn:<hash_type>:<hex_digest> # (apply (comp sig bencode) { :dn <name> :xt urn:<hash_type>:<hex_digest> })
	as=<url>                           # acceptable source "legacy number"
	tr=<url>                           # hypergate number

group programs (contracts)

contracts are frozen programs that provide various network services. a contract takes arguments from stdin and writes to stdout. the format of the program is irrelevant in the general case, the referenced bencode object describes the binding. try to keep it simple, but i don't want to mandate anything as far as contract processing.

a "group program" can be thought of as a more general "smart contract" which takes multiple user's messages as input, and returns a derived state. cryptogen defines the medium, a group program defines the form. a set of baseline conventions is outlined separately.

the group takes arguments from stdin and writes to stdout. the format of the program is irrelevant in the general case, the referenced bencode object describes the binding. try to keep it simple, but i don't want to mandate anything as far as contract processing. user requests are dispatched by plumbing rules to the corresponding resolver, which must eventually reach the cryptogen service. the indirection here allows for custom resolvers that can fetch data from any supported network resource. plumbing is also used to dispatch network state updates to other applications.

transmission

the gossip network makes use of broadcast capabilities in physical networks, wireless in particular. each peer considers only one hop at a time. simply, broadcast or recieve on one or more interfaces. pending requests are aggregated at each hop. prefix aggregation and request bundling break forwarding loops, so more available links can be used simultaneously.

-----> recieve
--/--> broadcast
--//-> replicated unicast

[replicated unicast] bridge networks: yggdrasil, tinc

[broadcast] physical networks: LAN, WiFi, BLE

# announce/interest packet goes to broadcast
# allegedly sending a broadcast UDP packet is equivalent to sending a
# MAC broadcast.

 FF:FF:FF:FF:FF:FF
 ANNOUNCE :len :name

 FF:FF:FF:FF:FF:FF
 SUBSCRIBE :len :name

pending interest table

pending announce table

pub/sub config table

known peers table (reliable peers are tagged 'eager, other known peers tagged 'lazy)

MTU 1472 octets. interest and announce packets are limited to this size. data packets are limited to 56k octets (39 packets).