Add references to the issues #3, #5, #11, #20, #23 and #24

concept/apis.md

@@ -5,11 +5,36 @@
 Connect different GDS instances, e.g. for creating a decentralized social network or offer services to the community (e.g. "Hi, I'm server xyz and I offer these services …") It still needs to be solved, how the data for single users are handled in shared environments.
 
 ## Connecting instances
-(just an idea)  
-Let's assume Joe wants to connect his GDS instance with the one of Rick to gain access to Rick's files.  
-An authentication process using a secret key could look like this:  
-Joe puts the URL of Rick's GDS instace in a "Connect with an instance" dialog. Joe's GDS sents some kind of ping to Rick's GDS where a popup with a scerect connect-key shows up. Rick sends this connect-key to Joe e.g. via an ecrypted email. Joe now copies the connect-key into a dialog of his GDS instance.  
-Now Joe's GDS instance hashes the connect-key and asks Rick's GDS instance if that hash equals the hash of the connect-key Rick's GDS just genrated for Joe's GDS instance.
+
+There are multiple ways described in [Issue #20](https://github.com/grand-decentral-station/concept/issues/20):
+
+- Using secret keys
+
+	1. Joe wants to connect his GDS instance with the one of Rick to gain access to Rick's files.  
+	2. Joe puts the URL of Rick's GDS instance in a "Connect with an instance" dialog.
+	3. Joe's GDS sends some kind of ping to Rick's GDS where a popup with a secret connect-key shows up.
+	4. Rick sends this connect-key to Joe e.g. via an encrypted email.
+	5. Joe now copies the connect-key into a dialog of his GDS instance.  
+	6. Joe's GDS instance hashes the connect-key and asks Rick's GDS instance if that hash equals the hash of the connect-key Rick's GDS just generated for Joe's GDS instance.
+
+- Using invitation
+
+	1. Rick wants to share some of his photos with Joe
+	2. Rick adds the user id of Joe (`[email protected]`) to the list of people with access and can give him write or only read privileges.
+	3. Rick's GDS pings the GDS of Joe at the domain domainofhisgds.tld
+  		- If there is a GDS living under the domain domainofhisgds.tld, Joe gets a message telling him he has access and can then see the content from Rick's GDS just like it would be stored on his own one
+  		- If there is **no** GDS living there (= normal email address), Joe gets an email telling him that he can now interact with Rick's data using a secret (and long) share URL pointing right to Rick's GDS
+	4. Done
+
+- Using connection requests
+
+	1. Joe arrives at Rick's social profile / website / service and wishes to connect
+	2. Joe pushes the 'connect' button. As a pre-authenticated GDS user ([email protected]), a connect request is sent automatically to Rick.
+	3. Via email or web interface, Rick can accept or deny Joe's request.
+	4. Done
+
+	To avoid spam, GDS could limit people able to request access to "friends of friends" like in the Facebook "discoverability" options. Alternatively, it could be switched to "invite only".
+
 
 ## Administration API
 

concept/applications.md

@@ -38,6 +38,8 @@ Each GDS application is a "meta-container" with one or more containers which mak
 
 All apps run completely sandboxed and communicates over a simple JSON api with the GDS core (e.g. service name/type, URLs/ports for service endpoints, meta info, etc.)
 
+There are several problems with this described in [Issue #5](https://github.com/grand-decentral-station/concept/issues/5) and [Issue #23](https://github.com/grand-decentral-station/concept/issues/23) which have yet to be solved.
+
 ## App Store
 
 It should be decentralized as well, so there could be an "app server" app for GDC to host your own app repository. A user could then subscribe to that server using its URL and could browse, buy and download apps directly from there.

concept/hosting.md

@@ -28,4 +28,16 @@ To handle traffic to and from the device in case of no available static IP it sh
 
 ## 4. On a personal computer 
 
-It is thinkable that Grand Decentral Station could also be running as an application on your personal computer. The connectivity to the web would be limited to the uptime of your computer, but that could be compensated by additional concepts to share server power between friends in the network of Grand Decentral Stations, so your trusted friends would take over hosting parts of your services and vice versa. This is very much theoretical yet though. 
+It is thinkable that Grand Decentral Station could also be running as an application on your personal computer. The connectivity to the web would be limited to the uptime of your computer, but that could be compensated by additional concepts to share server power between friends in the network of Grand Decentral Stations, so your trusted friends would take over hosting parts of your services and vice versa. This is very much theoretical yet though.
+
+See [Issue #3](https://github.com/grand-decentral-station/concept/issues/3) for more thoughts about this idea.
+
+## 5. On a small dedicated box the user already has
+
+Other possible devices for GDS are:
+
+- "low end boxes", i.e. small VPSes with only a small amount of RAM.
+- Raspberry Pi's
+- just about anything capable of running a current Linux Kernel and a bit of Hard Drive Space.
+
+See [Issue #11](https://github.com/grand-decentral-station/concept/issues/11) for more thoughts about this.

concept/services.md

@@ -114,7 +114,7 @@ If the different server can reproduce that the GDS is down, this chain continues
 The fifth discovery & uptime server now pings one of the mentoring servers of the user (multiple if one is down) and tells it that the domain is down.
 
 The mentoring server then checks again and if it can also reproduce this, it sends an email (or whatever communication channel the mentoring server implements) to the alternative email address of the admin.  
-It then remembers that it sent that email and will refuse to send another one until the GDS was up in between.
+It then remembers that it sent that email and will refuse to send another one until the GDS was up in between. The other mentoring servers will get a message about it as well to prevent multiple emails.
 
 The mentoring servers are needed to
 
@@ -127,4 +127,8 @@ Of course, the motivation to install a discovery & uptime server might not be th
 
 A way to motivate people would be monetizing found downtimes by letting the admin of the tracked GDS define a budget for every email which would be divided among all involved servers.
 
-This would probably lead to people modifying the software to claim that *every* GDS is down to save resources. The only way to fix this is a large number of discovery & uptime servers - some of them will still confirm that the server is up. This would stop the chain and the cheaters wouldn't have success.
+This would probably lead to people modifying the software to claim that *every* GDS is down to save resources. The only way to fix this is a large number of discovery & uptime servers - some of them will still confirm that the server is up. This would stop the chain and the cheaters wouldn't have success.
+
+### More information
+
+There's a discussion in [Issue #24](https://github.com/grand-decentral-station/concept/issues/24) about this.