diff options
Diffstat (limited to 'template/gsoc.html.j2')
-rw-r--r-- | template/gsoc.html.j2 | 1170 |
1 files changed, 593 insertions, 577 deletions
diff --git a/template/gsoc.html.j2 b/template/gsoc.html.j2 index fdca054f..5104e516 100644 --- a/template/gsoc.html.j2 +++ b/template/gsoc.html.j2 | |||
@@ -1,594 +1,610 @@ | |||
1 | {% extends "common/base.j2" %} | 1 | {% extends "common/base.j2" %} |
2 | {% block body_content %} | 2 | {% block body_content %} |
3 | <article class="d-flex flex-column p-2 bd-highlight"> | 3 | <article class="container"> |
4 | <div class="container"> | ||
5 | <div class="text-center"> | ||
6 | <header> | ||
7 | <h1>{{ _("GNUnet's Google Summer of Code projects") }}</h1> | ||
8 | </header> | ||
9 | <p> | ||
10 | {% trans %} | ||
11 | As a GNU project, GNUnet has participated in the | ||
12 | Google Summer of Code (GSoC) for a number of years. | ||
13 | This page lists all current, past, and finished | ||
14 | projects. | ||
15 | {% endtrans %} | ||
16 | </p> | ||
17 | </div> | ||
18 | <h2>{{ _("Current projects (2019)") }}</h2> | ||
19 | <section> | ||
20 | <h4>Android Port</h4> | ||
21 | <p> | ||
22 | {% trans %} | ||
23 | It is time for GNUnet to run properly on Android. Note that | ||
24 | GNUnet is written in C, and this is not about rewriting | ||
25 | GNUnet in Java, but about getting the C code to run on Android. | ||
26 | {% endtrans %} | ||
27 | </p> | ||
28 | <p> | ||
29 | {% trans %} | ||
30 | <strong>Mentors:</strong> <a href="https://www.goebel-consult.de/">Hartmut Goebel</a> | ||
31 | {% endtrans %} | ||
32 | </p> | ||
33 | </section> | ||
34 | 4 | ||
35 | <section> | 5 | <header> |
36 | <h4>Help with Continuous Integration setup</h4> | 6 | <h1>{{ _("GNUnet's Google Summer of Code projects") }}</h1> |
37 | <p> | 7 | </header> |
38 | {% trans %} | ||
39 | There is a push for migrating our CI to Gitlab. The CI should | ||
40 | eventually not just run "make check" on various platforms, but also | ||
41 | perform tests with multiple peers running in different VMs with | ||
42 | specific network topologies (i.e. NAT) between them being simulated. | ||
43 | The CI should also be integrated with Gauger for performance | ||
44 | regression analysis. Running jobs only when dependencies have changed | ||
45 | and scripting more granular triggers or ideally automatic dependency | ||
46 | discovery (as done by the autotools) is also important. | ||
47 | {% endtrans %} | ||
48 | </p> | ||
49 | <p> | ||
50 | {% trans %} | ||
51 | <strong>Mentors:</strong> TBD | ||
52 | {% endtrans %} | ||
53 | </p> | ||
54 | </section> | ||
55 | 8 | ||
56 | <section> | 9 | <div class="row"> |
57 | <h4>Migrate gnunet-qr from Python 2.7 to C using libzbar</h4> | 10 | <div class="col-2 d-none d-lg-block"><!-- for large viewports show menu for better orientation --> |
58 | <p> | 11 | <nav class="nav subnav position-fixed flex-column border-right" style="position:fixed"> |
59 | {% trans %} | 12 | <a class="nav-link" href="#current">{{ _("Current projects") }}</a> |
60 | Python 2.7 is reaching its end-of-life, and we want to get rid | 13 | <a class="nav-link" href="#past">{{ _("Past projects") }}</a> |
61 | of the dependency on Python. The existing gnunet-qr tool is a | 14 | <a class="nav-link" href="#finished">{{ _("Finished projects") }}</a> |
62 | rather simple wrapper around python-zbar, which itself wraps | 15 | </nav> |
63 | libzbar. The goal of this project is to directly use libzbar | 16 | </div> |
64 | to scan QR codes for GNUnet / the GNU Name System (see | 17 | <div class="col"> |
65 | also <a href="https://bugs.gnunet.org/view.php?id=5562">#5562</a>). | 18 | |
66 | <br> | 19 | <section> |
67 | <strong>Mentors:</strong> Christian Grothoff | 20 | <p> |
68 | {% endtrans %} | 21 | {% trans %} |
69 | </p> | 22 | As a GNU project, GNUnet has participated in the |
70 | </section> | 23 | Google Summer of Code (GSoC) for a number of years. |
24 | This page lists all current, past, and finished | ||
25 | projects. | ||
26 | {% endtrans %} | ||
27 | </p> | ||
28 | </section> | ||
71 | 29 | ||
72 | <section> | ||
73 | <h4>re:claimID OpenID Connect performance improvements</h4> | ||
74 | <p> | ||
75 | {% trans %} | ||
76 | reclaimID is a decentralized identity system build on top of the GNU | ||
77 | Name System. | ||
78 | Upon authorization, the user provides a requesting party (RP) such as a website | ||
79 | with an authorization ticket (e.g. piggybacked in an OpenID authorization code). | ||
80 | The RP uses information contained in this ticket to | ||
81 | <ol> | ||
82 | <li> Retrieve the decryption key from GNS</li> | ||
83 | <li> Retrieve the user attributes from GNS</li> | ||
84 | </ol> | ||
85 | The GNS lookups ensure that the RP receives up-to-date attributes and functional | ||
86 | decryption keys. However, in particular the RP-specific encryption key | ||
87 | resolution can be slow and even fail depending on the network topology. | ||
88 | We propose that in an initial exchange, in particular OpenID authorization code | ||
89 | flows, we try to incorporate key and maybe even an attribute set in the ticket | ||
90 | exchange. | ||
91 | 30 | ||
92 | In order to mitigate this issue, this project is meant to investigate and implement how... | 31 | <h2><a name="current" class="subnav-anchor"></a>{{ _("Current projects (2019)") }}</h2> |
93 | <ol> | 32 | <section> |
94 | <li> ... decryption keys can be added to an initial exchange in OpenID.</li> | 33 | <h4>Android Port</h4> |
95 | <li> ... initial set(s) of attributes can be piggybacked in OpenID.</li> | 34 | <p> |
96 | </ol> | 35 | {% trans %} |
97 | <br/> | 36 | It is time for GNUnet to run properly on Android. Note that |
98 | <strong>Mentors:</strong> Martin Schanzenbach | 37 | GNUnet is written in C, and this is not about rewriting |
99 | {% endtrans %} | 38 | GNUnet in Java, but about getting the C code to run on Android. |
100 | </p> | 39 | {% endtrans %} |
101 | </section> | 40 | </p> |
41 | <p> | ||
42 | {% trans %} | ||
43 | <strong>Mentors:</strong> <a href="https://www.goebel-consult.de/">Hartmut Goebel</a> | ||
44 | {% endtrans %} | ||
45 | </p> | ||
46 | </section> | ||
102 | 47 | ||
103 | <section> | 48 | <section> |
104 | <h4>re:claimID alternative GNS-based encryption</h4> | 49 | <h4>Help with Continuous Integration setup</h4> |
105 | <p> | 50 | <p> |
106 | {% trans %} | 51 | {% trans %} |
107 | re:claimID is a decentralized identity system build on top of the GNU | 52 | There is a push for migrating our CI to Gitlab. The CI should |
108 | Name System. | 53 | eventually not just run "make check" on various platforms, but also |
109 | The initial design and implementation of re:claimID includes an attribute-based | 54 | perform tests with multiple peers running in different VMs with |
110 | encryption module in order to prevent unauthorized access to attributes in the | 55 | specific network topologies (i.e. NAT) between them being simulated. |
111 | name system. | 56 | The CI should also be integrated with Gauger for performance |
112 | Our motivation for re:claimID was for it to be name system agnostic, which | 57 | regression analysis. Running jobs only when dependencies have changed |
113 | means the design theoretically also works for other name systems such as | 58 | and scripting more granular triggers or ideally automatic dependency |
114 | namecoin. | 59 | discovery (as done by the autotools) is also important. |
115 | Other name systems often do not have built-in mechanisms in order to do this. | 60 | {% endtrans %} |
116 | Hence, we implemented an ABE access control layer. Our ABE implementation | 61 | </p> |
117 | requires two third party libraries: libpbc and libgabe. While we could merge | 62 | <p> |
118 | libgabe into the gnunet service implementation of re:claimID, libpbc is a | 63 | {% trans %} |
119 | rather large, third party library which lacks packaging in distributions and | 64 | <strong>Mentors:</strong> TBD |
120 | for platforms. | 65 | {% endtrans %} |
121 | On the other hand, GNS supports record data encryption using symmetric keys as | 66 | </p> |
122 | labels. | 67 | </section> |
123 | If we make the access control layer of re:claimID more generic in order to | ||
124 | support both ABE and GNS encryption, we could reduce the required depenencies. | ||
125 | This would result in gnunet packages to include re:claimID by default. | ||
126 | 68 | ||
127 | In short, the goals are to... | 69 | <section> |
128 | <ol> | 70 | <h4>Migrate gnunet-qr from Python 2.7 to C using libzbar</h4> |
129 | <li> ... improve performance by reducing encryption overhead.</li> | 71 | <p> |
130 | <li> ... reduce dependencies.</li> | 72 | {% trans %} |
131 | </ol> | 73 | Python 2.7 is reaching its end-of-life, and we want to get rid |
132 | <br/> | 74 | of the dependency on Python. The existing gnunet-qr tool is a |
133 | <strong>Mentors:</strong> Martin Schanzenbach | 75 | rather simple wrapper around python-zbar, which itself wraps |
134 | {% endtrans %} | 76 | libzbar. The goal of this project is to directly use libzbar |
135 | </p> | 77 | to scan QR codes for GNUnet / the GNU Name System (see |
136 | </section> | 78 | also <a href="https://bugs.gnunet.org/view.php?id=5562">#5562</a>). |
79 | <br> | ||
80 | <strong>Mentors:</strong> Christian Grothoff | ||
81 | {% endtrans %} | ||
82 | </p> | ||
83 | </section> | ||
137 | 84 | ||
138 | <section> | 85 | <section> |
139 | <h4>Enable all networking applications to run over GNUnet out of the box</h4> | 86 | <h4>re:claimID OpenID Connect performance improvements</h4> |
140 | <p> | 87 | <p> |
141 | {% trans %} | ||
142 | One great problem of the current Internet is the lack of | ||
143 | disintermediation. When people want to talk they need a | ||
144 | chat service. When they want to share files they need a | ||
145 | file transfer service. Although GNUnet already possesses | ||
146 | quite advanced integration into Linux networking, a little | ||
147 | extra work is needed for existing applications like irc, | ||
148 | www, ftp, rsh, nntpd to run over it in a peer-to-peer way, | ||
149 | simply by using a GNS hostname like friend.gnu. Once | ||
150 | people have added a person to their GNS they can | ||
151 | immediately message, exchange files and suchlike directly, | ||
152 | with nothing but the GNUnet in the middle, using | ||
153 | applications that have been distributed with unix systems | ||
154 | ever since the 1980's. We can produce an OS distribution | ||
155 | where these things work out of the box with the nicknames | ||
156 | of people instead of cloud services. For more information | ||
157 | and context, read | ||
158 | {% endtrans %} | ||
159 | <a href="https://bugs.gnunet.org/view.php?id=4625">bug id 4625</a>. | ||
160 | </p> | ||
161 | <p> | ||
162 | {% trans %} | ||
163 | <strong>Mentors:</strong> lynX & dvn | ||
164 | {% endtrans %} | ||
165 | </p> | ||
166 | </section> | ||
167 | <!-- Past projects: Previously proposed, but left unfinished. Inspiration for students. --> | ||
168 | <h2>{{ _("Past projects") }}</h2> | ||
169 | <section> | ||
170 | <h4>Rust APIs for GNUnet services</h4> | ||
171 | <p> | ||
172 | {% trans %} | ||
173 | There are a variety of GNUNet APIs that should be | ||
174 | exposed in the Rust wrappers. Implementing these will | ||
175 | require extending the port of GNUNet utils written by | ||
176 | Andrew Cann and Kelong Cong. | ||
177 | {% endtrans %} | ||
178 | </p> | ||
179 | <p> | ||
180 | {% trans %} | ||
181 | As an introduction to the code base, we suggest that the | ||
182 | student and Jeff Burdges together update the | ||
183 | asynchronous IO system from gjio to futures-rs or | ||
184 | another layer built upon it. Jeff Burdges is expected | ||
185 | to concurrently be implementing a GNUNet API for his own | ||
186 | mix network work. | ||
187 | {% endtrans %} | ||
188 | </p> | ||
189 | <p> | ||
190 | {% trans %} | ||
191 | <strong>Mentors:</strong> Jeff Burdges | ||
192 | {% endtrans %} | ||
193 | </p> | ||
194 | <p> | ||
195 | {% trans %} | ||
196 | Required Skills: Rust | ||
197 | {% endtrans %} | ||
198 | </p> | ||
199 | <p> | ||
200 | {% trans %} | ||
201 | Difficulty level: low | ||
202 | {% endtrans %} | ||
203 | </p> | ||
204 | </section> | ||
205 | <section> | ||
206 | <h4>Tor compatibility for GNUnet</h4> | ||
207 | <p> | ||
208 | {% trans %} | ||
209 | Implement the AnycastExit spec to enable GNUnet clients | ||
210 | to connect over Tor. | ||
211 | {% endtrans %} | ||
212 | </p> | ||
213 | <p> | ||
214 | {% trans %} | ||
215 | <strong>Mentors:</strong> Jeff Burdges | ||
216 | {% endtrans %} | ||
217 | </p> | ||
218 | <p> | ||
219 | {% trans %} | ||
220 | Note: There was a Special TLDs spec to allow Tor to | ||
221 | resolve domain names using GNS over Tor too, but | ||
222 | currently that's on hold until folks think more about | ||
223 | how names should be moved around the local system. We're | ||
224 | calling this more collaborative approach NSS2 for now. | ||
225 | {% endtrans %} | ||
226 | </p> | ||
227 | <p> | ||
228 | {% trans %} | ||
229 | Required Skills: C | ||
230 | {% endtrans %} | ||
231 | </p> | ||
232 | <p> | ||
233 | {% trans %} | ||
234 | Difficulty level: medium | ||
235 | {% endtrans %} | ||
236 | </p> | ||
237 | </section> | ||
238 | <section> | ||
239 | <h4>RESTful GNUnet</h4> | ||
240 | <p> | ||
241 | {% trans %} | ||
242 | Design and implementation | ||
243 | of <a href="http://jsonapi.org/">REST APIs</a> that expose | ||
244 | the | ||
245 | <a href="https://gnunet.org/doxygen/modules.html">GNUnet API</a> | ||
246 | so that easy, hands-on development is | ||
247 | possible. Also, browser-based UIs will be much easier to | ||
248 | create on top of REST APIs. | ||
249 | {% endtrans %} | ||
250 | </p> | ||
251 | <p> | ||
252 | {% trans %} | ||
253 | <strong>Mentors:</strong> Martin Schanzenbach | ||
254 | {% endtrans %} | ||
255 | </p> | ||
256 | </section> | ||
257 | <section> | ||
258 | <h4>Rust implementation of GNUnet utils</h4> | ||
259 | <p> | ||
260 | {% trans %} | ||
261 | Improve the Rust implementation of GNUnet utils, possibly | ||
262 | including adding support for asynchronous IO using mio, or | ||
263 | perhaps a higher level asynchronous IO library built upon | ||
264 | it, such as rotor, mioco, eventual_io, or gj. | ||
265 | {% endtrans %} | ||
266 | </p> | ||
267 | <p> | ||
268 | {% trans %} | ||
269 | <strong>Mentors:</strong> Jeff Burdges | ||
270 | {% endtrans %} | ||
271 | </p> | ||
272 | </section> | ||
273 | <section> | ||
274 | <h4>Android compatibility for GNUnet</h4> | ||
275 | <p> | ||
276 | {% trans %} | ||
277 | Implement rudimentary Android compatibility for GNUnet, | ||
278 | in part by porting the GNUnet utils scheduler to act as | ||
279 | a thin wrapper over libuv. | ||
280 | {% endtrans %} | ||
281 | </p> | ||
282 | <p> | ||
283 | {% trans %} | ||
284 | <strong>Mentors:</strong> Jeff Burdges and Christian Grothoff | ||
285 | {% endtrans %} | ||
286 | </p> | ||
287 | </section> | ||
288 | <section> | ||
289 | <h4>Implementation of a replacement for PANDA</h4> | ||
290 | <p> | ||
291 | {% trans %} | ||
292 | Implementation of a replacement for PANDA (see Pond) | ||
293 | with better security, and maybe integration with the GNU | ||
294 | Name System for key exchange. | ||
295 | {% endtrans %} | ||
296 | </p> | ||
297 | <p> | ||
298 | {% trans %} | ||
299 | <strong>Mentors:</strong> Jeff Burdges | ||
300 | {% endtrans %} | ||
301 | </p> | ||
302 | <p> | ||
303 | {% trans %} | ||
304 | Required Skills: Rust or C, crypto | ||
305 | {% endtrans %} | ||
306 | </p> | ||
307 | <p> | ||
308 | {% trans %} | ||
309 | Difficulty level: high | ||
310 | {% endtrans %} | ||
311 | </p> | ||
312 | </section> | ||
313 | <section> | ||
314 | <h4>secushare: Implement social networking features on top of pubsub channels</h4> | ||
315 | <p> | ||
316 | {% trans %} | ||
317 | Implement different place types and file sharing by | ||
318 | creating a new place for the shared content. | ||
319 | {% endtrans %} | ||
320 | </p> | ||
321 | <p> | ||
322 | {% trans %} | ||
323 | Place types to be implemented: | ||
324 | {% endtrans %} | ||
325 | </p> | ||
326 | {% trans %} | 88 | {% trans %} |
327 | <ul> | 89 | reclaimID is a decentralized identity system build on top of the GNU |
328 | <li>File: generic file with comments</li> | 90 | Name System. |
329 | <li>Image: display an image with comments referencing a region of the image</li> | 91 | Upon authorization, the user provides a requesting party (RP) such as a website |
330 | <li>Sound: play a sound file with comments referencing a timestamp</li> | 92 | with an authorization ticket (e.g. piggybacked in an OpenID authorization code). |
331 | <li>Directory/Album: pointers to File / Image / Sound places</li> | 93 | The RP uses information contained in this ticket to |
332 | <li>Event: with RSVP</li> | 94 | <ol> |
333 | <li>Survey: ask your social neighborhood questions in a structured form</li> | 95 | <li> Retrieve the decryption key from GNS</li> |
334 | </ul> | 96 | <li> Retrieve the user attributes from GNS</li> |
97 | </ol> | ||
98 | The GNS lookups ensure that the RP receives up-to-date attributes and functional | ||
99 | decryption keys. However, in particular the RP-specific encryption key | ||
100 | resolution can be slow and even fail depending on the network topology. | ||
101 | We propose that in an initial exchange, in particular OpenID authorization code | ||
102 | flows, we try to incorporate key and maybe even an attribute set in the ticket | ||
103 | exchange. | ||
104 | |||
105 | In order to mitigate this issue, this project is meant to investigate and implement how... | ||
106 | <ol> | ||
107 | <li> ... decryption keys can be added to an initial exchange in OpenID.</li> | ||
108 | <li> ... initial set(s) of attributes can be piggybacked in OpenID.</li> | ||
109 | </ol> | ||
110 | <br/> | ||
111 | <strong>Mentors:</strong> Martin Schanzenbach | ||
112 | {% endtrans %} | ||
113 | </p> | ||
114 | </section> | ||
115 | |||
116 | <section> | ||
117 | <h4>re:claimID alternative GNS-based encryption</h4> | ||
118 | <p> | ||
119 | {% trans %} | ||
120 | re:claimID is a decentralized identity system build on top of the GNU | ||
121 | Name System. | ||
122 | The initial design and implementation of re:claimID includes an attribute-based | ||
123 | encryption module in order to prevent unauthorized access to attributes in the | ||
124 | name system. | ||
125 | Our motivation for re:claimID was for it to be name system agnostic, which | ||
126 | means the design theoretically also works for other name systems such as | ||
127 | namecoin. | ||
128 | Other name systems often do not have built-in mechanisms in order to do this. | ||
129 | Hence, we implemented an ABE access control layer. Our ABE implementation | ||
130 | requires two third party libraries: libpbc and libgabe. While we could merge | ||
131 | libgabe into the gnunet service implementation of re:claimID, libpbc is a | ||
132 | rather large, third party library which lacks packaging in distributions and | ||
133 | for platforms. | ||
134 | On the other hand, GNS supports record data encryption using symmetric keys as | ||
135 | labels. | ||
136 | If we make the access control layer of re:claimID more generic in order to | ||
137 | support both ABE and GNS encryption, we could reduce the required depenencies. | ||
138 | This would result in gnunet packages to include re:claimID by default. | ||
139 | |||
140 | In short, the goals are to... | ||
141 | <ol> | ||
142 | <li> ... improve performance by reducing encryption overhead.</li> | ||
143 | <li> ... reduce dependencies.</li> | ||
144 | </ol> | ||
145 | <br/> | ||
146 | <strong>Mentors:</strong> Martin Schanzenbach | ||
147 | {% endtrans %} | ||
148 | </p> | ||
149 | </section> | ||
150 | |||
151 | <section> | ||
152 | <h4>Enable all networking applications to run over GNUnet out of the box</h4> | ||
153 | <p> | ||
154 | {% trans %} | ||
155 | One great problem of the current Internet is the lack of | ||
156 | disintermediation. When people want to talk they need a | ||
157 | chat service. When they want to share files they need a | ||
158 | file transfer service. Although GNUnet already possesses | ||
159 | quite advanced integration into Linux networking, a little | ||
160 | extra work is needed for existing applications like irc, | ||
161 | www, ftp, rsh, nntpd to run over it in a peer-to-peer way, | ||
162 | simply by using a GNS hostname like friend.gnu. Once | ||
163 | people have added a person to their GNS they can | ||
164 | immediately message, exchange files and suchlike directly, | ||
165 | with nothing but the GNUnet in the middle, using | ||
166 | applications that have been distributed with unix systems | ||
167 | ever since the 1980's. We can produce an OS distribution | ||
168 | where these things work out of the box with the nicknames | ||
169 | of people instead of cloud services. For more information | ||
170 | and context, read | ||
171 | {% endtrans %} | ||
172 | <a href="https://bugs.gnunet.org/view.php?id=4625">bug id 4625</a>. | ||
173 | </p> | ||
174 | <p> | ||
175 | {% trans %} | ||
176 | <strong>Mentors:</strong> lynX & dvn | ||
177 | {% endtrans %} | ||
178 | </p> | ||
179 | </section> | ||
180 | <!-- Past projects: Previously proposed, but left unfinished. Inspiration for students. --> | ||
181 | <h2><a name="past" class="subnav-anchor"></a>{{ _("Past projects") }}</h2> | ||
182 | <section> | ||
183 | <h4>Rust APIs for GNUnet services</h4> | ||
184 | <p> | ||
185 | {% trans %} | ||
186 | There are a variety of GNUNet APIs that should be | ||
187 | exposed in the Rust wrappers. Implementing these will | ||
188 | require extending the port of GNUNet utils written by | ||
189 | Andrew Cann and Kelong Cong. | ||
190 | {% endtrans %} | ||
191 | </p> | ||
192 | <p> | ||
193 | {% trans %} | ||
194 | As an introduction to the code base, we suggest that the | ||
195 | student and Jeff Burdges together update the | ||
196 | asynchronous IO system from gjio to futures-rs or | ||
197 | another layer built upon it. Jeff Burdges is expected | ||
198 | to concurrently be implementing a GNUNet API for his own | ||
199 | mix network work. | ||
200 | {% endtrans %} | ||
201 | </p> | ||
202 | <p> | ||
203 | {% trans %} | ||
204 | <strong>Mentors:</strong> Jeff Burdges | ||
205 | {% endtrans %} | ||
206 | </p> | ||
207 | <p> | ||
208 | {% trans %} | ||
209 | Required Skills: Rust | ||
210 | {% endtrans %} | ||
211 | </p> | ||
212 | <p> | ||
213 | {% trans %} | ||
214 | Difficulty level: low | ||
215 | {% endtrans %} | ||
216 | </p> | ||
217 | </section> | ||
218 | <section> | ||
219 | <h4>Tor compatibility for GNUnet</h4> | ||
220 | <p> | ||
221 | {% trans %} | ||
222 | Implement the AnycastExit spec to enable GNUnet clients | ||
223 | to connect over Tor. | ||
224 | {% endtrans %} | ||
225 | </p> | ||
226 | <p> | ||
227 | {% trans %} | ||
228 | <strong>Mentors:</strong> Jeff Burdges | ||
229 | {% endtrans %} | ||
230 | </p> | ||
231 | <p> | ||
232 | {% trans %} | ||
233 | Note: There was a Special TLDs spec to allow Tor to | ||
234 | resolve domain names using GNS over Tor too, but | ||
235 | currently that's on hold until folks think more about | ||
236 | how names should be moved around the local system. We're | ||
237 | calling this more collaborative approach NSS2 for now. | ||
238 | {% endtrans %} | ||
239 | </p> | ||
240 | <p> | ||
241 | {% trans %} | ||
242 | Required Skills: C | ||
243 | {% endtrans %} | ||
244 | </p> | ||
245 | <p> | ||
246 | {% trans %} | ||
247 | Difficulty level: medium | ||
248 | {% endtrans %} | ||
249 | </p> | ||
250 | </section> | ||
251 | <section> | ||
252 | <h4>RESTful GNUnet</h4> | ||
253 | <p> | ||
254 | {% trans %} | ||
255 | Design and implementation | ||
256 | of <a href="http://jsonapi.org/">REST APIs</a> that expose | ||
257 | the | ||
258 | <a href="https://gnunet.org/doxygen/modules.html">GNUnet API</a> | ||
259 | so that easy, hands-on development is | ||
260 | possible. Also, browser-based UIs will be much easier to | ||
261 | create on top of REST APIs. | ||
262 | {% endtrans %} | ||
263 | </p> | ||
264 | <p> | ||
265 | {% trans %} | ||
266 | <strong>Mentors:</strong> Martin Schanzenbach | ||
267 | {% endtrans %} | ||
268 | </p> | ||
269 | </section> | ||
270 | <section> | ||
271 | <h4>Rust implementation of GNUnet utils</h4> | ||
272 | <p> | ||
273 | {% trans %} | ||
274 | Improve the Rust implementation of GNUnet utils, possibly | ||
275 | including adding support for asynchronous IO using mio, or | ||
276 | perhaps a higher level asynchronous IO library built upon | ||
277 | it, such as rotor, mioco, eventual_io, or gj. | ||
278 | {% endtrans %} | ||
279 | </p> | ||
280 | <p> | ||
281 | {% trans %} | ||
282 | <strong>Mentors:</strong> Jeff Burdges | ||
283 | {% endtrans %} | ||
284 | </p> | ||
285 | </section> | ||
286 | <section> | ||
287 | <h4>Android compatibility for GNUnet</h4> | ||
288 | <p> | ||
289 | {% trans %} | ||
290 | Implement rudimentary Android compatibility for GNUnet, | ||
291 | in part by porting the GNUnet utils scheduler to act as | ||
292 | a thin wrapper over libuv. | ||
293 | {% endtrans %} | ||
294 | </p> | ||
295 | <p> | ||
296 | {% trans %} | ||
297 | <strong>Mentors:</strong> Jeff Burdges and Christian Grothoff | ||
298 | {% endtrans %} | ||
299 | </p> | ||
300 | </section> | ||
301 | <section> | ||
302 | <h4>Implementation of a replacement for PANDA</h4> | ||
303 | <p> | ||
304 | {% trans %} | ||
305 | Implementation of a replacement for PANDA (see Pond) | ||
306 | with better security, and maybe integration with the GNU | ||
307 | Name System for key exchange. | ||
308 | {% endtrans %} | ||
309 | </p> | ||
310 | <p> | ||
311 | {% trans %} | ||
312 | <strong>Mentors:</strong> Jeff Burdges | ||
313 | {% endtrans %} | ||
314 | </p> | ||
315 | <p> | ||
316 | {% trans %} | ||
317 | Required Skills: Rust or C, crypto | ||
318 | {% endtrans %} | ||
319 | </p> | ||
320 | <p> | ||
321 | {% trans %} | ||
322 | Difficulty level: high | ||
323 | {% endtrans %} | ||
324 | </p> | ||
325 | </section> | ||
326 | <section> | ||
327 | <h4>secushare: Implement social networking features on top of pubsub channels</h4> | ||
328 | <p> | ||
329 | {% trans %} | ||
330 | Implement different place types and file sharing by | ||
331 | creating a new place for the shared content. | ||
332 | {% endtrans %} | ||
333 | </p> | ||
334 | <p> | ||
335 | {% trans %} | ||
336 | Place types to be implemented: | ||
337 | {% endtrans %} | ||
338 | </p> | ||
339 | {% trans %} | ||
340 | <ul> | ||
341 | <li>File: generic file with comments</li> | ||
342 | <li>Image: display an image with comments referencing a region of the image</li> | ||
343 | <li>Sound: play a sound file with comments referencing a timestamp</li> | ||
344 | <li>Directory/Album: pointers to File / Image / Sound places</li> | ||
345 | <li>Event: with RSVP</li> | ||
346 | <li>Survey: ask your social neighborhood questions in a structured form</li> | ||
347 | </ul> | ||
348 | {% endtrans %} | ||
349 | <p> | ||
350 | {% trans %} | ||
351 | Also provide the following UI functionality: | ||
352 | {% endtrans %} | ||
353 | </p> | ||
354 | {% trans %} | ||
355 | <ul> | ||
356 | <li>Fork existing channels, reorganize people into new chatrooms or channels.</li> | ||
357 | <li>Share a post (edit and repost something elsewhere, on a fan page for example).</li> | ||
358 | <li>Edit a previously published post + offer edit history to readers.</li> | ||
359 | <li>Control expiry of channel history.</li> | ||
360 | </ul> | ||
361 | {% endtrans %} | ||
362 | <p> | ||
363 | {% trans %} | ||
364 | See also <a href="http://secushare.org/features">http://secushare.org/features</a> | ||
365 | {% endtrans %} | ||
366 | </p> | ||
367 | <p> | ||
368 | {% trans %} | ||
369 | <strong>Mentors:</strong> lynX | ||
370 | {% endtrans %} | ||
371 | </p> | ||
372 | <p> | ||
373 | {% trans %} | ||
374 | Required Skills: C/C++ | ||
375 | {% endtrans %} | ||
376 | </p> | ||
377 | <p> | ||
378 | {% trans %} | ||
379 | Difficulty level: high | ||
380 | {% endtrans %} | ||
381 | </p> | ||
382 | </section> | ||
383 | <section> | ||
384 | <h4>secushare: Implement a Social Graph API for contact adoption and more</h4> | ||
385 | <p> | ||
386 | {% trans %} | ||
387 | Implement aggregation of distributed state from | ||
388 | various channels | ||
389 | in order to provide for a powerful social graph API capable of | ||
390 | producing social network profiles, dashboards, | ||
391 | a calendar out of | ||
392 | upcoming event invitations (if available), | ||
393 | social search functionality | ||
394 | and most of all to make it easy for users to | ||
395 | adopt cryptographic | ||
396 | identities of their contacts/friends simply by finding | ||
397 | them in the | ||
398 | social graph of their | ||
399 | existing contacts ("This is Linda. You have 11 | ||
400 | contacts in common with her. [ADD]"). | ||
401 | {% endtrans %} | ||
402 | </p> | ||
403 | <p> | ||
404 | {% trans %} | ||
405 | Related to | ||
406 | <a href="http://secushare.org/rendezvous">secushare.org/rendezvous</a> | ||
407 | {% endtrans %} | ||
408 | </p> | ||
409 | <p> | ||
410 | {% trans %} | ||
411 | <strong>Mentors:</strong> t3sserakt, lynX | ||
412 | {% endtrans %} | ||
413 | </p> | ||
414 | <p> | ||
415 | {% trans %} | ||
416 | Required Skills: C | ||
335 | {% endtrans %} | 417 | {% endtrans %} |
336 | <p> | 418 | </p> |
337 | {% trans %} | 419 | <p> |
338 | Also provide the following UI functionality: | ||
339 | {% endtrans %} | ||
340 | </p> | ||
341 | {% trans %} | 420 | {% trans %} |
421 | Difficulty level: high | ||
422 | {% endtrans %} | ||
423 | </p> | ||
424 | </section> | ||
425 | <section> | ||
426 | <h4>secushare: Implement integration with tradition e-mail</h4> | ||
427 | {% trans %} | ||
342 | <ul> | 428 | <ul> |
343 | <li>Fork existing channels, reorganize people into new chatrooms or channels.</li> | 429 | <li> |
344 | <li>Share a post (edit and repost something elsewhere, on a fan page for example).</li> | 430 | Emulate IMAP/SMTP protocols as necessary to transform |
345 | <li>Edit a previously published post + offer edit history to readers.</li> | 431 | traditional mail clients into secushare user |
346 | <li>Control expiry of channel history.</li> | 432 | interfaces. |
433 | </li> | ||
434 | <li> | ||
435 | Think of ways to map e-mail addresses to secushare | ||
436 | identities. | ||
437 | </li> | ||
438 | <li> | ||
439 | Encode or translate various e-mail features into | ||
440 | secushare equivalents. | ||
441 | </li> | ||
442 | <li> | ||
443 | Parts of secushare are currently written in Rust, | ||
444 | therefore Rust is preferred for this task but it is | ||
445 | not an requirement. | ||
446 | </li> | ||
347 | </ul> | 447 | </ul> |
448 | {% endtrans %} | ||
449 | <p> | ||
450 | {% trans %} | ||
451 | <strong>Mentors:</strong> t3sserakt, lynX | ||
452 | {% endtrans %} | ||
453 | </p> | ||
454 | <p> | ||
455 | {% trans %} | ||
456 | Required Skills: C | ||
457 | {% endtrans %} | ||
458 | </p> | ||
459 | <p> | ||
460 | {% trans %} | ||
461 | Difficulty level: high | ||
462 | {% endtrans %} | ||
463 | </p> | ||
464 | </section> | ||
465 | <section> | ||
466 | <h4>GNUnet auction</h4> | ||
467 | <p> | ||
468 | {% trans %} | ||
469 | Implementation of the GNUnet auction system described in | ||
470 | Chapter 3 of | ||
471 | <a href="https://gnunet.org/libbrand-thesis">this thesis</a>. | ||
472 | Specific tasks are adding smart | ||
473 | contract creation and round time enforcement to | ||
474 | libbrandt as well as creating the | ||
475 | GNUnet auction service, library and the three user interface | ||
476 | programs create, info and join. | ||
477 | {% endtrans %} | ||
478 | </p> | ||
479 | <p> | ||
480 | {% trans %} | ||
481 | <strong>Mentors:</strong> mate, cg | ||
482 | {% endtrans %} | ||
483 | </p> | ||
484 | <p> | ||
485 | {% trans %} | ||
486 | Required Skills: C | ||
487 | {% endtrans %} | ||
488 | </p> | ||
489 | <p> | ||
490 | {% trans %} | ||
491 | Difficulty level: medium | ||
492 | {% endtrans %} | ||
493 | </p> | ||
494 | </section> | ||
495 | <section> | ||
496 | <h4>Implementation of additional transports</h4> | ||
497 | <p> | ||
498 | {% trans %} | ||
499 | Implementation of additional transports to make GNUnet communication | ||
500 | more robust in the presence of problematic networks: | ||
501 | GNUnet-over-SMTP, GNUnet-over-DNS | ||
502 | {% endtrans %} | ||
503 | </p> | ||
504 | <p> | ||
505 | {% trans %} | ||
506 | <strong>Mentors:</strong> Matthias Wachs | ||
507 | {% endtrans %} | ||
508 | </p> | ||
509 | </section> | ||
510 | <section> | ||
511 | <h4>Implementation of ALG-based NAT traversal methods</h4> | ||
512 | <p> | ||
513 | {% trans %} | ||
514 | Implementation of ALG-based NAT traversal methods (FTP/SIP-based hole | ||
515 | punching, better STUN support) | ||
516 | {% endtrans %} | ||
517 | </p> | ||
518 | <p> | ||
519 | {% trans %} | ||
520 | <strong>Mentors:</strong> Matthias Wachs | ||
521 | {% endtrans %} | ||
522 | </p> | ||
523 | </section> | ||
524 | <section> | ||
525 | <h4>Integration of the GNU Name System with GnuPG</h4> | ||
526 | <p> | ||
527 | {% trans %} | ||
528 | <strong>Mentors:</strong> Matthias Wachs, Christian Grothoff, Jeff Burdges | ||
529 | {% endtrans %} | ||
530 | </p> | ||
531 | </section> | ||
532 | <section> | ||
533 | <h4>libaboss improvements</h4> | ||
534 | <p> | ||
535 | {% trans %} | ||
536 | Improving libaboss to make computation on shared secrets (including | ||
537 | repeated multiplication) based | ||
538 | on <a href="https://dl.acm.org/citation.cfm?doid=62212.62213">Ben-Or | ||
539 | et al.</a> if possible. This in particular means moving libaboss to | ||
540 | bignums (gcry_mpi). | ||
541 | {% endtrans %} | ||
542 | </p> | ||
543 | <p><strong>Mentors:</strong> Krista Grothoff, Jeff Burdges</p> | ||
544 | </section> | ||
545 | <section> | ||
546 | <h4>Implementation of a replacement for PANDA</h4> | ||
547 | <p> | ||
548 | {% trans %} | ||
549 | Implementation of a replacement for PANDA (see Pond) with better | ||
550 | security, and maybe integration with the GNU Name System for key | ||
551 | exchange. | ||
552 | {% endtrans %} | ||
553 | </p> | ||
554 | <p> | ||
555 | {% trans %} | ||
556 | <strong>Mentors:</strong> Jeff Burdges | ||
557 | {% endtrans %} | ||
558 | </p> | ||
559 | </section> | ||
560 | <section> | ||
561 | <h4>Supporting GNU Guix's package distribution</h4> | ||
562 | <p> | ||
563 | {% trans %} | ||
564 | Please refer to the description for this project listed under | ||
565 | GNU Guix project ideas. | ||
566 | {% endtrans %} | ||
567 | </p> | ||
568 | </section> | ||
569 | <h2><a name="finished" class="subnav-anchor"></a>{{ _("Finished projects") }}</h2> | ||
570 | <!-- Commentary: Finished projects, descriptions and Links to write-ups about them. --> | ||
571 | <h3>2018</h3> | ||
572 | <section> | ||
573 | <h4>GNUnet Web-based User Interface</h4> | ||
574 | <p> | ||
575 | {% trans %} | ||
576 | Implementation of a Web-based UI for GNUnet similar to | ||
577 | GNUnet-Gtk with a yet to be determined framework such as | ||
578 | Angular2. This includes the design and implementation of | ||
579 | not yet existing <a href="http://jsonapi.org/">REST APIs</a> | ||
580 | that expose the | ||
581 | <a href="https://gnunet.org/doxygen/modules.html">GNUnet API</a>. | ||
582 | {% endtrans %} | ||
583 | </p> | ||
584 | <p> | ||
585 | {% trans %} | ||
586 | <strong>Mentors:</strong> Martin Schanzenbach | ||
587 | {% endtrans %} | ||
588 | </p> | ||
589 | <p> | ||
590 | {% trans %} | ||
591 | Required Skills: C, JavaScript, CSS | ||
592 | {% endtrans %} | ||
593 | </p> | ||
594 | <p> | ||
595 | {% trans %} | ||
596 | Difficulty level: medium | ||
597 | {% endtrans %} | ||
598 | </p> | ||
599 | <p> | ||
600 | {% trans %} | ||
601 | Report: <a href="gsoc-2018-gnunet-webui.html">GSoC 2018: GNUnet WebUI</a> | ||
348 | {% endtrans %} | 602 | {% endtrans %} |
349 | <p> | 603 | </p> |
350 | {% trans %} | 604 | </section> |
351 | See also <a href="http://secushare.org/features">http://secushare.org/features</a> | 605 | |
352 | {% endtrans %} | ||
353 | </p> | ||
354 | <p> | ||
355 | {% trans %} | ||
356 | <strong>Mentors:</strong> lynX | ||
357 | {% endtrans %} | ||
358 | </p> | ||
359 | <p> | ||
360 | {% trans %} | ||
361 | Required Skills: C/C++ | ||
362 | {% endtrans %} | ||
363 | </p> | ||
364 | <p> | ||
365 | {% trans %} | ||
366 | Difficulty level: high | ||
367 | {% endtrans %} | ||
368 | </p> | ||
369 | </section> | ||
370 | <section> | ||
371 | <h4>secushare: Implement a Social Graph API for contact adoption and more</h4> | ||
372 | <p> | ||
373 | {% trans %} | ||
374 | Implement aggregation of distributed state from | ||
375 | various channels | ||
376 | in order to provide for a powerful social graph API capable of | ||
377 | producing social network profiles, dashboards, | ||
378 | a calendar out of | ||
379 | upcoming event invitations (if available), | ||
380 | social search functionality | ||
381 | and most of all to make it easy for users to | ||
382 | adopt cryptographic | ||
383 | identities of their contacts/friends simply by finding | ||
384 | them in the | ||
385 | social graph of their | ||
386 | existing contacts ("This is Linda. You have 11 | ||
387 | contacts in common with her. [ADD]"). | ||
388 | {% endtrans %} | ||
389 | </p> | ||
390 | <p> | ||
391 | {% trans %} | ||
392 | Related to | ||
393 | <a href="http://secushare.org/rendezvous">secushare.org/rendezvous</a> | ||
394 | {% endtrans %} | ||
395 | </p> | ||
396 | <p> | ||
397 | {% trans %} | ||
398 | <strong>Mentors:</strong> t3sserakt, lynX | ||
399 | {% endtrans %} | ||
400 | </p> | ||
401 | <p> | ||
402 | {% trans %} | ||
403 | Required Skills: C | ||
404 | {% endtrans %} | ||
405 | </p> | ||
406 | <p> | ||
407 | {% trans %} | ||
408 | Difficulty level: high | ||
409 | {% endtrans %} | ||
410 | </p> | ||
411 | </section> | ||
412 | <section> | ||
413 | <h4>secushare: Implement integration with tradition e-mail</h4> | ||
414 | {% trans %} | ||
415 | <ul> | ||
416 | <li> | ||
417 | Emulate IMAP/SMTP protocols as necessary to transform | ||
418 | traditional mail clients into secushare user | ||
419 | interfaces. | ||
420 | </li> | ||
421 | <li> | ||
422 | Think of ways to map e-mail addresses to secushare | ||
423 | identities. | ||
424 | </li> | ||
425 | <li> | ||
426 | Encode or translate various e-mail features into | ||
427 | secushare equivalents. | ||
428 | </li> | ||
429 | <li> | ||
430 | Parts of secushare are currently written in Rust, | ||
431 | therefore Rust is preferred for this task but it is | ||
432 | not an requirement. | ||
433 | </li> | ||
434 | </ul> | ||
435 | {% endtrans %} | ||
436 | <p> | ||
437 | {% trans %} | ||
438 | <strong>Mentors:</strong> t3sserakt, lynX | ||
439 | {% endtrans %} | ||
440 | </p> | ||
441 | <p> | ||
442 | {% trans %} | ||
443 | Required Skills: C | ||
444 | {% endtrans %} | ||
445 | </p> | ||
446 | <p> | ||
447 | {% trans %} | ||
448 | Difficulty level: high | ||
449 | {% endtrans %} | ||
450 | </p> | ||
451 | </section> | ||
452 | <section> | ||
453 | <h4>GNUnet auction</h4> | ||
454 | <p> | ||
455 | {% trans %} | ||
456 | Implementation of the GNUnet auction system described in | ||
457 | Chapter 3 of | ||
458 | <a href="https://gnunet.org/libbrand-thesis">this thesis</a>. | ||
459 | Specific tasks are adding smart | ||
460 | contract creation and round time enforcement to | ||
461 | libbrandt as well as creating the | ||
462 | GNUnet auction service, library and the three user interface | ||
463 | programs create, info and join. | ||
464 | {% endtrans %} | ||
465 | </p> | ||
466 | <p> | ||
467 | {% trans %} | ||
468 | <strong>Mentors:</strong> mate, cg | ||
469 | {% endtrans %} | ||
470 | </p> | ||
471 | <p> | ||
472 | {% trans %} | ||
473 | Required Skills: C | ||
474 | {% endtrans %} | ||
475 | </p> | ||
476 | <p> | ||
477 | {% trans %} | ||
478 | Difficulty level: medium | ||
479 | {% endtrans %} | ||
480 | </p> | ||
481 | </section> | ||
482 | <section> | ||
483 | <h4>Implementation of additional transports</h4> | ||
484 | <p> | ||
485 | {% trans %} | ||
486 | Implementation of additional transports to make GNUnet communication | ||
487 | more robust in the presence of problematic networks: | ||
488 | GNUnet-over-SMTP, GNUnet-over-DNS | ||
489 | {% endtrans %} | ||
490 | </p> | ||
491 | <p> | ||
492 | {% trans %} | ||
493 | <strong>Mentors:</strong> Matthias Wachs | ||
494 | {% endtrans %} | ||
495 | </p> | ||
496 | </section> | ||
497 | <section> | ||
498 | <h4>Implementation of ALG-based NAT traversal methods</h4> | ||
499 | <p> | ||
500 | {% trans %} | ||
501 | Implementation of ALG-based NAT traversal methods (FTP/SIP-based hole | ||
502 | punching, better STUN support) | ||
503 | {% endtrans %} | ||
504 | </p> | ||
505 | <p> | ||
506 | {% trans %} | ||
507 | <strong>Mentors:</strong> Matthias Wachs | ||
508 | {% endtrans %} | ||
509 | </p> | ||
510 | </section> | ||
511 | <section> | ||
512 | <h4>Integration of the GNU Name System with GnuPG</h4> | ||
513 | <p> | ||
514 | {% trans %} | ||
515 | <strong>Mentors:</strong> Matthias Wachs, Christian Grothoff, Jeff Burdges | ||
516 | {% endtrans %} | ||
517 | </p> | ||
518 | </section> | ||
519 | <section> | ||
520 | <h4>libaboss improvements</h4> | ||
521 | <p> | ||
522 | {% trans %} | ||
523 | Improving libaboss to make computation on shared secrets (including | ||
524 | repeated multiplication) based | ||
525 | on <a href="https://dl.acm.org/citation.cfm?doid=62212.62213">Ben-Or | ||
526 | et al.</a> if possible. This in particular means moving libaboss to | ||
527 | bignums (gcry_mpi). | ||
528 | {% endtrans %} | ||
529 | </p> | ||
530 | <p><strong>Mentors:</strong> Krista Grothoff, Jeff Burdges</p> | ||
531 | </section> | ||
532 | <section> | ||
533 | <h4>Implementation of a replacement for PANDA</h4> | ||
534 | <p> | ||
535 | {% trans %} | ||
536 | Implementation of a replacement for PANDA (see Pond) with better | ||
537 | security, and maybe integration with the GNU Name System for key | ||
538 | exchange. | ||
539 | {% endtrans %} | ||
540 | </p> | ||
541 | <p> | ||
542 | {% trans %} | ||
543 | <strong>Mentors:</strong> Jeff Burdges | ||
544 | {% endtrans %} | ||
545 | </p> | ||
546 | </section> | ||
547 | <section> | ||
548 | <h4>Supporting GNU Guix's package distribution</h4> | ||
549 | <p> | ||
550 | {% trans %} | ||
551 | Please refer to the description for this project listed under | ||
552 | GNU Guix project ideas. | ||
553 | {% endtrans %} | ||
554 | </p> | ||
555 | </section> | ||
556 | <h2>{{ _("Finished projects") }}</h2> | ||
557 | <!-- Commentary: Finished projects, descriptions and Links to write-ups about them. --> | ||
558 | <h3>2018</h3> | ||
559 | <section> | ||
560 | <h4>GNUnet Web-based User Interface</h4> | ||
561 | <p> | ||
562 | {% trans %} | ||
563 | Implementation of a Web-based UI for GNUnet similar to | ||
564 | GNUnet-Gtk with a yet to be determined framework such as | ||
565 | Angular2. This includes the design and implementation of | ||
566 | not yet existing <a href="http://jsonapi.org/">REST APIs</a> | ||
567 | that expose the | ||
568 | <a href="https://gnunet.org/doxygen/modules.html">GNUnet API</a>. | ||
569 | {% endtrans %} | ||
570 | </p> | ||
571 | <p> | ||
572 | {% trans %} | ||
573 | <strong>Mentors:</strong> Martin Schanzenbach | ||
574 | {% endtrans %} | ||
575 | </p> | ||
576 | <p> | ||
577 | {% trans %} | ||
578 | Required Skills: C, JavaScript, CSS | ||
579 | {% endtrans %} | ||
580 | </p> | ||
581 | <p> | ||
582 | {% trans %} | ||
583 | Difficulty level: medium | ||
584 | {% endtrans %} | ||
585 | </p> | ||
586 | <p> | ||
587 | {% trans %} | ||
588 | Report: <a href="gsoc-2018-gnunet-webui.html">GSoC 2018: GNUnet WebUI</a> | ||
589 | {% endtrans %} | ||
590 | </p> | ||
591 | </section> | ||
592 | </div> | 606 | </div> |
593 | </article> | 607 | </div> |
608 | |||
609 | </article> | ||
594 | {% endblock body_content %} | 610 | {% endblock body_content %} |