Re: [GNUnet-developers] GSoC

[carlo von lynX]

On 02/15/2016 12:11 PM, Martin Schanzenbach wrote:
> RESTful GNUnet
> 
> Design and implementation of REST APIs (http://jsonapi.org/) that
> expose the GNUnet API (https://gnunet.org/doxygen/modules.html) so that
> easy, hands-on development is possible. Also, browser-based UIs will be
> much easier to create on top of REST APIs.

Good one. I never liked HTTP abuse protocols but they reality of the
world seems to be that both web-apps and a lot of smartphone-apps are
built this way. This is also on the wishlist for secushare as it would
allow rapidly prototyped web UIs for the threaded mail system we are
working on right now as a preliminary goal towards a full social
network. Later we could possibly recycle existing web UIs like Diaspora.

The GNUnet social API is at a point that it can provide for a serverless
threaded mail and chat system, given that some people in the social
graph leave their nodes running. We are now working on a Qt-based UI but
doing a web-based one wouldn't be the wrongest of ideas.

A threaded mail/chat system means that it doesn't just do 1:1 mail, it
also provides forum/mailing list like behaviour and chatrooms all in one.
Current status apparently is that we only need the UI.

On 02/15/2016 03:41 PM, Jeff Burdges wrote:
> Rust implementation of GNUnet utils

Which languages do we already support this way?

> Tor compatibility for GNUnet
> 
> Implement the AnycastExit spec to enable GNUnet clients to connect over
> Tor.

This one is VERY interesting as well. I had a long conversation with
some folks who were designing a social network for Tor leading to the
idea of using Tor clients to access GNUnet/secushare in order to achieve
the multicast scalability that Tor does not provide necessary to host a
large scale social network.

https://lists.torproject.org/pipermail/tor-talk/2014-December/036252.html
https://lists.torproject.org/pipermail/tor-talk/2015-January/036288.html

I read your proposal closely but somehow still didn't grasp how exactly
it works.

> Android compatibility for GNUnet
> 
> Implement rudimentary Android compatibility for GNUnet, in part by
> porting the GNUnet utils scheduler to act as a thin wrapper over libuv.

Very relevant as well. Our secushare app uses a cross-platform library
suitable for running on Android, so if this was reality we could *poof*
be having a serverless mail and chat system for smartphones.

> Auto-pay tokens in Taler
> 
> Implement the auto-pay tokens specification for Taler.  Intended to
> help Tor users circumvent CloudFlare CAPTCHAs with CloudFlare's
> eventual cooperation.

Haha, lovely.

> Store integration for Taler merchants

Sounds legit.

> On Mon, 2016-02-15 at 08:51 +0100, Christian Grothoff wrote:
> 
>> Implementation of a replacement for PANDA
>>
>> Implementation of a replacement for PANDA (see Pond) with better
>> security, and maybe integration with the GNU Name System for key
>> exchange.
>>
>> Mentors: Jeff Burdges
> 
> I suppose this still makes sense.  Actually we know slightly more now.

But should we really insist on throwing money at the client/server
model? Pond has a terrible tendency to produce secret service honeypots
with all those people picking the very few default servers.
If we use the Tor-AnycastExit thing with secushare I don't think there
are many security properties that Pond offers that secushare doesn't
do better.

Still, whenever the social graph strategy for adopting contacts isn't
available or paranoid enough, a shared-secret based strategy can still
be useful (although people have proven to be really bad at adopting it!).
So I'm not entirely against a next generation PANDA, just
against insisting with Pond.

> On Mon, 2016-02-15 at 08:51 +0100, Christian Grothoff wrote:
>> Implementation of additional transports
>>
>> Implementation of additional transports to make GNUnet communication
>> more robust in the presence of problematic networks: GNUnet-over-
>> SMTP,
>> GNUnet-over-DNS
>>
>> Mentors: Matthias Wachs

Easy one, always good. Maybe also port the Tor Bridges subsystem to
GNUnet? Or just use it by turning the Tor router into a GNUnet client?

>> Implementation of ALG-based NAT traversal methods
>>
>> Implementation of ALG-based NAT traversal methods (FTP/SIP-based hole
>> punching, better STUN support)

A-ha? Anything that gets us out of censorship!

>> Integration of the GNU Name System with GnuPG
>> Mentors: Matthias Wachs, Christian Grothoff, Jeff Burdges

Again more energy thrown at the broken client/server system.
I think the way to bring e-mail users to the table is a
completely different one: Emulate an IMAP/SMTP/POP server
on the gnunet node and transparently repack it all to run
over GNUnet/PSYC. We can even recycle code from the Bitmessage
folks that already did this.

This rather small change for e-mail users, both private and
business, introduces immediate end-to-end cryptography, axolotl
forward secrecy, mailing list replacements, all in the backend
without them having to learn to use any phony crypto software.
We just need to extend mail software with a decent contact
acquisition mechanism, either using the social graph provided
by GNS and PSYC's distributed state, or by including the
opportunistic pEp mechanisms.

>> libaboss improvements
>>
>> Improving libaboss to make computation on shared secrets (including
>> repeated multiplication) based on Ben-Or et al. if possible. This in
>> particular means moving libaboss to bignums (gcry_mpi).

Is this related to PANDA or which kind of use cases do we have for
shared secrets?

When it comes to secushare/PSYC and GSoC, I think we could use
support in the following areas:

- Fix up the UI so that it provides for a threaded mail/chat system.

- Fix up the QR-code acquisition and generation engines to simplify
the exchange of cryptographic contact data between people who are
bootstrapping their secushare identities.

- Implement aggregation of distributed state from various channels
in order to provide for a powerful social graph API capable of
generating social network profiles, dashboards, a calendar out of
upcoming event invitations, social search functionality
and most of all to make it easy for users to adopt cryptographic
identities of their contacts/friends simply by finding them in the
social graph of their existing contacts ("This is Linda. You have 11
contacts in common with her. [ADD]")

- Implement the UI for those functions, which should total in a pretty
much complete serverless Facebook replacement.

I guess we can come up with some more if we think hard enough about it.

I'm so excited we are actually close to achieving our long-haul goals!


-- 
          irc://loupsycedyglgamf.onion:67/lynX
         http://loupsycedyglgamf.onion/LynX/
  torify telnet loupsycedyglgamf.onion