1 files changed, 40 insertions, 58 deletions

diff --git a/template/gsoc.html.j2 b/template/gsoc.html.j2
index 43ed1876..898fde13 100644
--- a/template/gsoc.html.j2
+++ b/template/gsoc.html.j2
@@ -69,29 +69,32 @@
       </section>
 
       <section>
-        <h4>re:claimID OpenID Connect performance improvements</h4>
+        <h4>re:claimID/GNUnet Browser Plugin</h4>
         <p>
           {% trans %}
             reclaimID is a decentralized identity system build on top of the GNU
             Name System.
-            Upon authorization, the user provides a requesting party (RP) such as a website
-            with an authorization ticket (e.g. piggybacked in an OpenID authorization code).
-            The RP uses information contained in this ticket to
+            Currently, there is a Webextension which uses the GNUnet <a href="https://rest.gnunet.org">REST API</a>.
+            In order to improve adoption and ease of use, this project aims to include
+            a full GNUnet node within the Webextention as a fallback.
+            GNUnet can be compiled to Web Assembly or JavaScript as demonstrated
+            <a href="https://gnunet.io">here</a>.
+            The idea is to improve upon this concept and support more of GNUnet's
+            subsystems.
+
+            The difficulty of this project largely depends on the students
+            proficiency with build tools, emscripten and improvisation skills.
+            There non-exhaustive task list would be:
             <ol>
-              <li> Retrieve the decryption key from GNS</li>
-              <li> Retrieve the user attributes from GNS</li>
+              <li>Improve existing GNUnet emscripten build to include more subsystems.</li>
+              <li>Integrate the result into a Webextention.</li>
+              <li>Integrate the result into the re:claimID Webextension</li>
             </ol>
-            The GNS lookups ensure that the RP receives up-to-date attributes and functional
-            decryption keys. However, in particular the RP-specific encryption key
-            resolution can be slow and even fail depending on the network topology.
-            We propose that in an initial exchange, in particular OpenID authorization code
-            flows, we try to incorporate key and maybe even an attribute set in the ticket
-            exchange.
-
-            In order to mitigate this issue, this project is meant to investigate and implement how...
+            Advantageous skills/languages/frameworks:
             <ol>
-              <li> ... decryption keys can be added to an initial exchange in OpenID.</li>
-              <li> ... initial set(s) of attributes can be piggybacked in OpenID.</li>
+              <li>C</li>
+              <li>emscripten</li>
+              <li>Webextensions</li>
             </ol>
             <br/>
             <strong>Mentors:</strong> Martin Schanzenbach
@@ -100,34 +103,32 @@
       </section>
 
       <section>
-        <h4>re:claimID alternative GNS-based encryption</h4>
+        <h4>Canonical statistics identifier</h4>
         <p>
           {% trans %}
-            re:claimID is a decentralized identity system build on top of the GNU
-            Name System.
-            The initial design and implementation of re:claimID includes an attribute-based
-            encryption module in order to prevent unauthorized access to attributes in the
-            name system.
-            Our motivation for re:claimID was for it to be name system agnostic, which
-            means the design theoretically also works for other name systems such as
-            namecoin.
-            Other name systems often do not have built-in mechanisms in order to do this.
-            Hence, we implemented an ABE access control layer. Our ABE implementation
-            requires two third party libraries: libpbc and libgabe. While we could merge
-            libgabe into the gnunet service implementation of re:claimID, libpbc is a
-            rather large, third party library which lacks packaging in distributions and
-            for platforms.
-            On the other hand, GNS supports record data encryption using symmetric keys as
-            labels.
-            If we make the access control layer of re:claimID more generic in order to
-            support both ABE and GNS encryption, we could reduce the required depenencies.
-            This would result in gnunet packages to include re:claimID by default.
-
+            Currently, the keys in our statistics database are too verbose.
+            For example:
+        </p>
+        <p>
+          nse # flood messages received: 13<br/>
+          nse # peers connected: 4<br/>
+          nse # nodes in the network (estimate): 203<br/>
+          nse # flood messages started: 5<br/>
+          nse # estimated network diameter: 3<br/>
+          nse # flood messages transmitted: 10<br/>
+        </p>
+        <p>
+           With such verbose keys there's no easy way to form compact JSON
+           document or entries for time-series database.
+           And you can't query single stats without having to copypaste the line
+           exactly and put in quotes.
             In short, the goals are to...
             <ol>
-              <li> ... improve performance by reducing encryption overhead.</li>
-              <li> ... reduce dependencies.</li>
+              <li>Thing of a way how statistics entries can be made canonical.</li>
+              <li>Implement the change and migrate existing uses.</li>
+              <li>Document the format(s) and define an appropriate registration mechanism for identifiers</li>
             </ol>
+            Relevant bugs: <a href="https://bugs.gnunet.org/view.php?id=5650">#5650</a>
             <br/>
             <strong>Mentors:</strong> Martin Schanzenbach
           {% endtrans %}
@@ -233,25 +234,6 @@
         </p>
       </section>
       <section>
-        <h4>RESTful GNUnet</h4>
-        <p>
-          {% trans %}
-            Design and implementation
-            of <a href="http://jsonapi.org/">REST APIs</a> that expose
-            the
-            <a href="https://docs.gnunet.org/doxygen/modules.html">GNUnet API</a>
-            so that easy, hands-on development is
-            possible. Also, browser-based UIs will be much easier to
-            create on top of REST APIs.
-          {% endtrans %}
-        </p>
-        <p>
-          {% trans %}
-            <strong>Mentors:</strong> Martin Schanzenbach
-          {% endtrans %}
-        </p>
-      </section>
-      <section>
         <h4>Rust implementation of GNUnet utils</h4>
         <p>
           {% trans %}