[Top][All Lists]

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

[GNUnet-developers] A thought/"feature request" regarding "The message f

From: address@hidden
Subject: [GNUnet-developers] A thought/"feature request" regarding "The message from Tahrir Square"
Date: Wed, 7 Mar 2012 23:29:54 +0000

Hello list,

hopefully my thoughts will not be considered too heretical. ;-) Honestly, 
please don't hesitate to tell me if this is the wrong project to ask for 
implementing this proposal. I know it is major feature request and this project 
at the moment aims at sharing data over active connections and in 

Taking "The message from Tahrir Square" into account it shows that the wired 
means of communication are shut down and the wireless wide-area alternatieves 
are either centralised and/or localiseable by technical measures. To adress 
this issue a trade of the luxury of real-time for a diversity of 
transport-channels should be possible.

Now my thought, rather a question, is:
Why not, as an alternative meta-method of transport, make a "dump" of all data 
destined to be sent to a specific peer and transport it otherwise as a file ?

These ways could be:
USB dead drops
(re)writeable CD/DVDs
diverse steganographic hacks
you name it...

Now I know, this is an asynchronous method of communication and would not be 
usable for VPN and TOR-like applications, but it would combine advantages of 
the afforementioned ways (no data retention, no means of time-correlation 
analysis and personal control over the data if you meet the respective person) 
with the "core values" of gnunet (end-to-end encyption, anonymous file sharing, 
mutual authentification and most important of all plausible deniability).

So why not implementing an API for these asynchronous transport channels ?

From my understanding the current transport-API assumes the channels to be 
synchronous and in semi-real-time, since you can open a channel and have a 
session to close. An asynchronous transport-API would of course require some 
changes of the gnunet framework. Gnunet should keep an account of "ongoing" 
communications to other peer (what has been requested / sent via an "offline 
packet") and keep this information over a reboot.

The API would need a queue function to collect everything that needs to be sent 
until it can be.
Transport modules would center around the event of a suitable device being 
connected, upon connection files/data are read, answers and reactions get 
computed and written to the medium.

In this context a timeout would of course not exist.

As for me, I have some experience at coding but "just implementing it and 
sending you the patch" is definitely above my level, also for it means a major 
change to the core framework.

If my thoughts are not completely lunatic, please let me know and I will post a 
more detailled feature request in Mantis.


reply via email to

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