Move questions/answers into FAQ section

.vscode/ltex.hiddenFalsePositives.en-US.txt

@@ -1,3 +1,6 @@
 {"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qpolyproto-core - The core federation protocol and APIs of polyproto.\\E$"}
 {"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qpolyproto-chat - The chat-API used by polyproto.\\E$"}
 {"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qpolyproto - The combination of the polyproto-core and polyproto-chat protocols and APIs.\\E$"}
+{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qquestion \"What if server B is malicious and provides a different public identity key for Alice?\\E$"}
+{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qquestion \"What if a home server is compromised/malicious?\\E$"}
+{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qquestion \"What if a server requests a federation token on behalf of a user?\\E$"}

SPECIFICATION.md

@@ -14,6 +14,7 @@
     - [2.4 Best practices](#24-best-practices)
       - [2.4.1 Signing keys](#241-signing-keys)
       - [2.4.2 Home server operation and design](#242-home-server-operation-and-design)
+    - [2.5 FAQ](#25-faq)
   - [3. Federating direct/group messages](#3-federating-directgroup-messages)
     - [3.1 Direct messages](#31-direct-messages)
     - [3.2 Group messages](#32-group-messages)
@@ -122,24 +123,12 @@ A client may choose to rotate their signing key at any time. When this happens,
 
 Signing messages prevents a malicious server from impersonating a user.
 
-TODO: Note about signing keys and how they are generated
-
-> TODO: What if a home server is compromised/malicious? How can we prevent a malicious server from impersonating a user?
-
-> - Technically, nothing prevents a malicious server from impersonating a user within the domain of that malicious server. However, I don't think that this is a problem. A malicious admin can always access the servers' database and impersonate users by directly manipulating database entries. The admin being able to potentially do this is entirely within our threat model. Secure communication should always be done via end-to-end encryption.
-
-TODO: What about impersonating a user on another server? 
-
-- The question here is: What if a server requests a federation taken on behalf of a user? This server would then hold the federation token, and could use it to request a session token on the user's behalf, as well generate a signing key which is supposed to represent the impersonated user. The server would then hold all the information it needs to impersonate a user on another server. 
+TODO: Note about signing keys and how they are generated 
 
 ### 2.3 Reducing network strain when verifying signatures
 
 If Bob receives a message from Alice, he will ask Server B to provide the public identity key of Alice at the time the message was sent. Server B will then ask Server A for this key. Server A will then send the appropriate key to Server B. Server B will then store this key in its database and forward it to Bob. Bobs' client should then ask Server A for its signing key, cache this key and verify that Server B has stored/provided the correct public identity key for Alice at the time the message was sent. Should Bob want to re-verify the signature of Alice's message in the future, or should another User of Server B want to verify the signature of Alice's message, Server B will already have the public identity key cached.
 
-> TODO: What if server B is malicious and provides a different public identity key for Alice? Bob would then succeed in verifying the signature of Alice's message, but the message would not have been signed by Alice.
-
-> - Consider removing this chapter (2.3) if no solution can be found.
-
 Bob's client could always ask Server A for the public identity key of Alice, but this would put unnecessary strain on the network. This is why Server B should cache the public identity keys of users from other instances.
 
 ### 2.4 Best practices
@@ -153,6 +142,20 @@ Bob's client could always ask Server A for the public identity key of Alice, but
 
 - Employ a caching layer to handle the potentially large amount of requests for public keys without putting unnecessary strain on the database.
 
+### 2.5 FAQ
+
+!!! question "What if a home server is compromised/malicious? How can we prevent a malicious server from impersonating a user?"
+
+    Technically, nothing prevents a malicious server from impersonating a user within the domain of that malicious server. However, we don't think that this is a problem. A malicious admin can always access the servers' database and impersonate users by directly manipulating database entries. The admin being able to potentially do this is entirely within our threat model. Secure communication should always be done via end-to-end encryption, which prevents something like this from happening.
+
+!!! question "What if server B is malicious and provides a different public identity key for Alice? Bob would then succeed in verifying the signature of Alice's message, but the message would not have been signed by Alice."
+
+    TODO: Consider removing chapter 2.3 if no solution can be found.
+
+!!! question "What if a server requests a federation token on behalf of a user? This server would then hold the federation token, and could use it to request a session token on the user's behalf, as well generate a signing key which is supposed to represent the impersonated user. The server would then hold all the information it needs to impersonate a user on another server."
+
+    TODO: uhhhhhhhhhh
+
 ## 3. Federating direct/group messages
 
 ### 3.1 Direct messages