summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorelijah <elijah@riseup.net>2014-02-03 14:10:20 -0800
committerelijah <elijah@riseup.net>2014-02-03 14:10:20 -0800
commit9835c7efeaa19dbce59390042952277c39127427 (patch)
treefc5a0cb6d08eb1ee22fb84995fc867911f520c35
parent2da6d2105513613cdbb16c665692139f1b0f379a (diff)
added note on how pond does routing
-rw-r--r--docs/tech/routing.md2
1 files changed, 2 insertions, 0 deletions
diff --git a/docs/tech/routing.md b/docs/tech/routing.md
index 948d4c3..46af93f 100644
--- a/docs/tech/routing.md
+++ b/docs/tech/routing.md
@@ -17,6 +17,8 @@ There are four strategies we might employ to add protection of routing informati
* Onion-routing-headers: A message from user A to user B is encoded so that the "to" routing information only contains the name of B's server. When B's server receives the message, it unwraps (unencrypts) a supplementary header that contains the actual user "B". Like aliases, this provides no benefit if both users are on the same server. As an improvement, the message could be routed through intermediary servers.
* Third-party-dropbox: To exchange messages, user A and user B negotiate a unique "dropbox" URL for depositing messages, potentially using a third party. To send a message, user A would post the message to the "dropbox". To receive a message, user B would regularly polls this URL to see if there are new messages.
* Mixmaster-with-signatures: Messages are bounced through a mixmaster-like set of anonymization relays and then finally delivered to the recipient's server. The user's client only displays the message if it is encrypted, has a valid signature, and the user has previously added the sender to a 'allow list' (perhaps automatically generated from the list of validated public keys).
+* Direct-delivery: Instead of relaying messages from client to server to server to client, in this model the sender's client delivers the message directly to the recipient's server. This delivery would need to happen over an anonymization network akin to Tor, or through proxies set up for this purpose. In order to prevent spam, the recipient server would only accept messages delivered in this manner if the message was signed using a group signature (this ensures that the server doesn't know who the sender is, but can confirm that they are allowed to deliver to a particular user). This would require advanced confirmation on the part of both users that they may send messages to one another. This is how Pond works.
+
None of these are currently used for email or chat.