Server and Development Stubs.

src/SUMMARY.md

@@ -5,4 +5,9 @@
 - [Connectivity](./connectivity.md)
 - [Tapir](./tapir.md)
 - [Cwtch Library](./cwtch.md)
+    - [Groups](./groups.md)
 - [Cwtch UI](./ui.md)
+- [Cwtch Server](./server.md)
+- [Development](./development.md)
+- [Deployment](./deployment.md)
+

src/deployment.md

@@ -0,0 +1 @@
+# Deployment

src/development.md

@@ -0,0 +1,38 @@
+# Development
+
+The main process to counter malicious actors in development of Cwtch is the 
+openness of the process.
+
+To enhance this openness, automated builds, testing and packaging are defined
+as part of the repositories - improving te robustness of the code base at every
+stage.
+
+While individual tests aren't perfect, and all processes have gaps, we should be
+committed to make it as easy as possible to contribute to Cwtch while also
+ building pipelines and processes that catch errors (unintential or malicious)
+ as soon as possible.
+
+### Risk: Developer Directly Pushes Malicious Code
+
+**Status: Mitigated**
+
+Master is currently locked and 3 Open Privacy staff members have permission
+to override it, and the responsibility of monitoring changes.
+
+Further every new pull request and merge triggered automated builds & tests
+ which trigger emails and audit logs.
+ 
+The code is also open source and inspectable by anyone.
+
+### Risk: Code Regressions
+
+**Status: Partially Mitgated** (See individual project entries in this
+ handbook for more information)
+ 
+Our automated pipelines have the ability to catch regressions when that
+ behaviour is detectable.
+ 
+The greatest challenge is in defining how such regressions are detected for the
+[ui](./ui.md) - where behaviour isn't as strictly defined as it is for the
+ individual libraries.
+ 

src/groups.md

@@ -0,0 +1 @@
+# Groups

src/server.md

@@ -0,0 +1,79 @@
+# Cwtch Server
+
+The goal of the Cwtch protocol is to enable group communication through
+**Untrusted Infrastructure**.
+
+Unlike in relay-based schemes where the groups assign a leader, set of
+ leaders, or a trusted third party server to ensure that every member of the
+ group can send and receive messages in a timely manner (even if members are
+ offline) - untrusted infrastructure has a goal of realizing those properties
+  without the assumption of trust.
+  
+The orignal Cwtch paper defined a set of properties that Cwtch Servers were
+expected to provide:
+
+*  Cwtch Server may be used by multiple groupsor just one.
+* A Cwtch Server, without collaboration of a group member, should
+  never learn the identity of participants within a group.
+* A Cwtch Server should never learn the content of any communication.
+* A CwtchServer should never be able to distinguish messages as belonging
+  to a particular group.
+  
+We note here that these properties are a superset of the design aims of Private
+Information Retrieval structures.
+
+## Malcious Servers
+
+We expect the presence of malicious entities within the Cwtch ecosystem.
+ 
+We also prioritize decentralization and permissionless entry into the
+ ecosystem and as such we do not base any security claims on the following:
+
+* Any non-collusion assumptions between a set of Cwtch servers
+* Any third-party defined verification process
+
+Peers themselves are encouraged to set up and run Cwtch servers where they can
+guarantee more efficient properties by relaxing trust and security
+ assumptions - however, by default, we design the protocol to be secure without
+ these assumptions  - sacrificing efficiency where necessary.
+ 
+### Detectable Faults
+
+* If a Cwtch server fails to relay a specific message to a subset of group
+ members then there will be a detectable gap in the message tree of certain
+ peers that can be discovered through peer-to-peer gossip.
+* A Cwtch server cannot modify any message without the key material known to
+the group (any attempt to do so for a subset of group memebers will result in
+identical behavior to failing to relay a message).
+* While a server *can* duplicate messages, these will have no impact on the
+ group message tree (because of encryption, nonces and message identities
+ ) - the source of the duplication is not knowable to a peer.
+ 
+## Efficiency
+
+As of writing, only 1 protocol is known for achieving the desired properties,
+naive PIR or "the server sends everything, and the peers sift through it".
+
+This has an obvious impact on bandwidth efficiency, especially for peers using
+mobile devices, as such we are actively developing new protocols in which the
+privacy and efficiency guarantees can be traded-off in different ways.
+
+The most developed idea is to bucket the messages on the server into discrete
+time windows and allow peers to fetch smaller batches, coupled with the
+ underlying tor connection this technique should provide sufficient privacy
+  - although the technique still needs formal verification.
+  
+# Protecting the Server from Malicious Peers
+
+The main risk to servers come in the form of spam generated by peers. In the
+prototype of Cwtch a spamguard mechanism was put in place that required
+peers to conduct some arbitrary proof of work given a server-specified
+ parameter.
+
+This is not a robust solution in the presence of a determined adversary with
+a significant amount of resources, and thus one of the main external risks to
+ the Cwtch system becomes censorship-via-resource exhaustion.
+ 
+We have outlined a potential solution to this in 
+[token based services](https://openprivacy.ca/research/OPTR2019-01/) but note
+ that this also requires further development.