git ssb

0+

cel / ssbc/docs



Commit cd2325e9ec3cfcaf23351328dc49e9e9e3db3478

Browse Files

Revert "move FAQ to ssb-handbook (#28)"

This reverts commit 5a1cdd281d7ef6e3b530ae1ab0f5ceba63285fb6.

This FAQ is not entirely in the handbook.
cel committed on 12/21/2019, 4:36:02 AM
Parent: a06f1b05e501f4825edad499e57711d07d44035e

Files changed

ssb/faq.mdadded
ssb/faq.mdView
@@ -1,0 +1,199 @@
1 …+# FAQ
2 …+
3 …+## How does user identity work?
4 …+
5 …+Users are identified by public keys.
6 …+This means it is not necessary to have a global registry of user names, nor to have a central server that tracks the action of users.
7 …+Instead, every user action (post) is signed, and this can be verified by any peer.
8 …+
9 …+To evaluate the trustworthiness of a user, you look at information published by other trusted users about the target.
10 …+If trusted users have flagged the target, then it is a bad actor.
11 …+If trusted users have followed the target, then it is probably a good actor.
12 …+
13 …+## What does a message look like?
14 …+
15 …+Here is an example message.
16 …+The top level properties are all mandatory, but the user may set anything inside the `content` property, as long as there is a `type` field which is a string between 3 and 64 characters long.
17 …+(The type is up to 64 characters long so that it may be represented by a hash.)
18 …+
19 …+``` js
20 …+{
21 …+ "previous": "%26AC+gU0t74jRGVeDY013cVghlZRc0nfUAnMnutGGHM=.sha256",
22 …+ "author": "@hxGxqPrplLjRG2vtjQL87abX4QKqeLgCwQpS730nNwE=.ed25519",
23 …+ "sequence": 216,
24 …+ "timestamp": 1442590513298,
25 …+ "hash": "sha256",
26 …+ "content": {
27 …+ "type": "vote",
28 …+ "vote": {
29 …+ "link": "%WbQ4dq0m/zu5jxll9zUbe0iGmDOajCx1ZkLKjZ80JvI=.sha256",
30 …+ "value": 1
31 …+ }
32 …+ },
33 …+ "signature": "Sjq1C3yiKdmi1TWvNqxIk1ZQBf4pPJYl0HHRDVf/xjm5tWJHBaW4kXo6mHPcUMbJYUtc03IvPwVqB+BMnBgmAQ==.sig.ed25519"
34 …+}
35 …+```
36 …+
37 …+The `previous` is the hash of the message before this in the feed signed by `author`.
38 …+`author` is the public key which signs this feed.
39 …+The key pair for this feed *may not* be used for other feeds.
40 …+
41 …+## Why is there a size limit on messages?
42 …+
43 …+Messages are limited at 8kb in size so that the time required to replicate is predictable.
44 …+Also, since peers will replicate all messages for peers they follow, it's important that peers do not create an unreasonable amount of work for each other.
45 …+
46 …+If you need a larger object, use "blob attachments."
47 …+
48 …+## What are attachments?
49 …+
50 …+Attachments are immutable blobs of binary data, similar to email attachments.
51 …+When clients see a message that refers to a given attachment, it will request it if the attachment isn't already stored locally.
52 …+Attachments are limited to 10mb.
53 …+
54 …+Replication of larger files could be implemented by integrating bittorrent (or even better, [webtorrent](https://github.com/feross/webtorrent)).
55 …+
56 …+## How do new users join the system?
57 …+
58 …+To join the network, a user needs to know a server in the system.
59 …+To have their data replicated, they need someone to follow them.
60 …+
61 …+The simplest way to join the network is to use an invite code.
62 …+The invite code contains the address of a pub server, and a secret that commands the server to follow (and therefore replicate) the invite's user.
63 …+If you run your own pub server you can create invite codes and give them to your friends.
64 …+
65 …+## Why do you have pub servers? isn't that a point of centralization?
66 …+
67 …+Routers with Network Address Translation ("NAT") and firewalls, and the shortage of IP addresses, make p2p difficult.
68 …+The simplest way around this problem was to create "pub servers".
69 …+
70 …+A pub server is exactly like a normal client, except you run it on a server with a static IP address.
71 …+It's a "pub" as in a bar where your friends meet to exchange gossip.
72 …+
73 …+Anyone can run a pub server.
74 …+It's not centralization because pub servers are totally generic (same code as "clients") and because, if we did have ipv6 and full p2p, ssb would work without any changes.
75 …+Also note that ssb also detects other peers running on your local network (wifi) and connects to them directly, without pub servers.
76 …+
77 …+## How do I reserve my user name?
78 …+
79 …+Secure Scuttlebutt does not have unique user names, because that would require a central registry of names, and then the system would not be decentralized.
80 …+
81 …+Instead, ssb's nicknames can be set locally.
82 …+If two of your friends pick the same name, then you can rename one to disambiguate them.
83 …+
84 …+The web interface alerts the user to name conflicts, so that this can be resolved quickly.
85 …+
86 …+## How do we prevent harassment and spam?
87 …+
88 …+Harassment is a problem on most online services.
89 …+The normal approach is to give users block or mute buttons or to have moderators.
90 …+All of these could be implemented on top of secure scuttlebutt.
91 …+
92 …+Presently, there is a "flag" feature, which is an extremely strong negative signal.
93 …+If somebody is behaving poorly, feel free to flag them.
94 …+
95 …+## Is it possible to delete or edit messages?
96 …+
97 …+Secure Scuttlebutt is immutable, so strictly speaking you cannot change anything that has been published.
98 …+There are, however, abstractions on top of the feeds which allow behaviors like deletion and editing.
99 …+
100 …+### Delete
101 …+
102 …+A true delete is not possible: instead, you post a message asking your friends to _ignore_ the message.
103 …+This is somewhat like real life - if you say something embarrassing, the best you can do is ask your friends to ignore it.
104 …+(Life is much better when you have good friends.)
105 …+
106 …+### Edit
107 …+
108 …+Editable objects can be represented by posting a create message, and then posting a message that refers to that message and overrides properties on that message, or applies patches to it.
109 …+By declaring lists of who may or may not edit documents, and using CRDTs to ensure convergence, you could implement access controls.
110 …+
111 …+## Could games be built on top of ssb?
112 …+
113 …+SSB would be quite suitable for turn based games.
114 …+
115 …+Generally, games are competitive, and so ensuring fairness requires consistency, i.e. turns.
116 …+In some games, player move in a given order (i.e. in a card game, players move one at a time).
117 …+In other games, players make moves simultaneously (i.e. in rock paper scissors).
118 …+(This is distinct from collaborative tasks such as wiki editing which are cooperative and are generally fine with eventual consistency.)
119 …+
120 …+This would be similar to editable documents, except that there would be well defined order that "edits" must occur in.
121 …+
122 …+### Perfect information games: chess / checkers / go
123 …+
124 …+Often in strategy games, all players know all information (except the plan of their opponent).
125 …+This could be easily implemented by posting messages that indicated the move taken from the previous game state.
126 …+
127 …+### Rock Paper Scissors
128 …+
129 …+In Rock Paper Scissors players reveal a secret simultaneously (their move).
130 …+This could be implemented securely by using a [commitment protocol](https://en.wikipedia.org/wiki/Commitment_scheme).
131 …+
132 …+### Poker
133 …+
134 …+Poker could be implemented securely (though, with more than 2 players you would have to trust other players not to collude, as you would in real life).
135 …+Shortly after inventing RSA encryption, Shamir, Rivest, Adleman developed a system for secure online poker called [mental poker](https://en.wikipedia.org/wiki/Mental_poker).
136 …+
137 …+I am not currently aware of any online poker site that uses their system, however.
138 …+Online poker depends on a trusted server - imagine playing poker around a table, but the dealer holds the cards face up, and shuffles behind a screen.
139 …+And yes, there have been [scandals](http://freakonomics.com/2007/10/17/the-absolute-poker-cheating-scandal-blown-wide-open/) where poker sites have had backdoors and have had house players that knew what cards the other players have!
140 …+
141 …+## How do you ensure data consistency between users?
142 …+
143 …+Sometimes, you want to make sure that other users are aware of a given change.
144 …+This can be implemented by posting acknowledgement messages.
145 …+
146 …+There is also active discussion about using signed pings to send ephemeral acknowledgements (off of the feeds).
147 …+
148 …+### Is SSB highly available (AP) or highly consistent (CP)?
149 …+
150 …+SSB is highly-available (AP).
151 …+Devices can create messages while offline, then synchronize later.
152 …+This means all data is eventually-consistent.
153 …+
154 …+### Can I know if I have the latest messages from somebody?
155 …+
156 …+No, because it's possible for devices to drop and continue operating (a network "partition").
157 …+There's a proposal to used signed pings to measure the "freshness" of a feed, but this could only be used in small groups of interested peers.
158 …+
159 …+### Is there a global total order in SSB?
160 …+
161 …+No.
162 …+There is, however, a global [partial order](http://en.wikipedia.org/wiki/Partially_ordered_set#Formal_definition).
163 …+
164 …+An individual feed has an internal [total order](http://en.wikipedia.org/wiki/Total_order).
165 …+Every message contains a sequence number and a pointer to the previous message in that feed.
166 …+
167 …+If feed A posts a message that links to a message in feed B, then we know that A's message is *after* B's.
168 …+That is, message-links imply a `happens-before` relationship.
169 …+(This is because, in order to know the hash of an object, that object must already exist.)
170 …+
171 …+Messages contain [monotonically increasing](http://en.wikipedia.org/wiki/Monotonic_function) UTC timestamps and sequence numbers.
172 …+This means you can assign an order to any two messages.
173 …+However, be aware that there is no way to ensure that the timestamp is accurate.
174 …+
175 …+## Can I deploy applications over SSB?
176 …+
177 …+It would be possible to deploy applications over ssb by sending the assets for that application as an attachment.
178 …+Then other users could run that app on their local machine.
179 …+
180 …+We have plans to build on this in the future.
181 …+
182 …+### How will you know it is safe to run an application?
183 …+
184 …+Applications would be run in a sandbox, and, since new versions of the application would be immutably published, it would always be possible to see the history of that application.
185 …+This would actually be much more secure that a normal web application.
186 …+In a normal website your browser just downloads code and runs it.
187 …+While it does run in a sandbox, it would be entirely possible to send one person a special version of the code that contained a targeted backdoor.
188 …+Since, in ssb, everyone will see the same history, it would be impossible to attack a single user like this without eventually being caught out.
189 …+
190 …+### Auditing applications
191 …+
192 …+Some applications require a higher quality standard, especially if they need special rights to the device's resources.
193 …+
194 …+Since performing a security audit is a highly skilled task, most users will not be able to perform their own security audit.
195 …+In this case, the user could "delegate" the auditing task to another user (or users) who perform the audit, posting a message declaring a given version safe to run.
196 …+Since the user can choose their auditors independently, it would mean an attacker would have to compromise the developers and many auditors in order to get people to install malicious code.
197 …+
198 …+Auditing could also be applied to application permissons.
199 …+Of course, the decision about what permissions is reasonable for a given application is much simpler than looking at code and checking there is nothing unsafe.

Built with git-ssb-web