text:
**Draft warning:** this is a public draft dated 27 Oct 2015, but should not be considered final. If you'd like to stay updated, consider joining the [Hypergolix mailing list](https://www.hypergolix.com/#page-top). Our previous whitepaper was very shy on technical details and has been moved to a [design philosophy](/design_philosopy.md) document.

# Introduction

Question: what is a social network?

Social systems are communicative. They are defined by interactions between entities. Broadly speaking, these entities must be capable of independent action; that is to say, they must possess a degree of individual [agency](https://en.wikipedia.org/wiki/Agency_%28philosophy%29). A non-agent component in a social interaction -- for example, a megaphone -- is simply a tool of its owner-agent. We don't talk *to* megaphones; we talk *through* them.

Networks are defined by the links between their interconnected nodes. *Digital* networks are simply information exchanges between discrete computational devices. In a digital world, these linked data handlers -- computers, phones, servers, *devices* -- are our megaphones.

It stands to reason that a social network should be simply the combination of these two concepts. Individual digital agents, connecting *through* their devices, *to* other agents. It makes no more sense to address our communications to the devices themselves than it would to talk to a megaphone while ignoring the person holding it. And yet crucially, we lack a protocol that defines and protects the difference. We intend Golix to fill this need.

## Defining the philosophical requirements

The Golix protocol's philosophical goal is to algorithmically protect individual agency on any digital network. In this context, we assume that the null state of any agent is a total absence of information. From that, we define agency as the ability to create, retain, receive, and share data; an agent may choose to retain any information she creates or receives, and she may share any information she retains. We abstract these four capacities into three "social actions": authorship, retention, and communication.

We impose a strict dichotomy between agents and non-agents: agents **must** be capable of **all** social actions, and non-agents **must** be capable of **none**. Furthermore, we treat the abstention from social actions as implicit; in other words, an agent must be free not only to retain data, but also to ignore it.

Finally, we assert that agency *at the Golix protocol level* is a walled garden, and that no agent or non-agent may be capable of restricting another's agency. From a practical standpoint we therefore require the protocol to maintain full content agnosticism on any Golix-implementing network.

## Defining the technical requirements

We translate the philosophical requirements for data retention, communication, and authorship into three technical concerns: content, sharing, and identity management, respectively. As they are the basis for our definition of agency, these three functions must then be fulfilled by the Golix protocol.

To satisfy our null state, all content must be private by default; it must therefore be permanently encrypted upon authoring. Similarly, to enforce our walled garden, content must have provable integrity. As a practical concern we require content to be of publicly-provable agent origin. We offset this threat to network-content agnosticism with the explicit requirement that digital identities carry no inherent physical meaning. Put differently: content compliant with the Golix protocol must always be publicly authenticated by a single digital agent, but that agent's identity may be anonymous, pseudonymous, or eponymous.

Given the requirement for universal encryption, sharing management can be technically described as keysharing. Because non-agents may not take network action, within the protocol, content can only be shared by agents. In a similar vein, as agents must be capable of non-action, protocol-compliant data need not be shared. However, once an agent has received a content key, if she chooses to retain it, the walled garden constraint prevents anyone (including the content's author) from restricting her ability to subsequently re-share it. As such, *any* communication may result in a sharing "cascade"; at the Golix protocol level, this is an unavoidable consequence of agency.

Finally, for content to have verifiable integrity and authenticity, agent-authors must be capable of generating cryptographic signatures. In addition to the compromise behind forced public authorship with no inherently meaningful identification, agents should further be capable of privately provable identity aliasing. That is, any Alice should be capable of forming multiple digital identities, and proving to any (but not every) Bob that these aliases are equivalent.

## Defining the scope

For a general-purpose protocol, the importance of scope declaration really cannot be understated. Our goal is to create a [zero-cost abstraction](http://blog.rust-lang.org/2015/05/11/traits.html) that consolidates shared social infrastructure into a singular mechanism, regardless of data transport or application. And given our broad definition of "social network", protocol use cases far exceed web sites and apps: they could be as broad as distributed atmospheric sensor networks or autonomous robot swarms. As such, predicating the protocol on the use of a particular server stack, API, or emerging technology seems highly inappropriate.

Furthermore, many of these use cases lack traditional relationships between agents. Subjecting a temperature sensor to a [FOAF](https://en.wikipedia.org/wiki/FOAF_%28ontology%29) description, for example, seems patently absurd. With the Golix protocol we deliberately avoid such high-level constructs. We specify no relationships between agents, nor restrict any interactions between them, nor what physical means they use to communicate. These are all concerns for different levels of abstraction. The Golix protocol is concerned only and exactly with converting any network-oriented transport mechanism into a standardized agent-oriented social overlay.

Finally, robust transport and application independence require the Golix protocol to support the least restrictive set of possible network architectures. To this end we make the following assumptions:

+ Asynchrony at sufficient speed is a superset of synchrony
+ Arbitrary binary data is a superset of any encoded information
+ One-to-any is a superset of one-to-none, one-to-one, and one-to-many
+ Static content is a superset of dynamic content (dynamic content is a set of related, time-dependent static frames)

# Content management

Consolidating technical requirements and applying scope limitations leaves the following minimum requirements for Golix content:

+ Binary format
+ Asynchronous availability
+ All content uniquely and statically identifiable on the network
+ All data contained within a private, encrypted body
+ Exactly one piece of public metadata: a unique identifier for the content's author
+ Hashed for integrity verification
+ Signed for authentication

Including a public identifier for content authorship is compromise between information privatization and network utility. It's both a defensive and offensive measure. It allows agent-authors to maintain their authorship across all communities, alleviating problems associated with [posting content to competing networks](http://www.urbandictionary.com/define.php?term=Freebooting). It also allows the network itself to police bad actors, and provides a general-purpose point of contact for remediation.

## Persistence and its standardization

Because asynchronous systems allow agents to be online or offline at any time, they require a networked data persistence mechanism. Because the Golix protocol avoids all transport routing information, this persistent data buffer is unavoidably dependent upon the underlying Golix-implementing transport layer.

In keeping with the protocol's scope restriction, we do not specify the details of this persistence implementation; instead, transport-specific conventions are more flexibly defined within overlay standards.

However, in the interest of protocol uniformity, we define both the commands to be implemented, and their sequence of transmission, within the Golix spec. Interactions with the persistence layer can therefore be contained within pluggable transport layer implementation packages, and any network node with access to multiple persistence systems can function as a bridge between them.

All persistence providers must, at a minimum, support the following commands:

+ Ping
+ Publish object
+ Get object
+ Subscribe to address
+ Unsubscribe from address
+ List address subscriptions
+ Acknowledge (ack) transmission
+ Non-acknowledge (nak) transmission
+ List bindings targeting an object
+ Query if a debinding targets an address
+ Disconnect

## Data retention and removal

Object deletion is notably absent from the persistence provider command set. There is currently a great deal of controversy surrounding the balance between an individual's so-described "right to be forgotten" and the general public's "right to remember". The Golix protocol is designed around the assumption that ephemerality is unenforceable: that is to say, individual agents have very limited direct control over the longevity of their footprints, whether digital *or* physical. However, since digital networks are generally designed to eliminate physical durability as an application concern, the lifetime of an object on a social platform is, for the most part, a wholly social question.

Golix represents a consolidation of shared social infrastructure into a single unified protocol, so it must be capable of establishing a deterministic framework for network information deletion. Any other outcome would place social restrictions on the persistence mechanism, which, as a part of the transport layer, is intended to be strictly independent of social concerns. This is no small task.

Our solution is inspired by high-level memory-managed programming languages. Objects themselves have no defined lifespan. Instead, their retention is governed by object "bindings". Bindings declare to the persistence provider that the object is under use; when none remain, the persistence provider garbage collects the object. Bindings may be placed by any agent on any content; however, to prevent malicious retention, the unique identifier for the agent is retained as public metadata in the binding. In this way, any agent may apply pressure to the binding party to remove the binding, but the persistence system remains entirely uninvolved in this social (or legal) process. Object bindings represent a compromise between unavoidably infinite and indeterminately finite data lifespans.

## Addressing content

As a mediating party between machine-based transport networks and agent-based social networks, Golix content requires a Golix unique identifier -- essentially, our equivalent of a URL. We consider human-readable names to be an application-specific concern; once again, a distributed sensor network may have no need for them. Their use for objects adhering to the Golix protocol is therefore out-of-scope. Instead, we desire a simple, machine-readable, unique address for all content.

Instead of a centralized content identifier (for example: a unique integer assigned by a trusted oracle), Golix uses cryptographic hash functions to deterministically assign collision-resistant addresses for content. Choosing a sufficiently strong hash function and allowing for future algorithm changes can minimize the risk of redundant addressing, whilst simultaneously adding an extra layer of security; any attempt to modify existing content should result in a new address. This unique address is the Golix Hash Identifier, or GHID.

This address scheme works quite well for static content, but it also fails to provide any form of dynamic referencing. Now, on the one hand, all individual observations are static: if we were to record the temperature of a room at 1-minute intervals for the rest of time, any particular data point would be forever immutable. From this perspective, one could argue that information mutability is, in reality, an application concern -- that a network like Golix has no business with dynamic addresses. However, given that the assumption of the one-way nature of secure hash functions precludes the ability to predict addresses in advance, as a practical concern, a very primitive form of dynamic addressing is exceptionally useful. A profound number of basic network operations (both physical and social) either require or are greatly simplified by a consistently-addressed, time-variant data stream. As such, we argue that the potentially unwanted abstraction overhead of any particular dynamic address system is justified, so long as applications are free to ignore it with no performance consequences.

Therefore, the Golix protocol defines a second kind of object binding. Like static bindings, they prevent object garbage collection; unlike static bindings, they generate a new address for existing content. Like static objects, they can only be created (or updated) by a single agent; however, that agent need not be the author of the objects bound by the address. Dynamic bindings are constructed as an ordered list of bound static GHID(s). The meaning of this list may be application-specific, but is generally assumed to be a buffer, and in such a use is formulated with the newest entry first. The dynamic address is generated once, as the hash of the first set of bound GHID(s), and is then included in all subsequent revisions of the binding.

## Content management primitives

At this point we can fully enumerate the required **public** components in a Golix encrypted object container (GEOC) record:

1. File hash / GHID
2. Author GHID
3. Author's signature of the file hash
4. Symmetrically encrypted payload

As well as a Golix static object binding (GOBS) record:

1. GHID of the agent placing the binding (the binding agent)
2. Binding agent's signature
3. GHID for the object to bind (the target)

And a Golix dynamic object binding (GOBD) record:

1. GHID of the binding agent
2. Binding agent's signature
3. Dynamic address
4. GHID(s) for static target(s)

And a Golix address debinding (GDXX) statement:

1. GHID of the debinding agent
2. Debinding agent's signature
3. Address to be debound

# Sharing and access management

Consolidating technical requirements and applying scope limitations leaves the following minimum requirements for Golix sharing:

+ One-to-any
+ Simple key sharing with static, non-revocable keys
+ Sharing must be initiated by a uniquely identifiable agent
+ Sharing must be directed at a uniquely identifiable agent
+ Connections between the initiator and target agents should not be publicly visible

Given the nature of Golix content containers, including cryptographic access management in the same delivery mechanism seems inefficient and unsustainable. As such, the Golix protocol wholly separates content from key distribution. Normally, relating keys to content resources would present a logistical challenge; however, with all Golix data being directly and only content-addressable, this problem is mostly inapplicable. Also note that public information sharing is out-of-scope, but can be simply constructed as a scripted network agent.

Once keys are separated from content, we can start to build communication primitives from dynamically-bound objects. In the Golix protocol, these channels are known as "pipes". Since Golix-compliant content is always singularly authored, each multidirectional pipe is a combination of unidirectional half-pipes.

## Key/content separation

Many (perhaps most) protocols include some kind of key management within the ordinary application message exchange. For example, the PGP protocol includes both key distribution and encrypted content in the same email. OTR similarly mixes the application message body with exchange key management. This approach is troublesome with arbitrary (and potentially inconsistent) numbers of conversation partners; put simply, it does not scale into a many-to-many network environment, even when individual messages are authored by single parties. As such, the Golix protocol entirely separates key management from content distribution.

The chief downside to this approach when creating a high-level protocol like PGP or OTR is that it does not integrate conveniently with most message-based transport exchanges. This is particularly true for email, where building a usable client for such a system would imply a very heavy-handed post-receipt merger of the separate content and key messages.

However, as a standalone entity, the Golix protocol bears no such limitation. Our biggest concern, then, with this separation of key and message, is how to create a reliable, secure, unambiguous link between the two. This problem can be easily solved by sharing keys paired not with the content itself, but with that content's GHID.

## Inter-agent "pipes"

Half-pipes, once created, are simply a dynamic binding with key state shared between multiple (usually two) agents. The simplest example would use the same key for every dynamic frame. Alice generates her initial frame and dynamic binding, shares the binding with Bob (along with the decryption key), and Bob subscribes to the dynamic address at the implementation level. Alice can then update the binding with new frames, establishing a consistent unidirectional communication channel (the half-pipe) with Bob. To construct a full pipe, Bob repeats the process with Alice. Note that the Golix standard **requires** Bob to use a different symmetric key for his half-pipe. More sophisticated pipes implement key rotation for forward secrecy.

These pipes may be used for any purpose, but are generally intended for one-to-one API communication. Because half-pipes have a consistent shared key state, once one is shared with another agent, it is impossible to revoke access without creating a new half-pipe. As such, in most cases, the optimal strategy is to make a single pipe for each possible pair.

Since agents may expose more than one API, and to avoid accidental or malicious confusion when matching half-pipes into full pipes, pipes should contain an API identifier in the first half-pipe frame. However, this operation -- and in particular, its applicability to dedicated keysharing pipes -- is defined within an overlay standard.

Finally, once a pipe-based transaction is complete, the terminating agent (Alice) pushes a special termination code to her upstream half-pipe. She may then either wait for an off-pipe response acknowledgement (ACK), or she may immediately debind her half-pipe. Either action should be interpreted by her parter Bob as a closure of the pipe, and he must respond by issuing an ACK, and should then remove any bindings he may have placed on Alice's half-pipe.

## Pipe handshakes

Conspicuously absent from this basic description of pipes is the initial keysharing process.  Because the Golix protocol is capable of asynchronous operation, and pipe initiation may not always be between previously "acquainted" agents, the only way to eliminate metadata publicly linking the pipe participants is for the pipe handshake to use public/private cryptography.

This process is fully symmetric and can be initiated by either party. First, Alice creates her half-pipe. She then uses Bob's public key to privately announce the half-pipe's dynamic GHID and its key to Bob, and he responds with either a pipe ACK (if successful) or pipe NAK (if unsuccessful). If a full pipe is desired, Bob can then repeat this process for Alice.

Of course, for Bob to respond, this request must be provably Alice's. Once again, though, we are explicitly avoiding publicly linking Alice and Bob in the handshake request. This has the somewhat undesirable consequence that Bob can only verify Alice's signature *after* decrypting the request. Though this prevents a malicious party from successfully initiating an API pipe on someone else's behalf, it also means that signature verification cannot be performed by the network. This opens a potential DoS-style attack vulnerability: an agent's application could be overwhelmed by spoofed pipe requests with invalid signatures from invalid GHIDs. Such an attack would compromise the victim's ability to initiate new pipes, but presumably leave its existing pipes minimally affected.

Mitigations against this style of attack will likely need to be developed, but it's worth mentioning that, since pipe requests are strictly a one-to-one transaction, they need not be signed asymmetrically. Rather, if both agents' public identities include a Diffie-Hellman public key, the request can be signed using a MAC with a key derived from their DH shared secret. This substantially decreases signature verification time, and therefore increases the computational footprint required for a successful attack. It also has the added benefit of inherent immunity to attempts to link Alice and Bob together by testing signature validity against a dictionary of public keys.

## Key state management

Once a pipe is established, given that Golix agents are device-independent, how do the connected parties remember encryption keys?

Though state can be easily transferred between agents using pipes, state management in the Golix applications themselves can be quite complicated. This will be an area of rapid early development for Golix applications as best practices and overlay protocols evolve.

Fortunately, key memory is a relatively direct form of persistence. It happens at a low level; in general, keys should only be handled by heavily-reviewed protocol implementation processes. Questions like application state sandboxing simply don't apply here: **no** downstream application is trusted with keys. As such, we can directly approach the question of key lifetimes,which is (at the moment) a concern reserved for implementation best practices, and not within scope for the Golix protocol With that being said, actual format for the key state file(s) will be defined within an overlay standard.

## Sharing primitives

At this point we can fully enumerate the required components in a Golix asymmetric request (GARQ) record:

1. Recipient agent GHID (public)
2. Requesting agent GHID (private)
3. Payload (private)
4. Requesting agent MAC (public)

The private payload requirements can then be broken down into three categories. Pipe initiation requests require:

1. Target half-pipe GHID
2. Half-pipe initial symmetric key

Pipe acknowledgement records require:

1. Target half-pipe GHID
2. Initialization status code (optional)

And a pipe non-acknowledgement requires:

1. Target half-pipe GHID
2. Failure code (optional)

# Identity management

Consolidating technical requirements and applying scope limitations leaves the following minimum requirements for Golix identities:

+ Are self-contained, self-describing, and independent of any other identity
+ Can sign content
+ Can receive asymmetric content
+ Can generate Diffie-Hellman shared secrets
+ Can be privately aliased
+ Should be independent of any physical device

Also note that to effectively support device-independent identity, online private key storage is logistically necessary. As with all other network requirements, this need can be served through content containers; however, the format for these containers (and indeed the entire "login" process) is out-of-scope for the core Golix protocol.

Similarly, at this level of abstraction, high-level descriptions of relationships between agents ("Friends lists" and the like) are entirely inappropriate. Automation may be built *on top* of the Golix protocol, but in the interests of general applicability at minimum cost, it should not be "baked" into it.

## Identities within Golix records

A key shortcoming of PGP-over-email is that public keys are distributed on a different transport mechanism than the messages themselves. Now, to be fair, if a key exchange process were also built upon SMTP, it would provide very little protection against man-in-the-middle attacks on initial contact. If Alice requests Bob's key over an insecure transport like email, an adversary Eve can simply intercept that key request, impersonating Bob from the outset. External key distribution helps slightly to mitigate this risk, but robust PGP-over-email implementations rely upon webs of trust. The difficulty here is that it entirely breaks the email workflow, and cannot be self-supporting. This situation is far less than ideal.

However, an alternative would be a protocol where "email addresses" were inseparable from their public key(s). This system, though still vulnerable to phishing attacks (as nearly all human-interfacing systems are), could never suffer from such a direct impersonation attack: if Eve replaced the public key in a malicious response to Alice's key request, Alice would be aware that the new address mismatched her request.

On a Golix-implementing network, use of hash-based GHIDs already provides this property; by storing Alice's identity in a Golix object, we can ensure that changing its content (her public keys) results in the generation of a new GHID. Within the context of Golix, we then refer to "Alice" *only* by the GHID of the container for her public keys. We therefore acquire self-security recipient "addresses" without any added infrastructure overhead. The network, including agent identities, can be wholly self-hosting.

## Aliases and their selective deniability

A final desirable property of identities is aliasing. It's sometimes useful to have a second point of contact for any particular entity. This isn't exactly a pseudonym, since both aliases (at least in this context) can bear the same name; it's more like a having two phone numbers, one public, one private.

Now, a basic alias could be built by simply creating a new Golix identity. But without also providing some provable linkage between the private identity and the public one, this is more a pseudonym than an alias -- two individually consistent digital entities, certainly, but their relationship is no stronger than their word. A better assurance is a preexisting shared secret, but it is not without potential consequences.

Sharing an alias is inherently a vulnerable process. Alice may not entirely trust Bob, but want to talk with him anyway. In this case, it would nice if the aliasing shared secret weren't something Bob could use to authenticate Alice's alias to an outside observer, Eve. For that we have only one option: a secret trivially constructible by either Alice or Bob, originating from nothing more than their principal identities. That way, Alice can always claim Bob made the whole thing up; his use of their conversation as evidence to Eve is wholly predicated on Eve's trust of his word.

Given principal identities BobPrincipal and AlicePrincipal, and alias identity AliceAlias, and assuming that their respective identity containers already include a Diffie-Hellman public key, the mechanism works as follows:

+ Alice creates AliceAlias
+ AliceAlias contacts BobPrincipal
+ AliceAlias sends BobPrincipal the shared secret from a Diffie-Hellman exchange between BobPrincipal and AlicePrincipal.

This mechanism is outlined in detail in a Golix overlay proposal.

## We three keys

Agent identity containers (GIDC) must therefore contain three public keys:

+ Public encryption key
+ Public signing key
+ Public half of Diffie-Hellman pair

# The conclusion: social agency in a digital world

In the physical world, personal agency is the defining characteristic of animate existence. Meanwhile, our contemporary digital environment is running rife with disempowerment. The reigning pattern of "privacy by promise" in walled-garden platforms has a dramatic chilling effect on the internet. And from a development standpoint, since every new social application is forced to build its own platform infrastructure, this approach comes with tremendous economic cost.

Golix consolidates content, sharing, and identity management into a single encrypted protocol. It allows social applications to focus on social utility, and frees their distribution platforms from arduous and repetitive account management and authentication concerns. It is encrypted from participant to participant and supports arbitrary content with asynchronous availability. The Golix protocol is a paradigm shift: it represents an attempt to algorithmically protect individual agency in a digital world.


text:
**WARNING:** This is a draft document dated May 2016. It is under review and is definitely not finalized. If you'd like to stay updated, consider joining the [Hypergolix mailing list](https://www.hypergolix.com/#page-top).

# Introduction

If Web 2.0 has been defined by the rise of the social internet, Web 3.0 will surely include the connected physical devices now being dubbed the "Internet of Things". Like its predecessors, the Internet of Things (IoT) will include and build upon the past. The emergence of social applications with physical components (currently these predominantly involve video sharing) attests to the importance of continued sharability. But a generally-accepted security solution for IoT has yet to materialize; and sites like Shodan -- which includes a search engine for vulnerable video feeds -- are yet another indication that this need is dire.

However, IoT security imposes substantially different challenges than Web 2.0. Broadly speaking there are two primary possible approaches, given existing best practices:

1. Issue certificates for each connected device, allowing end-to-end security
2. Issue certificates for a central server, requiring full trust in its owner

Even conservative growth estimates for IoT would imply that the first option, if pursued through existing certificate authority, would require orders of magnitude more certificates to be issued for IoT devices than in the entire previous history of the internet. Eschewing the certificate authorities might be possible, but with potentially dynamic IP addresses on both ends of the connection, sharability and reachability would remain substantial problems. And the second approach ultimately entails trusting companies with Facebook with access to internet-connected baby monitors. Clearly, neither option is particularly attractive.

An alternative approach would be to force end-to-end encryption of all IoT information, and implement a new addressing mechanism to communicate socially between devices. This would allow centralized, auditable services to concentrate transport-level security certificates without granting them access to data. This is an enticing compromise; however, with the requirement of scalable sharability, and more immediate constraints like dynamic data streams, existing protocols like PGP cannot fill this need.

Golix is a cryptgraphic protocol designed to fill this void. It allows for both asynchronous delivery and asynchronous sharing, making scalable encryption of data at rest possible even for highly-dynamic social systems. Critically, it requires no trust in a centralized server to achieve confidentiality of transferred data.

# Threat model

Golix protects the informational autonomy of an abstract digital ```entity-agent``` comprised of three public/private keypairs. That is to say, the Golix protocol affords these ```entities``` strict and exclusive control over:

1. creation,
2. retention,
3. and sharing

of any and all information ```possessed``` by the ```entity-agent```. Note that Golix does not include any concept of information ownership or intellectual property. Within a Golix context, information ```possession``` means only that an agent-entity retains that particular piece of information. As such, once information is shared, **the sharer's authority over the information stops at the point of share;** the recipient has explicit autonomy over their digital "memory" of that information, as does the sharer.

To enforce such agency cryptographically, Golix protects:

+ information *confidentiality* against ```illegitimate access``` by any adversary,
+ information *integrity* against deliberate or incidental modification by any adversary, and
+ information *authenticity* of authorship against impersonation by any adversary.

However, Golix provides only limited protections:

+ against meta-analysis of Golix data or traffic,
+ against flooding ```entities``` with requests, effectively (D)DoSing them, and
+ against malicious information retention or removal.

And Golix protections explicitly exclude:

+ any compromise of the underlying cryptographic primitives used by the protocol,
+ any compromise of ```entity``` (client) devices, and
+ any connection between physical entities and Golix ```entities```.

The following discusses what specific capabilities are afforded to various adversaries. Each capability builds upon (and includes) the previous category.

## *Any* adversary can...

Cryptographic compromises:

+ Use a collision of the address hash algorithm to tamper with existing information
+ Use a break of the signature algorithm to impersonate an ```entity``` in the future
+ Use a break of the public key encryption algorithm to intercept future key exchanges and compromise stored past key exchanges
+ Use a break of the symmetric encryption algorithm to expose the plaintext of past and future objects
+ Use a break of the exchange algorithm to impersonate an alias of an existing ```entity``` in the future
+ Use a break of the KDF algorithm to impersonate an alias of an existing ```entity``` in the future
+ Use a break of the exchange algorithm to forge key exchanges in the future
+ Use a break of the MAC algorithm to forge key exchanges in the future
+ Use a break of the KDF algorithm to forge key exchanges in the future

Client compromises:

+ Use a compromised client device to fully impersonate the client ```entity```
+ Use a compromised client device to gain access to the client ```entity``` private keys
+ Use a compromised client device to gain access to any client-stored content symmetric keys

Meta-analyses:

+ Tie any piece of information to exactly one ```entity```: typically the ```entity``` that created the information, but occasionally the ```entity``` that received it
+ Calculate the exact, or near-exact, length of confidential information

Denials of service:

+ Flood a ```persister``` server with *traffic*
+ Flood a client device with *messages*

## An ```entity``` (*client*) adversary can...

Denials of service:

+ Flood a ```persister``` with *messages*

Denials of availability:

+ Maliciously prevent deletion of arbitrary data
+ Maliciously delete possessed data

## A ```persister``` (*server*) adversary can...

Meta-analyses:

+ Analyze connection traffic to infer connections between a Golix ```entity``` and its viewed ```GHID```s
+ Analyze connection information to infer physical identity, IP address, probable time zone, etc

Denials of service:

+ Maliciously take itself offline
+ Flood a client device with traffic

Denials of availability:

+ Maliciously delete arbitrary data
+ Maliciously retain arbitrary data

## A *global passive* adversary can...

Meta-analyses:

+ Analyze traffic on the transport level to tie Golix ```entities``` to physical identities
+ Analyze traffic on the transport level to infer connections between multiple Golix ```entities```

## *No* adversary can...

Client compromises:

+ No adversary can directly escalate one client compromise into another client compromise.

Meta-analyses:

+ No adversary can perform social graph analysis of ```entities```.
+ No adversary can tie object ```recipient``` entities with object ```author``` entities
+ No adversary can deduce content types, content format, or any other content metadata, without access to the content itself

# Golix overview

## Identities

Creating Golix content requires an ```identity```. This ```identity``` is used primarily for:

1. data authorship (as metadata)
2. data retention "binding" (as metadata)
3. data sharing (as a sharing endpoint)

These ```identities``` require the ability to asymmetrically sign data, receive asymmetrically encrypted data, and perform symmetric key agreement. To divide the requirements of these three separate operations, and to minimize the damage of a break against the underlying cryptographic primitives, a separate key is used for each. As such, each ```identity``` comprises of exactly three public keys:

1. The signature key, used for signing and verifying data
2. The encryption key, used to encrypt and decrypt keyshares to the identity
3. The exchange key, used for key agreement in explicitly one-to-one operations

It is crucial to note that a Golix ```identity``` has no explicit link to any physical entity. Since there are no restrictions on the creation of new ```identities```, it is therefore very important to draw a distinction between the actual capabilities of a Golix ```identity```, and those that might be expected of a physical entity. In particular, note that though the digital Golix ```entity``` explicitly lacks content deniability, a physical entity retains the ability to repudiate any links to the Golix ```identity```. Similarly, though Golix assures consistent authentication of data, it makes no claims surrounding an ```identity```'s authorization to view that data, or of any verification of that ```identity```'s claimed physical counterpart. Put simply: with Golix, deniability is wholly different from repudiation; and authentication wholly different from authorization or verification.

Furthermore, as a result of content's dynamic sharability, and the distributed, highly-asynchronous nature of social graphs, it is preferable to use long-term keypairs instead of short-term ephemeral keys: the enormous added complexity of a key update mechanism simply cannot justify the correspondingly modest gains in forward secrecy.

## Addresses

An unambiguous reference to Golix objects is critical for network operation. However, as Golix is intended to be capable of cross-server federation *without breaking addressability*, traditional URL schemes are insufficient. Furthermore, URLs have no inherent relationship with the content they represent, which results in a complicated trust relationship between URL owner and content consumer. To avoid this entirely, Golix makes use of a static, deterministic address scheme. Put simply, absolutely every Golix object is addressed by its cryptographic hash digest. This address is termed the "Golix hash identifier" or ```GHID```.

The use of hashes as an address mechanism ensures that, provided the underlying hash algorithm remains cryptographically secure, all Golix content is fundamentally non-malleable; that is to say, once created, content cannot be altered by **any** party, deliberately or accidentally. It also bears explicit mentioning that the address is constructed in an **encrypt-then-hash** order, and as such protects the confidentiality of encrypted containers from compromises and attacks of the underlying hash function.

That being said, it is obviously often useful to treat multiple sequential pieces of static content as a single dynamic object. Given a thermometer, for example, though every individual temperature reading is inherently static, the room's temperature is not. To relate the static content to dynamic concepts, Golix allows ```entity-agents``` to bind a secondary address to changing content. That way, this "dynamic" or "portable" ```GHID``` may be used to refer to changing content with an unchanging address. The security properties of this reference are discussed within the Dynamic Binding object type below.

## Example exchanges

Preface:

1. Golix "clients" are ```identities```, and "servers" are ```persistence providers```. However, these ```identities``` and ```persistence providers``` have no direct, explicit relation to individual devices: a ```persister``` may in fact be a cloud services provider, and the ```identity``` may be simultaneously used on multiple devices.
2. There are no restrictions placed on distribution of content *in encrypted form*. Any **device** may request any Golix resource, and the ```persister``` will deliver it. Sessions between **devices** and ```persisters``` are wholly ephemeral, and any session state will always be destroyed upon disconnection. Any stateful operations must be maintained by the device client, or from within Golix objects (and therefore referencing Golix ```identities```).

Content creation:

1. An ```identity``` is initially created on the client device, and then uploaded to a ```persister```'s server(s).
2. The ```identity``` creates content within an encrypted object container
3. The ```identity``` creates a static (and/or dynamic) object binding for that container *prior to uploading the content*. This binding prevents garbage collection of the actual object, analogously to a memory-managed programming language.
4. The client device uploads the bindings to the ```persister```'s server(s).
5. The client device uploads the object container to the ```persister```'s server(s).

Content removal:

1. An ```identity``` with an existing binding creates a debinding. An ```identity``` may only remove their own bindings.
2. The client device uploads the debinding to the ```persister```'s server(s). Once validated, this clears the binding, dereferencing the original object.
3. If the original object reference count has reached zero, the object is deleted by the ```persistence provider```.
4. If the reference count is greater than zero, the client device may request a list of ```identities``` preventing the object's deletion.

Sharing content:

1. An ```identity``` creates a handshake request. Unlike other objects, which include a public reference to their *creator*, the handshake request includes a public reference to its *recipient* and a **private** reference to its creator. The handshake request also references the object to share, and includes its symmetric key.
2. The sharer's client device uploads the handshake request to the ```persister```'s server(s).
3. If another connection at the ```persistence provider``` has already subscribed to the recipient ```identity```'s ```GHID```, then that device is notified of the request.
4. Any subsequent new ```persister``` connections subscribing to the recipient ```identity```'s ```GHID``` are also notified of the handshake, until it is removed.
5. The recipient ```identity``` removes the request by debinding it. The recipient may also respond to the request with an acknowledgment (or non-acknowledgment) of success, by repeating the process in reverse, referencing the handshake request's ```GHID``` instead of the original object, and omitting the key.

# Golix network primitives

Golix network primitives comprise all stateful objects on Golix ```persisters```. Any other traffic between a client device and a ```persister``` server is ephemeral.

## Identity container (```GIDC```)

Identity containers combine a Golix ```entity```'s three public keys, permanently tying them together with a single static address. Identity containers are not intended to be removable from ```persisters``` and are therefore not subject to replay attacks.

Identity containers are the concatenation of:

1. Magic number
2. Version number
   Note: The version number is specific to each Golix primitive type.
3. Cipher suite designation
   Note: the cipher suite designation is an integer that corresponds to a combination of algorithms defined within the Golix spec.
4. **Signature public key**
5. **Encryption public key**
6. **Exchange public key**
7. **Resultant ```GHID```**
   Note: the hash digest includes all of the previous bytes in the file, including the hash algorithm definition.
    1. Hash algorithm
    2. Hash digest

## Object container (```GEOC```)

Object containers are used to store **all** application content on Golix ```persisters```, tying it to static addresses. They are analogous to the data encapsulation schemes used by hybrid cryptosystems, but are wholly separate from key encapsulation and distribution. Because their retention lifetimes at ```persisters``` are wholly dictated by bindings, they are not subject to replay attacks.

Object containers are the concatenation of:

1. Magic number
2. Version number
3. Cipher suite designation
4. **Author's ```GHID```**
   Note: author ```GHID```s are the resultant ```GHID``` from the author's identity container (GIDC).
5. Payload length
6. **Symmetrically encrypted payload:**
   ```{``` ```Arbitrary bytes``` ```}```
7. **Resultant ```GHID```**
    1. Hash algorithm
    2. Hash digest
8. **Author's signature**
   Note: the author signs only the bytes composing the hash digest in the ```GHID```. She does not sign the entire ```GHID```.

## Static object binding (```GOBS```)

Static bindings prevent object garbage collection, reusing the object's original ```GHID``` for addressing (*ie* the target object is referenced directly, and not by the static binding's resultant ```GHID```). Note that, because they can be removed by their creator, they **are** potentially subject to replay attacks. As such, any debinding must be retained by the ```persister``` until and unless that debinding itself is debound. See "Persister state analysis" below for more details.

Static bindings are the concatenation of:

1. Magic number
2. Version number
3. Cipher suite designation
4. **Binding author's ```GHID```**
5. **Binding target's ```GHID```**
   Note: similarly to author references, target references refer to the resultant ```GHID``` of the object container (GEOC) being bound.
6. **Resultant ```GHID```**
    1. Hash algorithm
    2. Hash digest
7. **Binding author's signature**

## Dynamic object binding (```GOBD```)

**Note: the GOBD diagram is out-of-date; see description below.**

Dynamic bindings also prevent object garbage collection, while also creating a secondary proxy address for whatever object is currently referenced by the binding. Like static bindings, they are potentially subject to replay attacks, and must follow the same mitigation process. See "Persister state analysis" below for more details.

Dynamic bindings are the concatenation of:

1. Magic number
2. Version number
3. Cipher suite designation
4. **Binding author's ```GHID```**
5. **Monotonic counter for binding frame indexing**
   Note: the frame index monotonic counter is responsible for replay protection on dynamic bindings. They are zero-indexed. Persistence servers must reject any index smaller than the index currently existing at the server.
6. Target vector length
7. **Target vector ```GHID``` list**
   Note: a most-recent-first sorted list of target GHIDs. The first GHID in the list is the current target. The target vector applies to only this particular frame.
8. **Resultant ```GHID```**
   Note: the first GHID in the dynamic binding is the "dynamic" or "portable" GHID. It is defined only once -- upon finalizing the first frame of the binding. This GHID may be used as a proxy address for the most current target of the binding. Like any other GHID, it is defined as the hash digest of the entire preceding file.
    1. Hash algorithm
    2. Hash digest
9. **Resultant ```GHID```**
   Note: the second GHID in the dynamic binding is the "static" or "frame" GHID. It is re-defined every time the binding is updated based upon the current content of the binding. It is used primarily as a reference point for the historical frame list.
    1. Hash algorithm
    2. Hash digest
10. **Binding author's signature**

## Debinding (```GDXX```)

Debindings remove existing bindings, reducing their reference count and eventually freeing them for garbage collection. They may also remove existing debindings, allowing previously removed objects to be rebound and reuploaded to the ```persister```. Like bindings, they are subject to replay attacks, and so their debindings must be retained by the ```persister``` until they themselves are debound. This creates a debinding chain, the length of which will increase after every upload/delete cycle. See "Persister state analysis" below for more details.

Debindings are the concatenation of:

1. Magic number
2. Version number
3. Cipher suite designation
4. **Debinding author's ```GHID```**
5. **Debinding target's ```GHID```**
6. **Resultant ```GHID```**
    1. Hash algorithm
    2. Hash digest
7. **Debinding author's signature**

## Asymmetric request/response (```GARQ```)

Asymmetric requests share an object with a recipient, or reply to an attempted share. They are analogous to the key encapsulation component of a hybrid cryptosystem such as PGP, but wholly separated from the data encapsulation, which is implemented by object containers. Unlike most Golix primitives, their author is not publicly available; instead, they are associated with their intended recipient, and encrypted against the recipient's public encryption key, as defined by the recipient's identity container. This results in full verification being only possible by the recipient; see "Entity state analysis" below for more details. They are removed via debinding by their recipient. A request replay attack is not particularly meaningful, but would result in ```persister``` congestion, and as such their debindings are subject to the same retention process as bindings and debindings. See "Persister state analysis" below for more details.

Asymmetric requests are the concatenation of:

1. Magic number
2. Version number
3. Cipher suite designation
4. **Request recipient's ```GHID```**
5. **Asymmetrically encrypted payload:**
   ```{``` ```Author GHID``` ```||``` ```Target GHID``` ```||``` ```<Keyshare>``` or ```<ACK>``` or ```<NAK>``` ```}```
6. **Resultant ```GHID```**
    1. Hash algorithm
    2. Hash digest
7. **Request author's ```MAC```**
   Note: here, both the MAC algorithm and the key agreement process are defined by the cipher suite designation. For reference, with CS-0x1 it is an HMAC performed with the key from a Diffie-Hellman exchange between the Author's and Recipient's exchange keys. This process must be carefully chosen to prevent an attacker from checking the signature against all known identities to unmask the author.

# State analysis

The criteria for acceptance or non-acceptance of Golix primitives is identical for all primitives except the asymmetric request. The request verification process varies based on the role of the verifier: the recipient ```entity```, which has privileged access to the private contents of the request, is the only party that can validate the origin and authenticity of the request. In all other cases, Golix primitives can be verified using only public information.

## ```Persister``` ("server") state analysis

As ```persisters``` are non-privileged data retention services, they can only verify Golix primitives based on their public information.

### Identity container (```GIDC```)

Identity containers must be accepted by the ```persister``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + Verify valid signature public key
    + Verify valid encryption public key
    + Verify valid exchange public key
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify EOF reached

![GIDC verification diagram](assets/operations-verify-gidc.png)

### Object container (```GEOC```)

Object containers must be accepted by the ```persister``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + Author retrieval
        1. Verify author exists at persistence provider
        2. Retrieve author's identity file
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify signature
6. Verify EOF reached

![GEOC verification diagram](assets/operations-verify-geoc.png)

### Static object binding (```GOBS```)

Static bindings must be accepted by the ```persister``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + GOBS status check: verify no debinding exists for the binding's resultant ```GHID```
    + Binder retrieval
        1. Verify binder exists at persistence provider
        2. Retrieve binder's identity file
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify signature
6. Verify EOF reached

![GOBS verification diagram](assets/operations-verify-gobs.png)

### Dynamic object binding (```GOBD```)

Dynamic bindings must be accepted by the ```persister``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + GOBD status check: verify no debinding exists for the binding's dynamic ```GHID```
    + GOBD consistency check:
        + if dynamic address **does not exist** at persistence provider **and** its counter is zero...
            1. Verify dynamic address algorithm
            2. Verify dynamic hash
        + elif dynamic address **does not exist** at persistence provider (but its counter is nonzero)...
            1. Dynamic address cannot be validated in this case. Optionally, the server *may* reject the binding, but *should* accept it.
        + else (binding exists and counter is nonzero):
            1. Verify existing binder matches uploaded binder
            2. Verify the frame index (the counter) increased
            3. Optionally, detect resource contentions by comparing target vector ```GHID```s after aligning them by the frame index
    + Binder retrieval
        1. Verify binder exists at persistence provider
        2. Retrieve binder's identity file
    + Digest remaining file
        1. Verify frame address algorithm
        2. Verify frame hash
5. Verify signature
6. Verify EOF reached

![GOBD verification diagram](assets/operations-verify-gobd.png)

### Debinding (```GDXX```)

Debindings must be accepted by the ```persister``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + GDXX status check: verify no debinding exists for the debinding's resultant ```GHID```
    + GDXX reference check
        1. Verify target GHID exists at persistence provider
        2. Verify debinder GHID matches binder GHID (for GOBS, GOBD, GDXX) or recipient GHID (for GARQ)
    + Binder retrieval
        1. Verify binder exists at persistence provider
        2. Retrieve binder's identity file
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify signature
6. Verify EOF reached

![GDXX verification diagram](assets/operations-verify-gdxx.png)

### Asymmetric request/response (```GARQ```)

Asymmetric requests must be accepted by the ```persister``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. (The following steps may be done in parallel)
    + Verify recipient exists at persistence provider
    + Digest remaining file
        1. Verify address algorithm
        2. Verify file hash
5. Verify EOF reached

![GARQ persister verification diagram](assets/operations-verify-garq_server.png)

## ```Entity``` ("client") state analysis

```Entities``` should independently verify all state analyses performed by the ```persister```. They should also perform additional privileged verification of the asymmetric request/response primitive.

### Asymmetric request/response (```GARQ```)

Asymmetric requests must be accepted by the ```entity``` if and only if the following procedure terminates successfully:

1. Verify magic number
2. Verify version
3. Verify cipher suite
4. Digest remaining file
    1. Verify address algorithm
    2. Verify file hash
5. Verify EOF reached
6. Decrypt payload
7. Author verification
    1. Verify author exists
    2. Retrieve author's identity file
8. Perform symmetric signature key agreement procedure (see Appendix B below)
9. Verify author symmetric signature

**Note that for the recipient, rejection should imply an immediate debinding of the GARQ,** optionally accompanied by a NAK response to the request's author, sent by a responding (second) GARQ.

![GARQ recipient verification diagram](assets/operations-verify-garq_client.png)

# Conclusion

Because all Golix content is encrypted, it can be distributed freely, without regard to access credentials -- or, in a practical and immediate sense, with complete disregard to any session information. Though this renders the security of Golix information wholly dependent upon the protocol itself, such a relationship is, realistically speaking, already a practical reality for the vast majority of contemporary internet traffic via TLS.

By embracing encryption as the sole source of confidentiality and treating all information as private by default, and then separating cryptographic content access from transactional content delivery, Golix effectively reduces the problem of access-restricted social sharing to the far simpler task of key encapsulation and distribution. In so doing, Golix allows centralized or federated servers to be used for asynchronous object persistence, without relying on them for an expectation of secrecy.

These Golix ```persisters``` use Golix ```identities``` to distinguish ephemeral connection verbs (like address subscription and object retrieval) from state-mutating verbs (object creation or sharing). By forcing all mutating requests to use Golix primitives, Golix ```persisters``` can limit all connections to either ephemeral, nullipotent requests (ex: get, subscribe), or a single state-mutating request (publish). Furthermore, as all Golix content is hash-addressed, publishing a Golix primitive to a ```persister``` is guaranteed idempotent.

In many ways, the critical insight of Golix is this *bidirectional* minimization of trust between client and server. Clients need not trust servers for confidentiality, and servers need not trust clients for authentication. Both clients and servers, operating in their capacities as ```entities``` and ```persisters``` respectively, are able to function independently. Provided the Golix primitives pass validation on the server, the ```persister``` is assured of authorized content, and provided the primitive is constructed properly on the client, the ```entity``` is assured of confidentiality.

This strict division of concerns is especially advantageous to the emerging Internet of Things, where traditional trust infrastructure does not map well to its forecasted hyper-exponential growth. Importantly, it maintains the dynamic sharability that has become a hallmark of the social web, clearing the way for easy integration of these networked physical devices with a diverse range of social applications.

# Appendix A: Glossary

## GHID

The "Golix hash identifier": a unique content-based static address for content on a Golix-compliant network or device.

## Entity-agent

An abstract digital entity represented by three linked public/private keypairs and a ```GHID```. Also informally referred to as an agent, entity, or identity. Entity-agents are the Golix equivalent of a single consistent consciousness. **The Golix protocol does not inherently relate Golix entities with physical entities.** Any such connection must be made by applications.

## Possession

Within a Golix context, information possession is wholly unrelated to information authorship or any notion of intellectual property. Here, to possess information means only that a particular entity-agent retains it.

## Illegitimate access

The access of information by any party with whom that information has not been affirmatively, explicitly shared. This party is an arbitrary adversary, who is not limited to attacks within the Golix protocol.

## Persistence providers

The servers that physically store Golix data. Also referred to as persisters, persistence, and occasionally (and highly informally) servers.

# Appendix B: Cryptographic primitives

## Ciphersuite ```0x1```

+ **Asymmetric signature:** RSASSA-PSS, MGF1+SHA512, public exponent 65537. Salt length 64 bytes.
+ **Asymmetric encryption:** RSAES-OAEP, MGF1+SHA512, public exponent 65537.
+ **Symmetric encryption:** AES-256 in CTR mode. Nonce distributed privately, with the key.
+ **Symmetric shared secrets:** ECDH over Curve25519.
+ **Key agreement from shared secret:** HKDF+SHA512. Salt with bitwise XOR of the the address components of the two parties' GHIDs.
+ **```GARQ``` MAC:** HMAC+SHA512

### Key/nonce serialization

The serialization of the AES-CTR nonce and key (which are contained within asymmetric ```GARQ``` primitives) is as follows:

| Offset | Length    | Name                       | Format                         |
| ------ | --------- | -------------------        | -----------                    |
| 0      | 2B        | Magic number               | ASCII "```SH```"               |
| 2      | 2B        | Key servialization version | Unsigned 16-bit int            |
| 4      | 1B        | Cipher suite identifier    | Unsigned 8-bit int: ```0x01``` |
| 5      | 32B       | Key                        | Bytes                          |
| 37     | 16B       | Nonce                      | Bytes                          |

Note: the current secret serialization version is 2.

### Full ```GARQ``` MAC procedure

From a resultant GHID ```rGHID``` that was already calculated during request creation, MAC calculation (which uses the recipient's and author's ```exchange keys```, is performed as follows:

```
ghidA = bytes(65)
addrA = ghidA[0:1] = 0x01
saltA = ghidA[1:65]

ghidB = bytes(65)
addrB = ghidA[0:1] = 0x01
saltB = ghidA[1:65]

salt = saltA XOR saltB
shared = ECDH(KA, KB)
key = HKDF-SHA512(shared, salt)

A → B: HMAC-SHA512(key, rGHID)
```

![MAC generation diagram](assets/operations-mac-cs1.png)

repo_name: Muterra/doc-golix

mime_type: text/plain


text:
# How does Golix work?

This outlines, from first principles, the protocol design decisions that lead to Golix. This does not justify our answers -- for that, read our [whitepaper](/whitepaper.md). However, it does explain the entire protocol architecture.

1. **Problem:** What is content?
   **Solution:** Content is any arbitrary binary data. All content is encapsulated within containers that assure confidentiality, integrity, and authenticity.

    1. **Problem:** How does an agent assure confidentiality?
       **Solution:** Encrypt the container content.

        1. **Problem:** How should content be encrypted?
           **Solution:** It's of arbitrary length, so definitely symmetrically (as per usual!)
        2. **Problem:** How does another agent access the encrypted file in a many-to-many network?
           **Solution:** Use a *separate* key-sharing mechanism (see below).

    2. **Problem:** How does an agent assure integrity?
       **Solution:** They hash the encrypted container.
    3. **Problem:** How does an agent assure authenticity?
       **Solution:** They asymmetrically sign the container hash.
    4. **Problem:** How is the content identified on the network?
       **Solution:** All containers are deterministically and uniquely content-addressed. In other words, content is identified by a collision-resistant cryptographic hash.
    5. **Problem:** How can this data be made asynchronously-available?
       **Solution:** Any Golix-implementing network requires a persistence system. These are transport-specific. A conformant physical network node stores data on agents' behalf(s). Nodes may also bridge between transport-specific Golix implementations to automatically sync network state between them. Uploading is implicit, and the persistence system must understand several commands defined within the Golix spec.

        1. **Problem:** What commands must a persistence system accept?
           **Solution:** Publish, get, subscribe, unsubscribe, ack, nak, list node subscriptions, list object binders.
        2. **Problem:** How are these persistence systems standardized?
           **Solution:** Each particular transport mechanism defines its own overlay standard for command format.

    6. **Problem:** How does the persistence system know to retain data?
       **Solution:** Agents bind addresses to objects, reminiscent of a "call-by-assignment" programming language. Bindings may be created by any agent, regardless of data authorship. This prevents problematic deletion. Objects are always static, but bindings may also be dynamic (which creates a secondary address).

        1. **Problem:** How does the persistence system know when to remove data?
           **Solution:** When all bindings have been removed through "debind" commands, the persistence system garbage collects the object.
        2. **Problem:** How can an author-agent remove undesired content that has been bound by a different agent?
           **Solution:** Binding records include the binding agent as public metadata. Persistence systems must include a command to list the agents who have bound to a particular piece of content. The author may then exert social/political/legal pressure on those binders for them to remove the binding.

2. **Problem:** What is sharing?
   **Solution:** An exchange of symmetric encryption keys.

    1. **Problem:** How is this accomplished in a many-to-many network?
       **Solution:** Separate the key exchange from the content itself. Content is uniquely and trivially addressable, and access is shared one-to-one between agents. Note that agents may be computational, so public information may be automatically shared across communities of any size.
    2. **Problem:** How do you perform secure online key exchange?
       **Solution:** Initially, through a special asymmetrically-encrypted handshake object. These are distributed like any other Golix content, but contain a public reference to their agent-target. Unlike standard objects, their author is only named privately, within the container body.
    3. **Problem:** Doesn't this hinge on the secrecy of the target's asymmetric private key? Can we get forward secrecy, etc?
       **Solution:** Absolutely. The handshake object *could* be used directly for every key exchange, but that would be both insecure and inefficient. The preferred method is to use the handshake to bootstrap a dynamic bidirectional communication pipe between two agents, and then use that for key exchange. The API definition for that key exchange pipe is out-of-scope for Golix itself, but candidates will be defined within overlay standards. Because it is encapsulated within the Golix symmetric pipe, it can be any binary message format.

3. **Problem:** What is an agent?
   **Solution:** An agent produces, accesses, shares, or retains content.

    1. **Problem:** An agent must be uniquely identifiable and network-available.
       **Solution:** Put the agent's entire identity within a single, standard content container on the network. Use their identity container's content address as their unique identifier.
    2. **Problem:** The agent requires an asymmetric public key for signing content.
       **Solution:** Add that key to the container file.
    3. **Problem:** The agent requires an asymmetric public key for receiving encrypted pipes.
       **Solution:** Add that key to the container file.
    4. **Problem:** How does an agent invisibly (to external parties) transition to a new identity?
       **Solution:** Through a Diffie-Hellman-based identity exchange process.

        1. **Problem:** Can this transition be made selectively deniable?
           **Solution:** Yes, through clever sequencing of the exchange.
        2. **Problem:** How does an agent perform this exchange online?
           **Solution:** The DH public key must be made available at the time of identity creation, and is therefore stored with the rest of the identity's public keys (aka: add it to the container file).

    5. **Problem:** Agents are meant to exist independently of physical devices, so they need online private key storage.
       **Solution:** Out-of-scope, but defined within an overlay protocol.
    6. **Problem:** How does the agent independently discover new content addresses?
       **Solution:** Out-of-scope.


text:
# Current revision: 29 March 2016

+ Changed dynamic bindings to use monotonic counter for replay protection and frame indexing, instead of a hash chain of frame GHIDs.
+ Changed dynamic bindings to use a target vector instead of current target and history separated
+ Updated dynamic binding version to 16
+ Updated spec and security whitepaper to reflect the change (however, GOBD diagramming still needs revision)

# Previous revisions

## 29 March 2016, #edfd65e

+ Clarified use of dynamic binding historical frames
+ Removed support for multiple targets in dynamic bindings; incremented version accordingly.
+ Updated debindings to be stateless; incremented version accordingly.
+ Explained debinding chains
+ Added salt definition in key agreement
+ Clarified requested GHID and author/recipient in asymmetric requests.
+ Clarified valid targets for static, dynamic bindings
+ Changed "pipe request" to "pipe handshake" to differentiate from "asymmetric request"
+ Potential deprecation warning in ciphersuite 2
+ Removed optional ghid request in persistence provider pings, and clarified several responses to/from persistence providers.
+ Added "query debinding" persistence provider command
+ Modified behavior of "list bindings" persistence provider command to return the binding ghids instead of their authors
+ List bindings (the persistence provider command) now has a specified order.

## 28 Feb 2016, #8b925e8

+ Rebranded Muse -> Golix. No version changes as a result, though. Corrected some minor glaring errors in the process, and noted some things in the spec as deprecated (but did not redocument them yet).
+ Added text explicitly forbidding dynamic binding to anything other than a static GEOC
+ Fixed overlooked update in GDXX record re: chain count vs chain length. Updated version accordingly.
+ Changed pipe request identifier to ASCII "RQ"

## 27 Feb 2016, #6aff066

+ Updated dynamic binding to remove support for multiple identical start points, and removed old wording surrounding random seed for that purpose. Upped version number accordingly.

## 26 Feb 2016, #4bf3e65

+ Reorganized spec documentation to list cipher suites and address algos first
+ Added dedicated identity container (GIDC)
+ Added ancillary format for secret sharing

## 20 Feb 2016, #e27e7bf

+ Major readme revision for better expressibility
+ Removed shameless plugs
+ Switched numeric identification of ciphersuites 1 and 2 in preparation for possible removal of SIV mode
+ Changed lengths of any GHID lists into absolute lengths, to ease support of potential future address algorithms of different lengths. Updated version numbers accordingly.
+ Moved all of the asymmetric operations into a single primitive (GARQ) with differing payloads. Added another payload definition for arbitrary content, to support future protocol development.
+ Clarified available size of asymmetric payload and appropriateness of use
+ Changed all secondary file extensions to .ghid and tertiary to object identifiers (ex .geoc)
+ Added support for different static/dynamic address algorithms in dynamic binding

## 18 Jan 2016, #4fcba8f

+ Clarified spec re: salt length in signature (should match hash length = 64 bytes)
+ Added some shameless plugs

## 11 Dec 2015, #9a6e2ff

+ Changed all DH from 2048-bit/Group #14 to ECDH/Curve25519
+ Changed external links to reflect muterra.io and ethyr.net reorganization

## 13 Nov 2015, #10d6a60

+ Removed deterministic nonce generation in spec
+ Changed cipher suite 0x1 to SIV mode with MAC prepended to ciphertext in spec
+ Added cipher suite 0x2 as CTR mode with nonce accompanying key distribution in spec
+ Added important questions to top of readme

## 10 Nov 2015, #83eb7e5

Initial draft release.