[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
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
- [GNUnet-developers] A thought/"feature request" regarding "The message from Tahrir Square",
address@hidden <=