Diaspora over Tor

[Martin Vahi]

A citation from 

    https://www.torproject.org/docs/tor-hidden-service.html.en

 In fact, because you don't use any public address, you can run a hidden service from behind your firewall.     

The way I understand, a pod behind firewall can find other pods through tor exit servers, but the pods outside of the tor network can not get back to the pods at the tor network, because they can not access the IP-address analogues of the tor network.

Given that Diaspora is meant to be a P2P application, it makes sense to allow people to run servers from homes, from behind firewalls, and have the accounts be virtual, mirrored, not firmly attached to a single pod. May be 

    https://www.spacemonkey.com/

might be an inspiration for parts of the specification.

Secondly, it would help a lot, if in addition to the "pods" there were "storage pods" that are PHP-applications that can run at cheap web hosting accounts. The accounts are cheap due to the lack of constant RAM usage: the PHP interpreter stays constantly in RAM, but the PHP applications initialize themselves at every request. That is a very different model from the servlet based approach, but despite its run-time wastefulness, at low traffic sites it's a real resource saver, if averaged. For floating accounts and mirroring the traffic of "Justin Biebers" and alike can be distributed among multiple pods, storage accounts, therefore making the architecture feasible.

Of course it's all easier said than done, but my question is, how much of it has already been done and is anybody working on it? 

I do not have time to work on it myself, but I want to summarize the requirements of different grass roots P2P projects, so that I can plan my projects better. So far I can offer only one, self-written, Ruby encryption tool that is too slow for encrypting files, but is optimized for e-mail encryption and is meant to be stronger than the GNU Privacy guard. 

https://github.com/martinvahi/mmmv_devel_tools/tree/master/src/mmmv_devel_tools/mmmv_crypt_t1

Given that public key crypto is fundamentally flawed, 

http://bitrary.softf1.com/index.php?title=Software_Development_:_Security_:_Cryptography#Why_Public_key_Cryptography_is_Fundamentally_Flawed

the mmmv_crypt_t1 is using the one-time pad

http://bitrary.softf1.com/index.php?title=Software_Development_:_Security_:_Cryptography_:_Onetime_pad

in a bit more general fashion:

http://longterm.softf1.com/specifications/txor/

My main point with the crypto story here is that may be some pods should have the ability to use symmetric key encryption and that's an architectural matter. Again, easier said than done and I'm just a troll here, telling things, not offering actual code. But, one way or another, I'm still interested to know, if You people have thought about those things at Your desing and if someone is working on something like that, then what parts of the code might I look at.

Thank You for reading my comment. :-)