home.md

@@ -23,13 +23,12 @@ Full fingerprint: **95EB 6FA4 03D7 29A7 13C2  FC9F F85A DA1C F61F 6137**
 
 ## When ?
 
-I'm still developing it all. Things can be complex, and I am finishing University.
+Developing is under way. A kickstarter campaign will start soon.
+I have finished University and am trying to make this project my work.
 
 The library is being developed [here](https://www.fenrirproject.org/Fenrir/libFenrir).
 
-It is still incomplete, but I am working towards a demo for now.
-
-Since I have to graduate in December, I'll better have something ready for then, though ;)
+It is still incomplete, but I am working towards a demo for now. A stable release might need up to one year.
 
 ## Why?
 
@@ -49,18 +48,21 @@ For an technical overview of the protocol read this
 [paper](https://www.fenrirproject.org/Fenrir/Fenrir_Project/uploads/504146146b8bbd21e0b1d4c40957c825/paper.pdf)
 that tracks the design of the protocol.
 
+For an in-depth analysis of the protocol choices, my [master thesis](https://www.fenrirproject.org/Fenrir/Thesis/wikis/home) should give you enough to think about.
+
 
 This protocol will be UDP-based, much like Google is doing with their [QUIC](QUIC) protocol
 In fact, a lot of ideas were taken from both SCTP and QUIC, so we have a full-featured transport protocol that handles cryptography and authentication in a new way. If it was not for the inclusion of a new authentication/authorization/cryptography mechanism, Fenrir would be too similar to google's QUIC.
 
 Aside from the transport features, the main objective of Fenrir are cryptography and user management.
 
-To better separate the players in our protocol, we define 3 roles:
+To better separate the players in our protocol, we define 4 roles:
 * Authentication Server
 * Service Server
-* Client
+* Application
+* Client Manager
 
-The names should be self-explanatory, they are the same as in Kerberos, and their function is the same, too:
+The names should be self-explanatory, they are similar to the Kerberos ones, and their function is the same, too:
 
 ### Authentication Server
 
@@ -70,9 +72,15 @@ This is obviously the server that will do the authentication and manage the user
 
 This is your application server. It may be an HTTP server or anything else. It's in constant communication with the Authentication Server and should NOT have access to the client credentials.
 
-### Client
+### Application
+
+The application that the user want to use (browser/mail client, whatever).
+
+### Client Manager
+
+The manager for your authentications/authorizations. It will connect to the Authentication server to negotiate the access and crypto stuff and then communicate directly with a Service Server.
 
-Your computer, or program. It will connect to the Authentication server to negotiate the access and crypto stuff and then communicate directly with a Service Server.
+This will handle all the security details, so that the application does not need to know anything about handshakes, token, or other authentication stuff.
 
 ### More details
 
@@ -85,7 +93,7 @@ If you are interested in the low level details, you can look at the following pa
 
 ## How can I contribute?
 
-Right now, please just analyze, think, comment, and ask questions. I'm still waiting for people's opinion on the protocol and design choices in general.
+For now, I am only looking for comments on theory and design. Around April the code should be a bit more stable, and you might want to look at the code and start contributing. If the Kickstarter campaign is successful enough, I will hire more developers, so check the status of the campaign if you are interested.
 
 The [library code](https://www.fenrirproject.org/Fenrir/libFenrir) is public, yet unfinished.