Passage: open source secure, fast communications network

[🏰 TradeFortress 🏰]

The draft

Users connect to nodes or run their own. Users do encryption and decryption locally, in their browser or computer.

Nodes pass encrypted messages between each other, store the relevant, and stream them to users

Node discover them through P2P means, as well as bootstrapping from IRC channels, dnsseeds, or anything really.

Identities

Users generate identities, just like bitcoin addresses, automatically with public private key crypgoraphy.

Identities have corresponding text representations and pictorial (eg randomart, colored pixels)

It would be very difficult for attackers to replace "I am [identity]" on numerous social networking websites, directories, blockchain timestamps, etc.

New identities would be generated and passed around with each message. Public identities are not used beyond an encrypted "identity swap".

Messages

Messages contain one from identity and an arbitrary amount of to addresses, a vague timestamp and arbitrary payload. They are identified by their hash.

The arbitrary payload may include details of the next identity to use (?)

Nodes will have their own policies on what they relay. Nodes probably will operate on a whitelisting level (unless there are better solutions)

Whitelisting will gravitate towards things such as identity swapping, solving CAPTCHAs, etc

------

MITM
If you post your public identity practically everywhere, it would be very difficult for an attacker to change them, especially if they are embeded in a blockchain like system.

From/to tracking
The software would automatically negotiate new identities through encrypted communications. If you run your own node, it would be very difficult to find out who you are talking to as your node will be passing messages rapidly

Spam
Nodes could operate on a fetch instead of push system, whereas only messages from specific identities chosen by the user are kept. Nodes may "whitelist" addresses that has completed proof of work (eg captcha). Nodes may trust other nodes in their whitelisting.

------

Example

Alice's public identity is towb0XgLHML1yyVBcYWn. This info is on a lot of directories, profiles and places.
Bob's public identity is likvMxGs0txShDuaSoXV. Both of the identities have completed "proof of work" of some sort and are recognized by nearly all of the network.

Alice and Bob runs their own nodes. Alice sends a message encrypted that only Bob can decrypt, and passes it around the network. The message contains a new identity. Alice and Bob's nodes may add these identity to "always keep messages".

Bob sees the message and replies with a message to Alice. The message may not contain an identity and may simply be gibberish that doesn't checksum. This makes it very difficult for people to determine if Alice is actually communicating with Bob. The software by default may occasionally send messages to random identities that it has heard activity from/to containing gibberish. A gibberish response is expected in that case.

Alice and Bob's nodes are constantly receiving a lot of irrelevant messages. They're all relayed to peers who don't have them, while the nodes only store the hash (possibly in bloom filter) to reply with "HAVE" when another node asks "GOT [hash]?"

Bob's software sends gibberish (does not match checksum) to a random identity it has observed mail from. It is customary for that selected identity to also reply with an encrypted message, which turns out to be gibberish too.

Alice now communicates another message from a new identity, to Bob's new identity. This may or may not include another new identity. Of course, there is the encrypted message, which could be text, could be image, could be a file, although large messages may be difficult to get relayed.

[Jaxkr]

The draft

Users connect to nodes or run their own. Users do encryption and decryption locally, in their browser or computer.

Nodes pass encrypted messages between each other, store the relevant, and stream them to users

Node discover them through P2P means, as well as bootstrapping from IRC channels, dnsseeds, or anything really.

Identities

Users generate identities, just like bitcoin addresses, automatically with public private key crypgoraphy.

Identities have corresponding text representations and pictorial (eg randomart, colored pixels)

It would be very difficult for attackers to replace "I am [identity]" on numerous social networking websites, directories, blockchain timestamps, etc.

New identities would be generated and passed around with each message. Public identities are not used beyond an encrypted "identity swap".

Messages

Messages contain one from identity and an arbitrary amount of to addresses, a vague timestamp and arbitrary payload. They are identified by their hash.

The arbitrary payload may include details of the next identity to use (?)

Nodes will have their own policies on what they relay. Nodes probably will operate on a whitelisting level (unless there are better solutions)

Whitelisting will gravitate towards things such as identity swapping, solving CAPTCHAs, etc

------

MITM
If you post your public identity practically everywhere, it would be very difficult for an attacker to change them, especially if they are embeded in a blockchain like system.

From/to tracking
The software would automatically negotiate new identities through encrypted communications. If you run your own node, it would be very difficult to find out who you are talking to as your node will be passing messages rapidly

Spam
Nodes could operate on a fetch instead of push system, whereas only messages from specific identities chosen by the user are kept. Nodes may "whitelist" addresses that has completed proof of work (eg captcha). Nodes may trust other nodes in their whitelisting.

------

Example

Alice's public identity is towb0XgLHML1yyVBcYWn. This info is on a lot of directories, profiles and places.
Bob's public identity is likvMxGs0txShDuaSoXV. Both of the identities have completed "proof of work" of some sort and are recognized by nearly all of the network.

Alice and Bob runs their own nodes. Alice sends a message encrypted that only Bob can decrypt, and passes it around the network. The message contains a new identity. Alice and Bob's nodes may add these identity to "always keep messages".

Bob sees the message and replies with a message to Alice. The message may not contain an identity and may simply be gibberish that doesn't checksum. This makes it very difficult for people to determine if Alice is actually communicating with Bob. The software by default may occasionally send messages to random identities that it has heard activity from/to containing gibberish. A gibberish response is expected in that case.

Alice and Bob's nodes are constantly receiving a lot of irrelevant messages. They're all relayed to peers who don't have them, while the nodes only store the hash (possibly in bloom filter) to reply with "HAVE" when another node asks "GOT [hash]?"

Bob's software sends gibberish (does not match checksum) to a random identity it has observed mail from. It is customary for that selected identity to also reply with an encrypted message, which turns out to be gibberish too.

Alice now communicates another message from a new identity, to Bob's new identity. This may or may not include another new identity. Of course, there is the encrypted message, which could be text, could be image, could be a file, although large messages may be difficult to get relayed.

So, you're describing a Bitmessage without the PoW on message sending?

[🏰 TradeFortress 🏰]

There are very distinct differences between this concept and BitMessage. It uses different ways to ensure anonymity of metadata and retention.

For example, nodes only store relevant messages (to their hoster, users, etc), and hashes of messages they have seen (so they don't miss checking any messages) and an amount of random irrelevant messages for anonymity.

[r3wt]

add dht as failover and you immediately have my interest.

[🏰 TradeFortress 🏰]

add dht as failover and you immediately have my interest.

DHT would reveal which node have which messages and make it impractical for large volumes of data. Most people have more bandwidth than storage.

[r3wt]

add dht as failover and you immediately have my interest.

DHT would reveal which node have which messages and make it impractical for large volumes of data. Most people have more bandwidth than storage.

hmm... so its practical for block chain storage but not for p2p messaging.

[nimda]

Most people have more bandwidth than storage.

Can you clarify that? Given infinite time and a nonzero internet speed, all people have more bandwidth than storage.

[🏰 TradeFortress 🏰]

Most people have more bandwidth than storage.

Can you clarify that? Given infinite time and a nonzero internet speed, all people have more bandwidth than storage.

OK, I was just saying that asking people to pass say 10 GB of data is less of a requirement than storing 10 GB of data. Because it'd take you 10 GB of bandwidth to store those data.

If you run a node, you'll probably want a lot of bandwidth and low latency for fast communications. You don't need to have much storage - the amount of storage you need is proportional to your anonymity settings, and the messages you send / receive - with it possible to have a static amount of space dedicated for "seen message or not" using advanced bloom filter implementations.

[tradeaway]

So basically you want each new message between the two nodes to be sent to a newly generated address, right?

[🏰 TradeFortress 🏰]

So basically you want each new message between the two nodes to be sent to a newly generated address, right?

Yes. This is OK because it doesn't matter if there are 100 addresses or 10,000 - there is no blockchain.

[r3wt]

So basically you want each new message between the two nodes to be sent to a newly generated address, right?

Yes. This is OK because it doesn't matter if there are 100 addresses or 10,000 - there is no blockchain.

then how the hell do you keep track of it? bring me back to my original point about dht  and datacentres.  how are you going to keep track of which addresses are in use at any given time with out a block chain, or at least leveraging magnet links(dht) to a datacentre(s) with the current database of addresses/keys

also, i think you will need to address things like collision and error handling. really is a great idea though. i'm all ears

[🏰 TradeFortress 🏰]

then how the hell do you keep track of it? bring me back to my original point about dht  and datacentres.  how are you going to keep track of which addresses are in use at any given time with out a block chain, or at least leveraging magnet links(dht) to a datacentre(s) with the current database of addresses/keys

also, i think you will need to address things like collision and error handling. really is a great idea though. i'm all ears

Track what?

[greBit]

I have also been thinking of similar ideas for enabling truly anonymous, censorship-resistant, communications between parties. I see it being a possible game-changer.

We can also go a lot further than just enabling person-person communication and replacing email. It could form a basis for building anonymity-by-design web applications.

For example - open source SilkRoad

Given a HTTP Api for the communications network, we could imagine having a community-auditable open-source 'silkroad' clone in the form of a Chrome extension. Silkroad functionality (browsing vendors/publishing adverts/communication) could be built upon the simple message primitives of the underlying network.

One concern I have is with the 'whitelisting' you mention. Could this be used to for example prevent all messages from 'wikileaks' being relayed. Or perhaps a powerful adversary, could track the IP addresses of nodes that relay ''wikileaks' messages in an attempt to unmask the real identities of the communication participants.

If I wanted to send a message to Bob, I would prefer that my message, M, appear as random encrypted rubbish to all network participants except for Bob, who has the private key for decryption and is the only other person able to tell that author(M) = me

I think I would prefer alternative spam prevention techniques such as by introducing a cost to store a message on the network.

[🏰 TradeFortress 🏰]

One concern I have is with the 'whitelisting' you mention. Could this be used to for example prevent all messages from 'wikileaks' being relayed. Or perhaps a powerful adversary, could track the IP addresses of nodes that relay ''wikileaks' messages in an attempt to unmask the real identities of the communication participants.

This is definitely a valid concern, however in practice I believe this will not happen as people can simply add nodse that do not cesnor messages. You are not limited to one node.

If I wanted to send a message to Bob, I would prefer that my message, M, appear as random encrypted rubbish to all network participants except for Bob, who has the private key for decryption and is the only other person able to tell that author(M) = me

I think I would prefer alternative spam prevention techniques such as by introducing a cost to store a message on the network.

The tradeoff of this is that nodes must store messages, and the system will no longer be free. People are happy to try out a new web app for free, but they will not want to pay.

I believe the current system can be very anonymous with automatic identity generation. While your first message may tell people who you communicate with if you sent it to a publicly listed identity, the client by default may randomly send a bunch of messages to random public identities to mask this.

[CIYAM]

I think there is a growing amount of demand for this - and Xenland has also been working on a very similar concept (P2P Crypt) - perhaps you guys should discuss this and combine ideas and/or resources?

Also if you are interested then CIYAM Open would be happy to help out with setting up a project (which can be managed by yourself) that would be fee free (all BTC addresses and tx's are handled by each Project Manager not by CIYAM Open).

As an example of what this might look like the Moneychanger project that is currently under development can be seen here: http://ciyam.org/open/?cmd=view&data=20130606055250338000&ident=M100V137&chksum=a2a9d6d5

[greBit]

The tradeoff of this is that nodes must store messages, and the system will no longer be free. People are happy to try out a new web app for free, but they will not want to pay.

Yeah I am in full agreement that the average user should not be forced to pay in order to send/receive email. That would be crazy and no-one would use it.

I'm just suggesting that attaching the identities in plain-text to every message may be a bit overkill to combat spam and cripples the anonymity of the network. It would make it far easier for an adversary to perform network analysis in order to figure out which private identities belong to which public identities, and correlate those private identities into IP addresses.

So im just wondering if there could be alternative solutions to help fight spam.

What would you do if a certain user, decides to send messages to himself. He makes a backup of his hard drive and stores 100gb worth of messages on the network.

Would the user be classed as a 'spammer' and just 'banned'?

Since storage of data has a real cost, it might be better for *some* use cases to make the user pay. This would make the system fairer and far more versatile.

If you allow the network to act as a 'dumb cloud' for applications, who pay for the pleasure, it could be revolutionary.

[🏰 TradeFortress 🏰]

What would you do if a certain user, decides to send messages to himself. He makes a backup of his hard drive and stores 100gb worth of messages on the network.

The network does not store messages, only relay them. Nodes store messages that are relevant to them. Read notifications would be used as indicators of a message needing to be rebroadcast.

I think there doesn't need to be any whitelisting actually! Just anti-DoS limitations per node. I am not too well versed on crypto, but I'm assuming that it's possible to encrypt a message so that it is rubbish to everyone else except to those with private keys to a specified list of public keys.

[Xenland]

I've been working on a prototype type called the "P2PCrypt" Codename: Dahlia and have came up with the exact specification after 2 years of research that you have posted. I have built numerous prototypes involving python, php, QT, C++, and "C" languages. So far QT/C++ is what I expect to be required from such a project.  (Some prototypes involve Beaglebone, USB microphones and wireless communications successfully transmitting/receiving across computers on a LANetwork)

Its an easy to use open source communications system that is ran from free and paid based incentives. It will eventually run off Namecoin and have it's own identity distributed network and some time in the future as well include hash cash to prevent spam, and to increase priorities from untrusted sources in a trust-able way. Lets start chatting about this

My latest prototype is made with QT/C++ (The server and the client is not posted up on my github yet, but you can find my older earlyer prototypes at my github https://github.com/Xenland/)

Simply put my vision for the future of Dahlia/P2PCrypt is to make it so the client can seemlessly communicate with any network protocal(IRC, AIM, G+, Facebook, etc), and it does this by use of decentralized relay nodes that do not need to be trusted (at the cost of more validation time -- at handshake). At first I'd imagine dahlia won't work with any networks at all that i listed earlyer(IRC, AIM, G+,etc), infact Dahlias main purpose it provide its own messaging relay network of its own that will be easy to use and reliable.

I hope to work more on dahlia when demand requires it and when I'm finished with the Moneychanger app.

[Xenland]

One more thing, I also have devised some research of including "relay reputation points" where as when you ping for your data you can ping for other relayed data that isn't related to your messages and help improve the network by helping bandwidth of relaying data, when you relay data, the network will award you relay reputation points (by some verifiable means). Its probubly a bad name becuase they are not reputation points they are just points that help other clients and relay nodes detect the likely hood of a MITM attack (so its more of a background point system and isn't something the users would be aware of, kind of like multiple Inputs/Ouputs of Bitcoin). Requesting data of random users' messages can help prevent snooping as the snooper can't tell which message to target cracking with out being an involved party member (which in that case is a trust issue not a networking communications issue).

UPDATE: I've been convinced by some BTC members who already knew about the Dahlia project to upload what I have so far for the Dahlia Client/Server code, I will be doing that tonight after I review everything for stableness.

[🏰 TradeFortress 🏰]

Umm, nice github avatar