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! > > _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
