OHAI, Dnia czwartek, 15 maja 2014 16:39:51 Cathal Garvey pisze:
Little proprietary walled gardens are absolutely not the answer for this problem.
How could we make a secure solution that plays nicely with the current tools without disturbing too much what is already established?
By writing a gateway (i.e. between RetroShare and e-mail)?
The gateway idea is interesting, but it has to be efficient enough and low cost enough for people to switch over. Something like bitmessage is not.
I actually think, having used it for some time and liking it on the whole, that Retroshare isn't suited to this.
The primary reason is RS only receives mail if the sender and recipient are online at the same time. There's no store-and-forward, even though all messages are PGP encrypted to recipients.
Wouldn't that be possible to change? For example by creating store-and-forward servers that would not be *required* for RS operation, but would add this as an added feature?
RS also has a lot of feature-bloat; it's better thought of as P2P Facebook than a simple communication system.
That is very true.
Finally, RS is engineered to a simple and admirable purpose which makes it unsuited to email replacement; it's Friend to Friend. That's great in its use-case, but I think email should be:
1) Rapid and censorship-resilient routing 2) Single canonical addresses for each participant, which are human-readable. 3) Churn-tolerant 4) Expensive to send, to deter spam otherwise facilitated by to (1) 5) Practical for payloads between 10M and 20M, no greater.
I do *not* think the core of a replacement email should guarantee anonymity, but the protocol should make allowances for that if possible.
It should at least guarantee pseudonymity, IMHO.
I think the above could be satisfied using a pseudo-blockchain for name->key mappings, and a key-routed DHT for creating routes for mail delivery. Credit is earned by routing other people's mail in store-and-forward fashion, like email. Credit can be spent to register new mail address:key mappings and to pay for routing of larger messages, or to prolong retention of messages before they bounce (if your intended recipient does not run a high-uptime mailserver and may need a day or two to log in).
Interesting.
That resembles Twister, the coupling of DHT:Blockchain, but may be better suited to the model than twister is (because twister hit problems with scaling DHT use to many followers, I think),
https://github.com/miguelfreitas/twister-core/issues/24 https://github.com/miguelfreitas/twister-core/issues/165
because email is slower and stabler than microstatus systems; more amenable to P2P-isation, whereas rapid updates coupled with mass-queries to other feeds is a setup better suited to a client:server interaction. The blockchain would need tweaking, because Twister is using scrypt, which is now apparently ASIC-able, e.g. useless. I think a password encrypting function whose parameters are set dynamically by the value of the prior block might help fix matters; the goal is for the ideal "ASIC" for the function to be a consumer CPU, not a GPU or dedicated ASIC.
Makes sense.
Anyway, sorry for the wall of text. Killing/replacing email is often on my mind.
Yeah, I also have a love-hate relationship with this communication medium. -- Pozdr rysiek