"""
= The Nano peer-to-peer protocol
Since users encrypt their requests and responses to each other, the server cannot partake in the message exchange aside
from complying with transmission and caching requests. For this reason the communication between the clients and the
nanos have to be designed without relying on much help from the servers.

== Request authentication
The payload of a request will be encrypted with authenticated encryption and it may also be signed digitally. The
server will include the requesting account's id as request metadata so the nano is able to look up keys and permissions
for evaluation. The server cannot forge requests, falsifying or omitting an account id will explicitly show either the
lack of cooperation of the server or the client (if they supply incorrectly encrypted payloads).

== Extensibility
Request processing will be determined by the type of the request. All requests must include their type. Processing must
be denied if there is no handler for the type or some type specific conditions are not fulfilled by the request.

== Stateful and multi-request procedures
While a response to a request may be arbitrarily large from the perspective of the requester as the response streaming
supports chunked transport, requests have no equivalent feature on transport level. The handlers that need to process
large incoming data must manage the state of that data and the chunking on their own. (file-upload typically) The
chunking of responses is also required as appropriate.

== Caching and encryption of response
The handlers must choose the appropriate options by the request. The gateway will always provide information on the
privacy settings of the server with encryption keys to use. Only requests that can be shared for multiple users *if*
they ask for it may be cached and thus encrypted with a group key.

"""