edit links, test update and diagrams

docs/FAQs/Backups.md

@@ -6,28 +6,31 @@ This guide has been developed as a community project and is a live document. We
 
 The backup process in Fedimint is out of scope of the main protocol and is likely to differ depending on the particular federation implementation.
 
+In particular large federations with weaker the second party trust may approach this process very differently to smaller federations.
+
+Here we will focus on the community federation with stronger second party trust assumptions. 
+
 ## How are user backups and recoveries managed?
 
-It is envisaged that after joining a federation, which only requires scanning a QR code provided by a federation guardian, the user will likely be asked to enter their full name as it appears on their passport (or easily memorable piece of information).  
+It is envisaged that after joining a federation, which only requires scanning a QR code provided by a federation guardian, the user will likely be asked to enter their name or an easily memorable piece of information which can be provided to the federation during the recovery process.
 
-This will be used to encrypt the user private key before it is sharded and backed up to the guardians’ federation servers.
+This will be used to encrypt the user private key along with a pepper (secret salt) before it is sharded and backed up to the guardians’ federation servers.
 
-If a user loses their phone or can no longer access their tokens, they can personally verify themselves using KYF (Know Your Federation - always use Fedimints where you can trust your guardians) and once a quorum of guardians verify the identity of the user, they can send the shards that relate to their name and the user can reconstitute them locally.
+If a user loses their phone or can no longer access their tokens, they can personally verify themselves to the federation guardians (where there is a strong second party trust relationship with the guardians) and once a quorum of guardians verify the identity of the user, they can send the shards that relate to their name and the user can reconstitute them locally.
 
-## Can Fedimint federations help with estate planning and inheritance?
+This process can be thought of as an encrypted password backup to a mini private DropBox or Google Drive run by the federation.
 
-Yes.  Building on the protocol discussed in the question “How are user backup and recovery handled?”, it is feasible to securely store one’s will with the Fedimint federation such that it can only be revealed upon your passing.  
+In this way, no one guardian is able to access a user’s credentials but a minority of guardians losing their federation private keys will not prevent recovery of the user’s private key.  
 
-Even without this, it is possible for suitably appointed executors to a Will to provide sufficient evidence to enable the guardians to release the late users tokens to them.
+Given the multiple second party trust model that already exists, this approach does not introduce additional risk to users but does provide greater convenience and lower risk than storing it with a third party such as a cloud backup service provider.
 
-## Do federation users need back up private keys?
+## Can Fedimint federations help with estate planning and inheritance?
 
-Do federation users need to figure out how to back up their private keys or 12 or 24 word backup phrases like with a hardware wallet?
+Yes.  Building on the recovery process above, it is feasible to securely store one’s will with the Fedimint federation such that it can only be revealed upon your passing.  
 
-Yes they do, but it is envisaged that their key will automatically be split into cryptographically secure “shards” that are shared between the guardians when they first connect using their full name (or similar) as the recovery key. 
+Even without this, it is possible for suitably appointed executors to a Will to provide sufficient evidence to enable the guardians to release the late users tokens to them.
+
+This process would likely differ in implementation between federations.
 
-This process can be thought of as an encrypted password backup to a mini private DropBox or Google Drive run by the federation.
 
-In this way, no one guardian is able to access a user’s credentials but a minority of guardians losing their federation private keys will not prevent recovery of the user’s private key.  
 
-Given the multi second party trust model that already exists, this approach does not introduce additional risk to users but does provide greater convenience and lower risk than storing it with a third party such as a cloud backup service provider.

docs/TradeOffs/01-Trust-Trade-Offs.md

@@ -2,7 +2,7 @@
 sidebar_position: 1
 ---
 
-# Trust Model
+# Trust Model Trade Offs
 
 :::caution
 This guide has been developed as a community project and is a live document. We would advise you to fully consider your own risk model and mitigations before running Fedimint. We also appreciate any feedback you may have and you can submit edits, corrections and pull requests through the link at the bottom of each page.
@@ -25,12 +25,14 @@ On the flip side the user benefits from the following positive attributes:
 
 1. **Blind Balance:** The guardians cannot see a users balance. 
 2. **Blind Transactions:** The guardians cannot tell which parties are part of a transaction.
+3. **Unattended LN deposits:** A user of a fedimint can receive payment on the lightning network without needing to be online.
+4. **Simplified use:** Using the Bitcoin and Lightning network is made simpler due to the operation of the Bitcoin and Lightning nodes being outsourced to the federation of LN gateways.
 
 :::note
-Fedimint is a voluntary system which individuals can and individuals in part or fully for their bitcoin custody. We hope that by being honest with these trade offs, individuals can make better decisions for their risk profiles. 
+Fedimint is a voluntary system which individuals can use in part or fully for their bitcoin custody. We hope that an honest accounting of the trade offs will help individuals make better decisions for their risk profiles. 
 :::
 
-## The Trade Offs
+## The Risks
 
 The trade offs in the trust model have been captured as five key risks as outlined below[^1] and explored in more detail on the following pages. 
 
@@ -42,7 +44,6 @@ The trade offs in the trust model have been captured as five key risks as outlin
 3. **[Regulatory Risk](RegulatoryRisk):** Can the federation be unilaterally shut down or forced to cease operations.
 4. **[LN Gateway Censorship Risk](TrustLNGateways):** What are the risks in LN gateways refusing service to mint users.
 5. **[Transaction Censorship Risk](Transaction-Contract-Fulfilment):** In what instance could a federation refuse service. 
-6. **[Deanonymisation of backups:](BackupDeanonymization)** Can the federation leak identity information from your backup.
 
 
 [^1]: This is under constant revision, please raise further trade offs for consideration. 

docusaurus.config.js

@@ -37,15 +37,15 @@ const config = {
           sidebarPath: require.resolve("./sidebars.js"),
           // Please change this to your repo.
           // Remove this to remove the "edit this page" links.
-          editUrl: "https://github.com/fedimint/fedimint.org/tree/main/",
+          editUrl: "https://github.com/fedimint/wiki_fedimint/tree/main/",
           remarkPlugins: [math],
           rehypePlugins: [katex],
         },
         blog: {
           showReadingTime: true,
           // Please change this to your repo.
           // Remove this to remove the "edit this page" links.
-          editUrl: "https://github.com/fedimint/fedimint.org/tree/main/",
+          editUrl: "https://github.com/fedimint/wiki_fedimint/tree/main/",
           blogSidebarTitle: "All posts",
           blogSidebarCount: "ALL",
         },