I worked out this was odd behavior on my OPNSense firewall NAT rules.
For some reason some syncing worked (eg. beehaw.org) but new connections failed. I'm not sure why. Maybe established sessions were kept alive.
Those rules haven't changed in months and months, so I'll chalk that up to "weirdness".
Yeah, I’ve tried that a couple of times too.
And run through all the federation troubleshooting steps in the docs.
I thought that, and in the past I’ve been off for a day or two and always caught up.
This time I haven’t and it’s been a week or two since coming back online.
Given this is !privacy and the advertise as front page features both “works will all your messaging apps” and “end to end encryption”, it seems important to flag currently those aren’t mutually compatible.
It’s not their fault the apps don’t have e2e APIs, it’s a tough problem, but the secrecy and privacy guarantee is just “trust us to stick to our policy”. And they’re a start-up, tooling isn’t perfect (or even exist), mistakes happen, etc
Their self-hosting looks interesting, but then it said to use your own clients too, which took the fun out of that.
“For example, if you send a message from Beeper to a friend on WhatsApp, the message is encrypted on your Beeper client, sent to the Beeper web service, which decrypts and re-encrypts the message with WhatsApp's proprietary encryption protocol.”
So, not really end to end for most common use-cases.
I don’t think it’s about lemmy.
curl ifconfig.io works too
I agree, that would be more authentic. Or rig up an actual line printer.
But I think the fuzzy old terminal emulator at full screen gives you a more accurate view of an old curved, flickery, low-res screen.
Event a TTY on a modern screen is going to be higher res (far more than 80x24), nice crisp fonts, colors, etc.
Should have used https://github.com/Swordfish90/cool-retro-term instead of gterm for the real flickery tiny terminal experience
Depends a lot on your existing reverse proxy.
You can read the nginx config that the defaults include and it’s some basic rules to route incoming requests to either lemmy or lemmy-ui. If your existing reverse proxy is nginx you could just incorporate the rules in there.
It also depends on why you need it behind the existing proxy, and how you’ll choose to route your traffic, and where you traffic is coming from in general.
I’d start with taking a look at the default nginx config to see if you can move those rules to your existing reverse proxy, or just forward everything coming in that’s for lemmy straight to the lemmy reverse proxy, although that might be more complicated in correctly preserving the incoming requests.
One way is to run Pi-hole’s admin interface on a different port. That’s configured in:
Set:
Then your URL is http://IP:8000/admin