feat(p2p): started work on the p2p introduction

src/p2p.md

@@ -1,60 +1,119 @@
-# Information sharing and P2P
+# Pier to Pier networking
 
-As mentioned before, a Blockchain operates in _high adversarial conditions_. That is to say, we have to assume:
+Most online services in Web 2.0 follow a simple **client-server** architecture, where a client (the person using the service) makes a request to a centralized server belonging to the service provider. This centralized server then sends a response to your client which satisfies your request.
 
-- Bad actors will attempt to abuse, break and tamper with a Blockchain.
-- There is no way to differentiate a bad actor from a good actor.
-- Bad actors might have very high resources and capabilities.
+> **Facebook** is a good example of a client-server model: when you like a post, a request is sent to the Devi- ahem Facebook servers. These in turn register your like and send an updated version of the like count to other users seeing the same post.
 
-> **High adversarial conditions** describes a state of heightened threat to a system: this means that there might be many people trying very hard to break said system. In the case of Blockchain, this might be hackers, corporations, or even _nations_.
+<div style="text-align: center;">
 
-**How can we create a system for sharing information that is resilient under these sort of conditions?** In a traditional Web 2.0 environment, information exchange is centralized: there exists a server, or finite small set of servers that are used to propagate data around the world.
+```mermaid
+flowchart LR
+    C1[Client]
+    C2[Client]
+    C3[Client]
+    S[(fa:fa-server Server)]
+
+    C1 --> S
+    C2 --> S
+    C3 --> S
+
+    S --> C1
+    S --> C2
+    S --> C3
+```
+_Fig. 1: A typical client-server architecture_
+
+</div>
 
-If a server shuts down or is tampered with, because of an error or a malicious attack, then part of a network that relied on that server might stop working as intended. This can be mitigated by having multiple _redundant_ servers so that if it is no longer operating as normal, another will take it's place: kind of like a backup generator.
+What happens however if this server were to _shut down_? We call this a centralized _vulnerability_.
 
-> We can already begin to see that _redundancy_ is key if we want to create a resilient system.
+> **Centralized vulnerability** occurs when a system relies entirely on one of its components to function: if that component were to stop functioning, it would affect the rest of the system.
+>
+> ex: _Fuel is a centralized vulnerability in a car. If a car runs out of fuel, it stops working. There is no alternative that can fill its role in its place._
 
-## Hacking a centralized network
+In the case of our client-server model, this is an issue since it means that any client, or user, trying to connect to a failing server will not be able to use the service it usually provides.
 
-Let's consider the following example: imagine a single network that allows users to connect to the rest of the internet. This network is split into two servers, with three users **A**, **B** and **C** trying to connect to this network.
+<div style="text-align: center;">
 
 ```mermaid
 flowchart LR
-    subgraph "Sub-Network 1"
-        User1[fa:fa-user User A] --> Server1
-        User2[fa:fa-user User B] --> Server1
-    end
-
-    subgraph "Sub-Network 2"
-        User3[fa:fa-user User C] --> Server2
-    end
-  
-    Server1[(fa:fa-server Server 1)] --> WWW
-    Server2[(fa:fa-server Server 2)] --> WWW
-
-    WWW((fa:fa-globe WWW))
+    classDef serverDown fill:#ff5050,stroke:black,color:black
+
+    C1[Client]
+    C2[Client]
+    C3[Client]
+    S[(fa:fa-server Server)]:::serverDown
+
+    C1 --x S
+    C2 --x S
+    C3 --x S
+
+    S ~~~ C1
+    S ~~~ C2
+    S ~~~ C3
+
+    linkStyle 0 stroke:#ff5050
+    linkStyle 1 stroke:#ff5050
+    linkStyle 2 stroke:#ff5050
 ```
 
+_Fig. 2: A service which relies on a client-server architecture is vulnerable to outages_
+
+</div>
+
+There is an easy solution to this: add more servers! That way if one stops working, another one will be able to take up the work in its place. While this protects us from outages and external malicious attacks, it does not protect us from _internal malicious attacks_.
+
+> Even with multiple redundant servers, there exists a single entity with absolute power over the service it provides. Nothing prevents that entity from abusing that power by choosing to restrict certain users for example, or censoring content it does not approve of.
+
+## Decentralized servers
+
+> **P**ier to **P**ier networking, or (P2P), describes a network in which there resides no central authority with absolute power over the services it provides.
+>
+> ex: _popular examples of P2P networks include [Gnutella](https://en.wikipedia.org/wiki/Gnutella) and [Bittorent](https://www.bittorrent.com/)._[^1]
+
+P2P networks function by allowing anyone to enter as a server, or Node. Crucially, no Node is treated differently from any other. This way, there is no central point of failure to such networks.
+
+<div style="text-align: center;">
+
 ```mermaid
 flowchart LR
-    classDef serverDown color:#000,fill:#FF866C,stroke:#FF4A23,stroke-width:2px;
-
-    subgraph "Sub-Network 1"
-        User1[fa:fa-user User A] --> Server1
-        User2[fa:fa-user User B] --> Server1
-    end
-
-    subgraph "Sub-Network 2"
-        User3[fa:fa-user User C] --> Server2
-    end
-  
-    Hacker[fa:fa-computer Hacker] --> Server1
-    Server1[(fa:fa-server Server 1)]:::serverDown --> WWW
-    Server2[(fa:fa-server Server 2)] --> WWW
-
-    WWW((fa:fa-globe WWW))
-
-    linkStyle 0 stroke:#FF866C
-    linkStyle 1 stroke:#FF866C
-    linkStyle 4 stroke:#FF866C
+    classDef serverDown fill:#ff5050,stroke:black,color:black
+
+    C1[Client]
+    C2[Client]
+    C3[Client]
+
+    U1((fa:fa-user))
+    U2((fa:fa-user))
+    U3((fa:fa-user))
+
+    S1[(fa:fa-server Node)]
+    S2[(fa:fa-server Node)]:::serverDown
+    S3[(fa:fa-server Node)]
+
+    S1 --- U1
+    S2 --- U2
+    S3 --- U3
+
+    C1 --> S1
+
+    C2 --x S2
+    C2 --> S1
+
+    C3 --x S2
+    C3 --> S3
+
+    linkStyle 1 stroke:#ff5050
+    linkStyle 4 stroke:#ff5050
+    linkStyle 6 stroke:#ff5050
 ```
+
+_Fig. 3: A typical P2P network_
+
+</div>
+
+Contrarily to the typical client-server model, P2P networks distribute the data and computation they require over every Node in the network, with data being saved in multiple copies. That way, even if a single Node goes offline or is compromised, another Node can take its place.
+
+As you can see in figure 3, even if a single Node in a P2P network goes down, users can simply connect to another Node to access the service provided by the network. Each node can be individually owned by a unique user, with the largest networks boasting millions of users and still no central point of failure.
+
+[^1]: [Napster](https://en.wikipedia.org/wiki/Napster) might also come to mind, however while it utilized P2P techniques, it still relied on a centralized indexing server for retrieving information in the network. While it was still possible for people to set up their own indexing server as was the case during the [Metallica](https://en.wikipedia.org/wiki/Napster#Legal_challenges) debacle, this still meant not all nodes were treated equal, so Napster cannot be considered a 'true' P2P network.