Hello everyone,
I’m not really sure where to start here. I am attempting to how a Diaspora* Pod which is to be served over the Tor Network, and I have somewhat succeeded in getting it set up. I have a self-signed certificate that I have created via openssl, but the https version of the site will not load properly. I was getting a 404 error when trying to access the site via https and now it is a 403 error. If I use the non-https version it has limited functionality. I have so far managed to get the Pod to allow me to register after much fiddling with the various configurations and settings on my server. I would like some assistance so I can complete the establishment of my Pod.
I will try to upload some images here shortly so you all might better be able to help me. Though right now I am exhausted as I have spent 20+ hours of the past 48 hours working on this project and must sleep.
Just in case you missed it, Diaspora doesn’t support self-signed certificates:
By design, federation will not work with pods that have self-signed or invalid SSL certs installed.
Your pod won’t federate with others. I am not sure if it is possible to make it work as standalone server.
Not trying to be rude, but your response can be equated to a State Highway Patrol pulling me over when I’m doing 120 MPH in a Lambo on the freeway just to ask me if I realize the speed limit is 70 MPH. Haha, and in case YOU missed it: https://wiki.diasporafoundation.org/FAQ_for_pod_maintainers#Can_I_make_my_pod_private.2Fisolated.2Fnot_communicate_with_other_pods.3F
I am not trying to do that… My issues are resultant of other causes… I am testing this before I spend 300 bucks or so on a commercial cert my friend.
Looking for a much more technologically savvy response hehe 
Being rude to other people who want to help you is a bad move, @OTBTechnologies. Please go back to reading the rules you agreed on when signing up on this Discourse, and also go back to reading this project’s community guidelines before proceeding.
letsencrypt.org is a wonderful thing, and free.
Besides that, follow our official installation guides to set up a normal internet-facing pod. If that fails, come back and tell us what exactly fails, and we can dig into that. When your internet-facing pod is running, you can work on setting up a hidden service that allows to access said pod, but you need to get the base running first.
If that offends someone its more their problem that they were raised in a bubble than mine. It was friendly jesting.
Anyway, I did as you said but the images wouldn’t display properly as they were trying to be served over https and Lets Encrypt doesn’t work with onion sites so I used openssl. So, now what?
We don’t do that here.
I could just go back to modifying code myself or ask a friend of mine who is more familiar with Ruby since you all seem unlikely to be able to help me thus far. I understand Diaspora over Tor is unheard of and there seems to be this underlying tone from the both of you that you all typically deal with relatively less technologically inclined individuals so I totally understand. This is just very frustrating.
No fun zone. Got it.
As you clearly have a hard time understanding, I’ve allowed you some time to actually read the rules within the next 7 days before you can come back and post again. And if you continue behaving like this, rest assured that my next response will be less friendly.
Diaspora* over Tor is absolutely not “unheard of”. In fact, multiple pods offer a hidden service to enable users to access the pod via tor, and those pods do work quite fine. That does not change the fact that diaspora* needs internet-facing access for federation to work, you won’t be able to federate with pods like pod.geraspora.de, nerdpol.ch, or diasp.org (who, btw, is offering a hidden service at diasporgc3d32vv4.onion), as federation does not happen over tor, and is unlikely to ever happen over Tor because there is no need to do so.
If your images did not show up, it sounds like you goofed up the reverse proxy config (nginx or apache, that is). diaspora* itself does never serve images in production, mainly for performance reasons.
If you want any help, I’d suggest you share your reverse proxy config, and also explain what you did when “fiddling with the various configurations and settings on my server”, because it wouldn’t be the first time where such changes actually broke stuff, and we really don’t like debugging black boxes.
I am also curious about bringing up a small pod with tor as it’s primary means of access. Is there a reason for not allowing federation via tor ? On first pass, it seems tor solves a few hurdles for a small pod hanging on a typical household dynamic ip.
A pre-packaged pod running in a docker container on a raspberry pi 4 with tor as it’s federation transport seems useful.
First of all diaspora* is a server application that expects to be running and online 24/7.
More importantly, the fewest servers in the network would know how to reach an .onion address. Thus they simply don’t know how to reach your server and cannot send you any messages.
It’s not that the software doesn’t allow it, it’s that in the current ecosystem there’s no practicality to it.
There’s no issue with making a regular setup also reachable as a hidden service, that’s a pure webserver configuration that can be fully transparent to diaspora.
That makes sense.
If I understand then a diaspora* server setup with tor could use the tor network for 1) outbound delivery to other diaspora* servers ( public dns or .onion address), 2) be reachable as a .onion address, and 3) be reachable as a public dns address.
As you say, the diaspora* server needs to be reachable at a public dns address to effectively participate in the diaspora* ecosystem.
It would seem that tor2web could solve that problem by publishing your diaspora* server’s dns address to other diaspora* servers as an .onion.to address. (https://www.tor2web.org/)
“Solve” as in introducing a central failure point to a decentral design, yes 
Honestly, providing a hidden service to users makes sense. Everything beyond feels like doing it for the sake of it, not to any practical benefit.
But then even for the hidden service usecase, diaspora* is just not designed to be used to evade state surveillance. Please don’t advertise it as such over systems that are and much better suited as such. Claiming diaspora* would serve this usecase, is in the extreme putting people’s life at risk. Please just don’t.
It seems to me the primary central point of failure would still be the single instance of the small pod itself.
The benefit I see is not having to get a static IP and domain, or use a dynamic dns service.
Avoiding state surveillance isn’t the driver. The autonomy of an .onion address is a benefit in itself.