gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] GSoC


From: Martin Schanzenbach
Subject: Re: [GNUnet-developers] GSoC
Date: Tue, 16 Feb 2016 10:53:56 +0100

Hi,

On Tue, 2016-02-16 at 09:50 +0100, carlo von lynX wrote:
> 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.

I already started a REST plugin framework and a handful of APIs for my
own use. If you have requirements for a specific set of APIs from
GNUnet then it would be good if you could file a bug report so we can
keep track of what is needed first. Moving the _whole_ GNUnet API to
REST with a well designed HTTP-style API and good documentation should
be the goal of this GSoC. The task is not very sophisticated/innovative
but a nice exercise in SE and API design and it's a great way to get to
know what GNUnet does, and how, I think.

- Martin

> 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.h
> tml
> 
> 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!
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]