The following feedback by grarpamp suggests unMessage to be flexible about the transport. This issue should be used to discuss the possibility and implementation of such feature.
On Wed, Mar 29, 2017 at 03:57:29AM -0400, grarpamp wrote:
You may want to link unmessage into the I2P network as well.
On Thu, Mar 30, 2017 at 02:48:45AM -0400, grarpamp wrote:
It's suggested and welcome that all overlay networks publicly
review, audit, analyze, each others work and offerings. Unfortunately
that hasn't develop much yet in a formal dedicated as responsibility
manner among even the larger opensource community, or even
discussion if that is a good idea. (But there is some good work in
some projects out there lately of their own work... automated code
linting, and the rarer procured third party audit.)
Then shall we presume all our networks are equivalently secure?,
or equivalently flawed, as each network happens to advertise now and then.
This may leave the matter of partitioning up to the user to consider
pursuant to any note about that in the app documentation.
The app could enable simultaneous multihome based on commandline
options... --tor --i2p --cjdns --other, default [whatever] .
And of course all the ports / addresses / bindings would need to
be flexible.
On equivalent networks, presence is maybe a bigger issue than partitioning.
This includes concept to drop the network identity off the network itself,
or use new ID, not just managing announces to buddy list entries.
The following feedback by grarpamp suggests unMessage to be flexible about the transport. This issue should be used to discuss the possibility and implementation of such feature.
On Wed, Mar 29, 2017 at 03:57:29AM -0400, grarpamp wrote:
On Thu, Mar 30, 2017 at 02:48:45AM -0400, grarpamp wrote: