Pages:
Author

Topic: Passage: open source secure, fast communications network - page 2. (Read 2757 times)

vip
Activity: 1316
Merit: 1043
👻
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.
Pages:
Jump to: