Decentralized Update Governance (DUG)

Orthogonal concepts to be defined independently but worked together:

• identification (e.g., by content hash) of current version
• linkage of versions into a linear series, SkipChain, or TimeTree
• update authorization by one or quorum of identities
• authentication of identities (people or devices) eg by signing
• registration of updates on authoritative registry or registries
  • checking of witnesses by threshold
• definition of unambiguous authoritative chain by timescale?

– Version Identifier (VID) scheme:

Intended to be a type of URI that you put into your source Web content (or other content) to represent a trackable object, whose VIDs can be upgraded automatically when the target changes. Or better to put the VID info in the target’s metadata?

– DUG scheme:

In a web page, insert into a META tag in the header. In other types of files, can be in a comment etc toward the beginning.

Can specify either directly in-line or out-of-line the update governance spec?

Needs to tell readers:

• how to be certain that this is a valid/correct DUG spec
• at what location(s) the current/updated status, versions can be found
• how to validate their authorization, correctness, and consistency

To head off DUG attacks on temporarily-hacked websites or subpages, need to have a root-level robots.txt-like indication for readers to consider DUG specs to be authoritative?

Example full VID reference:

vid[:/] vid[sha256:/foo/bar/#blah]

Alternatively, for agility, make VIDs a list of alternate sub-CRIs with different schemes/ciphersuites?

Example:

vid[1[/],2[/]]

Proto-VID marker:

vid[]

This just requests the content/version control system to replace this marker with a full VID on initial checkin.

– Functionality I want from governed versioned series:

• Anyone can produce a series in most any way
• Format and cryptographic agility
• anyone can publish a series in multiple ways: direct HTTP server, P2P, WebRTC, or via third-party like GitHub, cloud, IPFS, etc.
• can require multiple signoffs to produce/publish new versions signoffs via multiple devices, users, etc.
• multiple signoff notification/request protocols (push notifications, etc)
• blockchain/registry agility: Bitcoin, Ethereum, private, etc.

–

Functionality I want from TimeTrees:

• Any device can create/maintain its own TimeTree
• authenticated by one or more device keypairs (maybe one cipherswuite defining both the keypair type and the cryptographic hash algorithm for the TimeTree)
• a new TimeTree for a new suite can be constructed to contain an old one
• a device can “publish” its TimeTree directly (peer-to-peer), and/or to third-parties (GitHub Pages, Amazon/Google, IPFS).
• other devices can follow and verify consistency of a TimeTree via various protocols: HTTP, git, peer-to-peer, IPFS, Tor, etc.
• it’s up to application/device whether leaves remain published forever or get pruned with time or when no longer needed

– TimeTree state ID (or TimeTree Stamp?): consists of optional human-readable date stamp in RFC 3339 format, followed by sequence of optional cryptographic hashes, one per bit in the binary representation of the number of seconds since Unix Epoch, with present hashes for one bits and omitted hashes for zero bits. Each hash is the root of a complete binary Merkle tree of height corresponding to that bit position.

Optionally may have more bits representing stamps with greater precision represented as a binary fraction of a second.

Syntax: “hash_n;[hash_n-1];…;[hash_0][.[hash_-1];…;[hash_-m]]” where n is the highest set bit in the timestamp, and m is the number of fractional bits in the timestamp.

Since the number of seconds since the Unix Epoch is directly derivable, the TimeTree state ID also serves as a representation of the timestamp.

Defined with respect to a particular cryptographic hash algorithm, such as sha256.

Full URI: “tts:sha256:hash_n;…;[hash_-m]”

Binary-to-ASCII encoding specified with tts scheme? Base85?