Commit 18a88d713536e6a0673dec03a5f1d93805309847
more notes
Stephen Whitmore committed on 1/6/2018, 4:20:00 AMParent: 41d9d4ce3d814a32ebcd97479b0883634a5ffbf8
Files changed
README.md | changed |
README.md | ||
---|---|---|
@@ -4,9 +4,9 @@ | ||
4 | 4 … | single answer that maps exactly to *all* peer-to-peer systems; this FAQ does its |
5 | 5 … | best to provide a general answer when possible, and provide concrete examples |
6 | 6 … | where it makes sense. |
7 | 7 … | |
8 | -## Sounds great, but will it scale? | |
8 … | +## 1. Sounds great, but will it scale? | |
9 | 9 … | |
10 | 10 … | Yes. It is rare to find a p2p service that does not scale. They are distributed |
11 | 11 … | systems by design, and most distributed systems are meant to scale. You could |
12 | 12 … | say, then, that many distributed systems take cues from p2p systems in order to |
@@ -20,9 +20,9 @@ | ||
20 | 20 … | struggle to initially share to the first wave of peers. Unlike a centralized |
21 | 21 … | system though, once that first wave of peers downloads a copy, the bandwidth for |
22 | 22 … | that torrent data to be served grows exponentially. |
23 | 23 … | |
24 | -## If websites are hosted on p2p, what happens when no peers are online? | |
24 … | +## 2. If websites are hosted on p2p, what happens when no peers are online? | |
25 | 25 … | |
26 | 26 … | The same result as when a centralized website goes down: it isn't available. |
27 | 27 … | |
28 | 28 … | The difference is that peer-to-peer networks distribute *the power to host*. I |
@@ -31,26 +31,48 @@ | ||
31 | 31 … | that there may be many peers in the swarm that are also hosting my website, so |
32 | 32 … | if my server goes down, the site will continue to be accessible through those |
33 | 33 … | seeding peers. |
34 | 34 … | |
35 | -## What about security? Somebody could share a hacked version of a p2p website? | |
35 … | +## 3. What about security? Somebody could share a hacked version of a p2p website? | |
36 | 36 … | |
37 | -... | |
37 … | +It depends what the security model of the system hosting the website uses. There | |
38 … | +are two commonly tools I know of for ensuring that a copy of data you've | |
39 … | +received from a potentially untrusted source is authentic: | |
38 | 40 … | |
39 | -## What about privacy? Everybody in the p2p network can see what I am looking at. | |
41 … | +1. You used the [hash](https://wikipedia.org/Hash_function) of the data to | |
42 … | + request from the p2p network. If so, the data you receive from a peer can be | |
43 … | + hashed, and that hash compared against the one used to make the request for | |
44 … | + the data. [IPFS](https://ipfs.io) and [Secure | |
45 … | + Scuttlebutt](https://scuttlebutt.nz) do this. A caveat is that the data is | |
46 … | + static: the hash never changes and thus neither can the data. A benefit is | |
47 … | + that content-addressable data can be safely cached indefinitely. | |
40 | 48 … | |
41 | -... | |
49 … | +2. You used the [public key](https://wikipedia.org/Public_key_cryptography) of | |
50 … | + the author to request the data from the p2p network. The idea is that every | |
51 … | + version of the data is cryptographically signed by the data's author, so that | |
52 … | + any data you download will have a signature can be checked against the public | |
53 … | + key used to request the data. This guarantees that the data came from the | |
54 … | + author you expected, and also permits changes to that data, unlike with | |
55 … | + content-addressed above. [Dat](https://dat-project.org), | |
56 … | + [IPFS](https://ipfs.io) and [SSB](https://scuttlebutt.nz) all use this | |
57 … | + approach for dynamic data. | |
42 | 58 … | |
43 | -## p2p is great, but sometimes you need a single authoritative source of truth | |
59 … | +## 4. What about privacy? Everybody in the p2p network can see what I am looking at. | |
44 | 60 … | |
45 | 61 … | ... |
46 | 62 … | |
47 | -## What if nazis take over the p2p network? | |
63 … | +## 5. P2P is great, but sometimes you need a single authoritative source of truth | |
48 | 64 … | |
49 | -... | |
65 … | +If you are cryptographically signing the data you create (see #3), users can | |
66 … | +request your content by your public key. In this way you are able to control | |
67 … | +what data appears in this feed of data, but rely on potentially untrusted peers | |
68 … | +to distributed that data. | |
50 | 69 … | |
51 | -## What areas do modern p2p apps still struggle with? | |
70 … | +By introducing a monotonic increasing sequence number to each new entry in the | |
71 … | +signed feed, peers can be assured that no messages were suppressed or censored. | |
52 | 72 … | |
73 … | +## 6. What areas do modern p2p apps still struggle with? | |
74 … | + | |
53 | 75 … | Apps still seem to have a hard time managing resources, like CPU and network |
54 | 76 … | bandwidth. If an app naively tries to download and replicate ALL of the data it |
55 | 77 … | sees, it's easy for it to overwhelm the machine it's running on. Many apps still |
56 | 78 … | have a ways to go in offering good controls for CPU and bandwidth use. |
Built with git-ssb-web