my slightly selfish plug for my recent blog post on open source / decentralization / etc. | | V "please read and share (or comment on, critique, use as virtual toilet paper, etc..." :-) https://odinn.cyberguerrilla.org/index.php/2014/01/02/opensourcebuildguide/

On Mon, Dec 30, 2013 at 12:34 AM, ianG wrote:

...

On 28/12/13 09:24 AM, grarpamp wrote:

...

On Wed, Dec 25, 2013 at 7:21 PM, Matthew Kaufman wrote:

...

So there's already a system that until very recently did peer-to-peer delivery of messages over encrypted channels between hosts that participated in a peer-to-peer overlay. It was Skype.

Afaik, skype used a central lookup to get to unknown peers, not a DHT. So they perhaps knew who wanted to talk to who. Of course now skype is untrusted by anyone with a clue.

So sad. I have a clue and don't trust Skype. But I can't for the life of me migrate my friends off of it. It's as addictive as crack. It's just better than the alternatives.

As a serious business problem, if one wants to share documents on a frequent basis, which system would one choose for security? Skype, google docs aka drive, or something else?

I need something that ordinary people can use. So no complicated "download this on 100 machines and ..."

Also, should be free and can make a nice cup of coffee.

There is slick, and then there is utility. I'm seeing some good utility in a few of the listings on https://www.prism-break.org/ . When it comes getting utility done, it's not to hard to introduce (even firmly) people into using utilities. Slick helps, but it's not required, and will come in time. Everyone throws up BS about adoption and thus nothing ever gets built, or even researched, screw that, I say build it and see.

I also question a few of those listings.

...

...

...

battery life... and when they're on 3G/4G, the bandwidth isn't as good and it can be very expensive, and it burns the battery up even faster.

Sure, there's a class of users that want this, a big class. They can have and use their modified legacy centralized email as they wish. There's another big class that want's something more than that.

We're also going to see faster hardware, lighter code, and maybe even wearable battery packs... because as you say, these users want it all and are willing to go to almost any means to get it.

I'm going to make a call here. I reckon that future phone bandwidth and batterywidth will be sufficient to close the gap, to the point that this problem goes away.

So, moving away from p2p notions that are popular with the one-laptop-per-everyone western world would be the wrong strategy.

Although it seems that the phone market is 'different' it is catching up fast in the things that matter. Right now, the only thing where they are arguably short is VoIP. Hell, they're happy watching utube on phones...

But that's no problem because in today's world, what dominates is chat & apps. Lack of good VoIP over phones is just a short term issue.

(It's a prediction, not a claim!)

I agree with this hardware path, especially for the subject of p2p secure messaging.

I think voip is currently not a user priority on devices with a cell stack because that stack is already activated and paid for. With good apps and wider access to free wifi in particular, encrypted voip should take off. Or we will see more use of cell based IP plans. Another twist is going out of voiceband to get the key material of your peer, then with the more open phones out there, grab the cell mic/vocoder/modem on them and stuff your encrypted voice over that if voip doesn't work at that moment. But that's way off topic to p2p secure messaging... at least until that hardware path allows for p2p secure <everything>.

...

...

...

These users want to be able to send and receive messages when their device is on, but the recipient's device isn't. Because most of the time, the recipient's device, even if they put it in their pocket 10 seconds ago, is already asleep, trying to preserve as much battery as possible.

That pretty much eliminates all designs that do direct transfer from sender to receiver, irrespective of the traffic analysis risks of doing so.

Additionally, it also means that nearly all the participant nodes are also unable to participate in a peer-to-peer overlay network, because they can't afford the network uptime (and consequent battery drain) necessary.

We're exploring ideas. What is to say we are able to develop into it some kind of automaton taho-lafs delivery storage nodes. Storing messages in transit under some expiry policy is not a huge space concern. So who knows.

Maybe everyone with their uber important phones will end up VPN to their home/colo servers where the horsepower is.

Predicting mobile is hard. Throw more apps out there and your $30-50/mo unlimited data plans go away. Now is everyone going to pay $150+/mo for that? Where is free open wifi going to end up spanning? And so many other things.

In the market I'm in, people are very used to switching off Apps when they see the bandwidth being sucked. Just an observation... I think it's a problem that solves itself, a warning to developers that they have to think outside their tech box.

Right... I think not everything has to run in RAM... we have a few GiB to store the network state in, as a sliding tradeoff for reconnection speed when switching them back on. CPU is another available slider. So is network rate/transfer limits.

...

...

What I think is clear is that there will for the far to indefinite forseeable future be some form of real workstation/laptop in the home and office. Phones just can't replace that. Maybe we're seeing something in how you see larger tablet/netbooks/laptops with headsets being carried about now as if it is natural. And lots of those people will want a highly secure system to communicate over with their peers in this new world of disgustingly gratuitous surveillance and databasing. I would not underestimate the demand for that sort of a comms system.

I see this as rather a rich western world observation. It probably works for Apple. It doesn't so much work in the non-rich world, where things are much more widely driven by Android, etc.

I gather Africa does a lot of things with simple text messaging on simple non-I/Android/MS/Unix phones. What is their path for phone tech advancement, and when?

Is it reasonable to expect to truly need to develop for more than the 'West' as a userbase? Keep in mind the West now probably includes China and many other places, so we're looking at more than 1B nodes anyways. We probably mean 'Western class' of phones. And by the time a p2p secure messaging platform the subject of this thread is deployed in a handful of years, that class will be much more widespread. So perhaps natural convergence of this software and hardware will occur.

Yes there are West/first vs. second/third disparities, if everyone waited we wouldn't have what 'western' tools we have today. There are folks in the west that need them too, even to work on solving those disparities, so it is not much of an argument to expect to limit develop only for western class HW.

See what you can build for intel/amd CPU's. See what you can fit in ARM, snapdragon, android, etc.

...

...

...

ps. And then there's the other unsolved problem: If you do actually build a popular service that lets people securely exchange messages, the government comes with an order to reveal the content of the messages, and threats to lock up the principals if those demands aren't met. I wish I could tell you more stories about this, but of course I'm subject to the same sorts of non-disclosure that everyone else who's ever gotten one of those is.

That's why you should be doing the development of these new protocols entirely within existing secure networks such as Tor and I2P. And why you should bootstrap via peers instead of clearnet authorities like Tor that can be shutdown... it's a little less secure, but you can have in network authorities wrapped in web of trust and then rejoin listening only to them later. And if clearnet get''s that bad, it becomes a freedom of speech issue which is well, SHTF time.

Easy to say :) And then you meet your users, and they don't want that, they want something different.

ie: I2P has it's main repo in .i2p and some anon developers.

I don't see bootstrapping into the net via peers as 'unwanted', they are your trusted real world friends for the most part. What your app does after that with the network db it learns from that doesn't necessarily need to involve your friend anymore.

What don't they want? A little less initial security for a day while the app crunches and sorts things out? Possibly selecting a trust chain other than that introduced to them by their friend? Reading the public consensus on that? It sounds like the BS adoption issue people like to claim in order to not build anything. Granny learned to surf the net, so Johnny can learn to encrypt. And both of them know how to read the manual. Seriously.