From aaf1d499bfb648b8fa24eb9de0ca9772b80823a3 Mon Sep 17 00:00:00 2001 From: Kegan Dougal Date: Mon, 6 Oct 2014 13:18:52 +0100 Subject: [PATCH] Add more section headings. --- docs/specification.rst | 42 +++++++++++++++++++++++++++++++++++++----- 1 file changed, 37 insertions(+), 5 deletions(-) diff --git a/docs/specification.rst b/docs/specification.rst index eea892c90..de3d04f24 100644 --- a/docs/specification.rst +++ b/docs/specification.rst @@ -2378,6 +2378,15 @@ SRV Records .. TODO-doc - Why it is needed +State Conflict Resolution +------------------------- +.. NOTE:: + This section is a work in progress. + +.. TODO-doc + - How do conflicts arise (diagrams?) + - How are they resolved (incl tie breaks) + - How does this work with deleting current state Security ======== @@ -2385,6 +2394,29 @@ Security .. NOTE:: This section is a work in progress. +Server-Server Authentication +---------------------------- + +.. TODO-doc + - Why is this needed. + - High level overview of process. + - Transaction/PDU signing + - How does this work with redactions? (eg hashing required keys only) + +End-to-End Encryption +--------------------- + +.. TODO-doc + - Why is this needed. + - Overview of process + - Implementation + +Lawful Interception +------------------- + +Key Escrow Servers +~~~~~~~~~~~~~~~~~~ + Threat Model ------------ @@ -2531,10 +2563,6 @@ have to wait in milliseconds before they can try again. - Surely we should recommend an algorithm for the rate limiting, rather than letting every homeserver come up with their own idea, causing totally unpredictable performance over federated rooms? - - crypto (s-s auth) - - E2E - - Lawful intercept + Key Escrow - TODO Mark Policy Servers @@ -2543,7 +2571,11 @@ Policy Servers This section is a work in progress. .. TODO-spec - We should mention them in the Architecture section at least... + We should mention them in the Architecture section at least: how they fit + into the picture. + +Enforcing policies +------------------ Content repository