Blockchain + DHT = secure email-like messaging.

[tradeaway]

I'm not sure that fixes anything, you still have to get the address somehow. If the service giving you the address is compromised or malicious it could just give you an address/key it controls and forward the mail through using another address of its own as the reply-to address and intercept communication both ways. Alice -> Eve as Bob -> rewrite reply address to Eve as Alice -> Send to Bob. Return works the same way but switching the addresses back again. Eve still comprises all the back and forth through MITM. Generating enough addresses on the fly gets a little harder if creating a new identity is expensive (cost or computation), but would probably still be possible.

But if you have a receiver address you just send the message to it, just like if you have a Bitcoin address you send to it. If somehow the receiver gave you a wrong address it's his problem

Two ways is probably a minimum, there's always plenty of ways to work it out. I'd argue that supernodes at any point does or can lead to centralization and all the things you're looking to avoid by making it decentralized. So of those two solutions just relying on donated resources might be required. Implicit supernodes that are just well connected with lots of space and bandwidth might pop up, but are a nice possibility not a requirement of the protocol.

Yes, that's right, if the service provided by the system is useful you'll always find the users willing to maintain the network. And also some ways to monetize the system open up. I believe some monetization could be the way to make the sytem really popular, as it was with Bitcoin, the main promoters of the Bitcoin system are naturally the miners.

Also as I wrote in the post above, some nice opportunities may be considered, like starting a bitcoin fork with messaging file sharing etc. This way you get payments and messaging combined, and the currency obtains some intrinsic value. I'm not sure that I wanna follow this road, though.

I'm not sure how much filtering would be possible using a DHT/broadcast/everything public system. The source node not being connected when the message is eventually retrieved is nearly a protocol requirement I would think. Storing spam forever is also a PITA because people who aren't receiving it can't spam check or do anything to figure out if anyone wants the mail. Someone sending mail back and forth to themselves could theoretically DoS the network, or at least take up a lot of space. You can control who you connect to, but in a practical sense someone has to be willing to connect to new peers and most people will eventually be connected through some series of nodes to every other peer, friendly or not.

Yes sure, everything gets stored until the receiver reads it. Probably there's no way to circumvent this. But the receiver has the opportunity to drop the messages from the network after she checks them. In my opinion correct DHT setting can solve a lot of issues - for example, messages to you are not stored network-wide, they are stored only on peers which are "close" to you. So the spam problem is alleviated, you can't really overload the network by sending huge messages to a couple of addresses.

I do think that's a more manageable system overall, everyone polls for messages of users they care about. Messages are signed for public messages or encrypted to the receiver and then signed (all the headers on the inside, source may still be leaked/public possibly) for private messages. Doesn't work like any traditional system I'm familiar with, but there's no central server so it works. Does sound pretty similar to FMS on Freenet though, could be a good reference.

Yes, that would be really great, completely decentralized twitter, which works on protocol level, like http. I think the ability to broadcast information
just having access to Internet could be essential. Meaning twitter-like capabilities should go deeper, do not depend on third-party services and work on par with http or ftp

It's usually a tradeoff between easy and private. No one writes down notes and encrypts them in public because it's a pain, you just talk, the best you can do is whisper or go somewhere more private.

Files, including video, audio, etc, can all be represented in printable characters across text messaging systems, and give it ten minutes of existence and I'm sure someone will be transferring files and they'll slowly get as big as people care to send. yEnc on usenet, base64 more generally. Binary data is still just data.

Storage is cheap by some metrics, a large company can have exabytes (Megaupload, Google, Facebook, etc), but the home user can and will fill up his harddrive and want space eventually, or may only care to dedicate so much of it. Add to that junk mail, large file transfer, data redundancy, and all the rest and eventually it will run out. Even if it's not in the plans, assume any corner case will happen and have some plan for it. The problem with opt-in deletion (sender or receiver explicitly deleting things) is that if they forget to or lose they keys to do so then it's stuck there. Theoretically the receiver could delete it once received or the sender could put a destroy-at timestamp, though I don't think you could do it based on time read; you don't really want to let the public know when a message is read, I don't at least. Being able to re-send a message into the swarm (as the sender, or receiver even) isn't too difficult I'd imagine, just keep passing around the block of data containing the message. I would certainly be highly in favor of some mechanism that eventually expires data being included from the beginning, even if there's no expectation to use it.

Supernodes may be the solution to the storage problem, of course.  Also consider simple setup when a user is able to store as much data  in the "cloud"  as she stores locally (of other peers' data). That could balance the system. Actually somehow I feel that this shouldn't be the main obstacle to the validity of the system.

[1715458224]

1715458224

[1715458224]

1715458224

[1715458224]

1715458224

[1715458224]

1715458224

[1715458224]

1715458224

[1715458224]

1715458224

[tradeaway]

http://techcrunch.com/2013/07/06/tools-for-treason/
great piece from techrunch. Something is in the air, this is time for crypto-revolution

[btharper]

I'm not sure that fixes anything, you still have to get the address somehow. If the service giving you the address is compromised or malicious it could just give you an address/key it controls and forward the mail through using another address of its own as the reply-to address and intercept communication both ways. Alice -> Eve as Bob -> rewrite reply address to Eve as Alice -> Send to Bob. Return works the same way but switching the addresses back again. Eve still comprises all the back and forth through MITM. Generating enough addresses on the fly gets a little harder if creating a new identity is expensive (cost or computation), but would probably still be possible.

But if you have a receiver address you just send the message to it, just like if you have a Bitcoin address you send to it. If somehow the receiver gave you a wrong address it's his problem

That's all assuming you're able to speak with the other party directly. If you have to use any third party (Bitcointalk, chat server, etc) They can all be compromised and change the address before you get it. If the two already have a secure channel to communicate over then why are they going to switch to this one?

Two ways is probably a minimum, there's always plenty of ways to work it out. I'd argue that supernodes at any point does or can lead to centralization and all the things you're looking to avoid by making it decentralized. So of those two solutions just relying on donated resources might be required. Implicit supernodes that are just well connected with lots of space and bandwidth might pop up, but are a nice possibility not a requirement of the protocol.

Yes, that's right, if the service provided by the system is useful you'll always find the users willing to maintain the network. And also some ways to monetize the system open up. I believe some monetization could be the way to make the sytem really popular, as it was with Bitcoin, the main promoters of the Bitcoin system are naturally the miners.

Also as I wrote in the post above, some nice opportunities may be considered, like starting a bitcoin fork with messaging file sharing etc. This way you get payments and messaging combined, and the currency obtains some intrinsic value. I'm not sure that I wanna follow this road, though.

I'd say if you end up with anything that can be paid for you have to make sure you maintain the free side of things too. If you wanted to run it off a chain you could allow miners to trade currency and charge for messages in that currency and trading would happen between other cryptocurrencies naturally. Although in this case I'd assume messages would be encoded as transactions and those get broadcast around anyway. At which point it's harder to charge for things that get broadcast to the entire network for free anyway. The blockchain could be stored for long or indefinite periods at a cost (tx fee) and the other messages would just eventually die because there's no reason to keep broadcasting them without a fee and most miners not mining on free transactions. Spam and abuse of broadcast transactions would be problematic though.

I'm not sure how much filtering would be possible using a DHT/broadcast/everything public system. The source node not being connected when the message is eventually retrieved is nearly a protocol requirement I would think. Storing spam forever is also a PITA because people who aren't receiving it can't spam check or do anything to figure out if anyone wants the mail. Someone sending mail back and forth to themselves could theoretically DoS the network, or at least take up a lot of space. You can control who you connect to, but in a practical sense someone has to be willing to connect to new peers and most people will eventually be connected through some series of nodes to every other peer, friendly or not.

Yes sure, everything gets stored until the receiver reads it. Probably there's no way to circumvent this. But the receiver has the opportunity to drop the messages from the network after she checks them. In my opinion correct DHT setting can solve a lot of issues - for example, messages to you are not stored network-wide, they are stored only on peers which are "close" to you. So the spam problem is alleviated, you can't really overload the network by sending huge messages to a couple of addresses.

Any messages sent to an address that isn't in use gets stored forever since there is no receiver to discard it from the network. Imagine generating 1000 random bitcoin addresses, sending some coin to each of them, and then deleting the wallet. They go somewhere but if no one has that private key (including you since you deleted it) they just sit there for eternity taking up space. Sending any messages to random addresses distributed across the DHT fills up space across the network and never gets freed.

I'd also argue for distributing mail for each user across the network, if the handful of peers around me all go down I don't want my mail to die with them. It also means that someone can figure out who mail is for by seeing which nodes accept it; it would seem more secure to me if they can tell as little about the message (sender, receiver, headers, content, timestamps) as possible.

I do think that's a more manageable system overall, everyone polls for messages of users they care about. Messages are signed for public messages or encrypted to the receiver and then signed (all the headers on the inside, source may still be leaked/public possibly) for private messages. Doesn't work like any traditional system I'm familiar with, but there's no central server so it works. Does sound pretty similar to FMS on Freenet though, could be a good reference.

Yes, that would be really great, completely decentralized twitter, which works on protocol level, like http. I think the ability to broadcast information
just having access to Internet could be essential. Meaning twitter-like capabilities should go deeper, do not depend on third-party services and work on par with http or ftp

I'd say it's pretty hard to get anything working that smoothly without a central server, again the advantages that centralization offers. For a bit of extra latency though you could do much of the same. Tradeoffs exist everywhere. Granted you might be able to get everything you want in one system, but I wouldn't expect it right off.

It's usually a tradeoff between easy and private. No one writes down notes and encrypts them in public because it's a pain, you just talk, the best you can do is whisper or go somewhere more private.

Files, including video, audio, etc, can all be represented in printable characters across text messaging systems, and give it ten minutes of existence and I'm sure someone will be transferring files and they'll slowly get as big as people care to send. yEnc on usenet, base64 more generally. Binary data is still just data.

Storage is cheap by some metrics, a large company can have exabytes (Megaupload, Google, Facebook, etc), but the home user can and will fill up his harddrive and want space eventually, or may only care to dedicate so much of it. Add to that junk mail, large file transfer, data redundancy, and all the rest and eventually it will run out. Even if it's not in the plans, assume any corner case will happen and have some plan for it. The problem with opt-in deletion (sender or receiver explicitly deleting things) is that if they forget to or lose they keys to do so then it's stuck there. Theoretically the receiver could delete it once received or the sender could put a destroy-at timestamp, though I don't think you could do it based on time read; you don't really want to let the public know when a message is read, I don't at least. Being able to re-send a message into the swarm (as the sender, or receiver even) isn't too difficult I'd imagine, just keep passing around the block of data containing the message. I would certainly be highly in favor of some mechanism that eventually expires data being included from the beginning, even if there's no expectation to use it.

Supernodes may be the solution to the storage problem, of course.  Also consider simple setup when a user is able to store as much data  in the "cloud"  as she stores locally (of other peers' data). That could balance the system. Actually somehow I feel that this shouldn't be the main obstacle to the validity of the system.

Supernodes can solve some problems, but then you're moving to somewhere between centralized and decentralized; advantages and disadvantages present. You'd almost certainly have to leave a bit of room for redundancy at a factor of 2-5 depending on how likely the peers you trade with are to be up and running when you want the data back; for each megabyte you store on other machines you have to store five to achieve this redundancy (not a problem per se, but a consideration). And what happens when a peer disconnects? Do you assume they're gone after an hour/day/week/month/year/decade and delete their data and trade with someone else? How long do you want them to wait when you disconnect? How would you handle a clean shutdown so that you're not holding any data people need access to right away while you're gone? When working directly off parity (and not including at least some altruism) it can get messy during periods when you can't reciprocate, and without an always on client that's hard.

I don't think it's the main obstacle to validity, but I think it's one of the biggest problems that's concrete enough to go after directly. The rest of the protocol is still vague and malleable. Two days worth of retention (as in bitmessage) is simple to achieve and concrete, longer is still easy but at some point if you're expiring data (and I'd argue it's a case of when not if) you have to know when and how it's getting deleted. Local or reinserted copies can persist of course though.

[tradeaway]

That's all assuming you're able to speak with the other party directly. If you have to use any third party (Bitcointalk, chat server, etc) They can all be compromised and change the address before you get it. If the two already have a secure channel to communicate over then why are they going to switch to this one?

Hmm well, yes. If you are not sure of the receiver's address validity you're not advised to send messages to this address. But it is a general problem.
The addresses are public keys after all, and public keys are open to everyone by default.

I'd say if you end up with anything that can be paid for you have to make sure you maintain the free side of things too. If you wanted to run it off a chain you could allow miners to trade currency and charge for messages in that currency and trading would happen between other cryptocurrencies naturally. Although in this case I'd assume messages would be encoded as transactions and those get broadcast around anyway. At which point it's harder to charge for things that get broadcast to the entire network for free anyway. The blockchain could be stored for long or indefinite periods at a cost (tx fee) and the other messages would just eventually die because there's no reason to keep broadcasting them without a fee and most miners not mining on free transactions. Spam and abuse of broadcast transactions would be problematic though.

Actually I'm writing a more technical description of a purely free system right now. Monetization is nice but it can be too distractive. Although it looks like a nice opportunity - you combine all crypto services in one system, so the currency gets some intrinsic value. Maybe it is what Satoshi had in mind too, because there are many features in bitcoin original code which would support this idea. But yes, I think messages cannot be stored in any form of blockchain. Message headers can, though. For example you store in the chain the message hash and then find the message with DHT.

Any messages sent to an address that isn't in use gets stored forever since there is no receiver to discard it from the network. Imagine generating 1000 random bitcoin addresses, sending some coin to each of them, and then deleting the wallet. They go somewhere but if no one has that private key (including you since you deleted it) they just sit there for eternity taking up space. Sending any messages to random addresses distributed across the DHT fills up space across the network and never gets freed.

Good point, but these messages can be easily dropped from the system, since when a message is sent the sender tries to find the receiving peer,
if it is not seen in any hash table the message is dropped.  A node has to announce its existince to "close" nodes (the closeness is considerd in some hash metrics). The messages for the given node are stored by its "close" nodes, so if no one ever saw the node if won't receive messages.

I'd also argue for distributing mail for each user across the network, if the handful of peers around me all go down I don't want my mail to die with them. It also means that someone can figure out who mail is for by seeing which nodes accept it; it would seem more secure to me if they can tell as little about the message (sender, receiver, headers, content, timestamps) as possible.

Yes, it's doable. The message back-up will be an integral part of the system. It seems to be quite straigtforward actually.

I'd say it's pretty hard to get anything working that smoothly without a central server, again the advantages that centralization offers. For a bit of extra latency though you could do much of the same. Tradeoffs exist everywhere. Granted you might be able to get everything you want in one system, but I wouldn't expect it right off.

Actually some decentralized systems work amazingly well, including Bitcoin and Bittorent (with magnet links). We should push it, this is a matter of invested work I believe. You won't be able to achieve the same level of performance as with centralized systems but you, hopefully, will be able to closely mimic it. And the benefits are enormous.

Supernodes can solve some problems, but then you're moving to somewhere between centralized and decentralized; advantages and disadvantages present. You'd almost certainly have to leave a bit of room for redundancy at a factor of 2-5 depending on how likely the peers you trade with are to be up and running when you want the data back; for each megabyte you store on other machines you have to store five to achieve this redundancy (not a problem per se, but a consideration). And what happens when a peer disconnects? Do you assume they're gone after an hour/day/week/month/year/decade and delete their data and trade with someone else? How long do you want them to wait when you disconnect? How would you handle a clean shutdown so that you're not holding any data people need access to right away while you're gone? When working directly off parity (and not including at least some altruism) it can get messy during periods when you can't reciprocate, and without an always on client that's hard.

I don't think it's the main obstacle to validity, but I think it's one of the biggest problems that's concrete enough to go after directly. The rest of the protocol is still vague and malleable. Two days worth of retention (as in bitmessage) is simple to achieve and concrete, longer is still easy but at some point if you're expiring data (and I'd argue it's a case of when not if) you have to know when and how it's getting deleted. Local or reinserted copies can persist of course though.

Supernodes should be different to usual nodes only in their storage capacity. Actually in all decentralized systems appear some structure, this is an emergence phenomenon. Bitcoin actually is not any different, it converges to the state when only supernodes will carry around the whole blockchain.

Redundancy will be crucial to the system stability, that is right. Bacically a given message would be stored on all the nodes which are close to the given node. It should be carefelly balanced, taking into account that some messages will be deleted after all, and some would probably not be meant to be stored at all.

[🏰 TradeFortress 🏰]

Decentralized is a must. Don't focus on making your own alt coin - a few reasons:

The majority of people will not use something they have to pay to send messages (money or significant processing power or network)

The key thing would be to make it easy to use and fast. You have failed if you created PGP, because PGP is not going to get used by the average Joe. You failed if you created something like Bitmessage that is clunky and takes 4 minutes to send a message.

It needs to be as fast as IM. Seriously, you could code whatever you want but if it is not easy to use it will not be used other than as a forgotten niche.

Another thing that you may not see as a requirement but actually very much is - it must be web based.

"Talk to me on platform! Compile this binary: github.com/platform/platform" > 75% of people: "talk to me on skype"

vs

"Talk to me on platform! http://platform-project.org/webclient or download your own local copy" > 75% of people: *click*

Now of course it must be open source and just serving static javascript. It can connect to commercial providers while being decentralized.

The commercial providers would just be limited to passing encrypted bits, as well as storing encrypted data like a mailbox. Now you might worry about network fragmentation - but that isn't an issue if messages are designed to flood the network, AND you can connect to multiple providers to fetch data. Or run your own. I am 100% sure that this network will end up with free donation supported networks, even if there's nothing prohibiting charging, because $0.01 is infinity larger than $0.00.

Seriously, forget about DHT, forget about blockchain, forget about cryptocurrencies: this isn't difficult, this isn't perfect, but you need a web app and data transmitters.

A and B are the two major rivals that are withholding messages from each other? Join C which connects to both. Metadata like source, from, time, size etc being disclosed? Build a tor network on top of that.

OK, so how do you prevent MITM attacks?
Fingerprints.

But that's not perfect!
It won't be, because you won't succeed if you try to build the prefect system. You need to build something that can be adopted easily. You need to focus as much time on smiles as security.

[tradeaway]

I got your point, really insightful indeed.
I wouldn't like to start another altcoin, it just doesn't feel right to me, on many levels. New altcoin should be something way ahead of Bitcoin, for example I strongly belive that it has to have some intrinsic value and not be a subject of market speculations. As long as we don't know how to do it Bitcoin will probably be the king. And there are ways to mitigate Bitcoin drawbacks, probably some large market maker will arrive sooner or later, it may be also community effort aimed at stabilizing the currency rate.

As for the web-services - I have a setup in mind which resembles bitcoin hosted wallets. In this case it will be analogous to webmail. It could work like blockchain.info hosted wallet, that is your private key is not transmitted anywhere, it's just used to decrypt messages on the fly. And webservice fetches your messages with your public key.

Decentralized is a must. Don't focus on making your own alt coin - a few reasons:

The majority of people will not use something they have to pay to send messages (money or significant processing power or network)

The key thing would be to make it easy to use and fast. You have failed if you created PGP, because PGP is not going to get used by the average Joe. You failed if you created something like Bitmessage that is clunky and takes 4 minutes to send a message.

It needs to be as fast as IM. Seriously, you could code whatever you want but if it is not easy to use it will not be used other than as a forgotten niche.

Another thing that you may not see as a requirement but actually very much is - it must be web based.

"Talk to me on platform! Compile this binary: github.com/platform/platform" > 75% of people: "talk to me on skype"

vs

"Talk to me on platform! http://platform-project.org/webclient or download your own local copy" > 75% of people: *click*

Now of course it must be open source and just serving static javascript. It can connect to commercial providers while being decentralized.

The commercial providers would just be limited to passing encrypted bits, as well as storing encrypted data like a mailbox. Now you might worry about network fragmentation - but that isn't an issue if messages are designed to flood the network, AND you can connect to multiple providers to fetch data. Or run your own. I am 100% sure that this network will end up with free donation supported networks, even if there's nothing prohibiting charging, because $0.01 is infinity larger than $0.00.

Seriously, forget about DHT, forget about blockchain, forget about cryptocurrencies: this isn't difficult, this isn't perfect, but you need a web app and data transmitters.

A and B are the two major rivals that are withholding messages from each other? Join C which connects to both. Metadata like source, from, time, size etc being disclosed? Build a tor network on top of that.

OK, so how do you prevent MITM attacks?
Fingerprints.

But that's not perfect!
It won't be, because you won't succeed if you try to build the prefect system. You need to build something that can be adopted easily. You need to focus as much time on smiles as security.

[🏰 TradeFortress 🏰]

https://bitcointalk.org/index.php?topic=252273.0

Some ideas on a system that favors bandwidth with minimal storage requirements.

[Jaxkr]

Another thing that you may not see as a requirement but actually very much is - it must be web based.

"Talk to me on platform! Compile this binary: github.com/platform/platform" > 75% of people: "talk to me on skype"

The irony here is that skype is not web based.

[tradeaway]

I don't think it has to be web-based, it must be convenient to use, that's the most important. we need to build a thing which wouldn't seem too cumbersome or sophisticated at all.

Another thing that you may not see as a requirement but actually very much is - it must be web based.

"Talk to me on platform! Compile this binary: github.com/platform/platform" > 75% of people: "talk to me on skype"

The irony here is that skype is not web based.

[tradeaway]

Contemplating several quite different versions of the system, gravitating towards block-chain shared among all the nodes with DHT.

It means that a given node will carry only a fraction of the whole blockchain, if a client needs this part of the blockchain it downloads it from the "cloud". This way blockchain can become really huge, since it is distributed between all nodes. And we can include much more stuff in it, compared to Bitcoin.

What guys do you think of the idea? Maybe you can see some pitfalls I missed.

[tradeaway]

Probably I didn't put it clear enough, would like to clarify a bit. Actually it boils down to this:
For example, we have a 6 GB blockchain with bitcoin. It obviously becomes unwieldy to handle.
The idea is to share the whole blockchain among the all peers, with a given peer carrieng only the part of the blockchain.
Then, in effect, we won't have any limitations on blockchain size whatsoever.
The search in blockchain will be by means of DHT. We'll be able to put in the blockchain much more information, including messaging, contracts....
I can't see any pitfalls, seems to be doable. Please give me some feedback

[greBit]

Any updates on this? Sounds interesting

[markm]

1. I want to be able to communicate securely with any counter party for which I know its public key, and our communication cannot be intercepted if the attacker does not have my private key and is able to carry out only polynomial-time computations.

That right there puts you squarely back into the same problem, key exchange, that you say you do not like about PGP / GPG.

PGP / GPG does not actually "require" key exchange in order to write a message to someone whose public key you know. How you cause them to become aware that the message you have written to them exists could be anything, heck you could just put it on a web page with their public key as the page's title, have google spider the page, and hope they will some day ask google whether any pages exist that have their public key as the title. Or use a DHT that lets them look up whether any items have been stored that pertain to their public key.

So fundamentally sending someone a PGP message in no way requires exchange of keys, it only requires that you have their public key.

What does require exchange of keys is the whole defense versus man in the middle and stuff like that. If you want that then, like PGP, you need key exchange.

As far as I know offhand, your complaint regarding key exchange is thus not really a complaint about PGP at all but is rather simply a requirement of certain "certainty about who you are communicating with" features that you would like. If you are willing to do without those assurances, then you can use PGP without exchange of keys. I don't know offhand (though need sleep so memory/wits aren't at their best) of methods to accomplish those kinds of assurances whilst spamming messages at public keys.

My main point here is PGP public keys could be messaged at just as easily as coin addresses, and if you are willing to not bother exchanging keys you can do that with PGP just as easily as you can with coin addresses.

-MarkM-