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
signature.asc
Description: This is a digitally signed message part.
