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