gnunet-developers
[Top][All Lists]
Advanced

[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 
semi-real-time.

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:
Sneakernet
USB dead drops
Bluetooth
(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.


Sincerely,
        a.jhonson



reply via email to

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