[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-developers] A thought/"feature request" regarding "The message f
[GNUnet-developers] A thought/"feature request" regarding "The message from Tahrir Square"
Wed, 7 Mar 2012 23:29:54 +0000
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
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.
- [GNUnet-developers] A thought/"feature request" regarding "The message from Tahrir Square",