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 mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnunet-developers
