MeowdyPardner

I’ve been happy with the tp link TV-IP324PI, it’s a Poe bullet cam with a simple web interface (I don’t think it requires JS, but at any rate you just need to log in once to set a password, make sure upnp is off, and adjust camera/encoding/fps/text overlay settings to your liking). There’s also the amcrest IP5M-B1186EW-28MM, another similar Poe bullet cam with night vision that works local only. I’ve used both for several years and I think they support onvif but I had no issues using the rtmp url with zoneminder

Ubuntu 22.04 with docker, no issues it’s pretty barebones and easy to manage / update

I would recommend getting a separate client radio device for several reasons:

• You can position it better for reception
• Get a device with directional antenna so you can point it at the best AP
• You won’t use up 1 band of a dual-band router
• You won’t be limited in your main router firmware choice to only those that support client mode on a radio

Personally I would get a nanostation loco 5ac (non-loco is bigger and probably isnt needed) and flash openwrt on it (that will free any airmax radio from the proprietary airmax limitation), configure the 5GHz radio to client mode with the apartment wifi details, and put in the desired mac into the mac field if you need a specific mac besides the device default. Make sure the radio is set to wan zone so that forwarding works and plug the lan cable from the radio to the WAN of whatever nice router you have.

I used to carry around a nanostation with this config set to xfinity access points with a small script that would pick a random MAC from a list I gathered from wardriving client MACs that I saw authenticated with xfinity hotspots. That way if I ever needed an ethernet connection for a non-wifi device I could just power up the radio and run the script to pick a new mac until I got one that was “remembered” in someone’s xfinity account.

Edit: to clarify, I think the way I set it up was to run dhcp client on the radio’s uplink and then hand out IPs via dhcp server on the lan port, so I think you’d be triple natted, but since you would need to double nat anyway to get around the MAC authorization it probably isn’t hurting speeds any more than it already would be.

This is the solution. I reverse proxy from a digitalocean droplet running haproxy which sends traffic via send-proxy-v2, then I set the tunnel subnet as a trusted proxy ip range on traefik which is what haproxy hits through the tunnel, which causes traefik to substitute in the reverse proxied original ip so all my apps behind traefik see the correct public IP (very important for things like nextcloud brute force protection to work)

Hetzners risk averseness is so annoying. I tried to sign up and rent a dedi to replace my rack mount nas. Considering electric costs I was happy to pay a few hundred a month for substantial storage. Didn’t realize they didn’t accept privacy.com cards (I don’t even use them to cancel, it’s just so I can change banks and switch 1 billing link instead of 100). Account rejected and deleted and no response from support.

The only realistic thing that the NDA could have contained was stipulations around leaking details about Threads. Who cares. Some admins probably wanted an inside look so they agreed to not leak any details. That does nothing to put their instances under the control of Meta. Yeah sure the admins are “controlled by the contract”… to not share any secrets about Threads. Again who cares.

People dreaming up scenarios about the NDAs including clauses that let Meta control instances or their admins are delusional. As someone working in tech I sign NDAs all the time when I visit my friend’s companies. It doesn’t mean they have any control over me besides stopping me from leaking stuff that I see inside the company.

Doesn’t authenticated fetch kinda fix that? If users have the option to make their account private except to logged in other users, and if the server enables authenticated fetch to reject access from blocked / de-federated servers, then only logged in users from servers the server grants access to federate with will be able to view the content. That seems like some useful measure of privacy at least.

I don’t necessarily disagree, I just think that the solution is to cultivate the content here. Not connect with the same old corporate platforms that caused the problems in the first place.

My own hypothesis is that it’s not as much about EEE in the way that people understand it, or about stealing the small amount of users on the fediverse, but more about hedging against the possibility that the fediverse gains significant mainstream appeal. By having one foot in the fediverse they can better capture the fedi-curious. I don’t think the fediverse is currently a threat, but the possibility that it could be I think is what they care about. And spinning up Threads is a cheap (for them) way to address that.

It uses the zip archive feature that they allow you to request and export so at least it doesn’t use a direct connection or API. I think there is also some EU rule or something about requiring it because Dansup was asking about filing a complaint because of the export format being convoluted or something, not sure of the details but hopefully that means there’s some legal weight to the export feature sticking around.