Yes, and AI

++1 :-))

good one!!!

If my phone has a VPN to my home server, then it should all be encrypted.

Yes, but it wont work for sharing mobile internet because VPN doee not apply to tethering unless you have root. On Android there is also WiFi direct, but it's not very reliable and require proxy / not work for everything.

> But notice how you just did a much better job of explaining what this thing does without using any jargon at all.

There was plenty of jargon and acronyms like LAN and SSH. You're just used to those ones.

I still think the Rio Karma looked good and it had a good interface: https://en.wikipedia.org/wiki/Rio_Karma

I've still got it somewhere but the HDD has died.

The Karma looks interesting – not ugly, not pretty, but kinda unique.

I had a Rio 500 [1], which I wouldn't call ugly, but certainly not beautiful and it felt like a cheaply made plastic box, even though it was expensive (64 MB flash!).

[1] https://en.wikipedia.org/wiki/Rio_500

Cheaper to just use the wifi access that 99% of TVs will be given.

> The server just returns HTML (not JSON, actual HTML)

Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable.

That way all of the front end code is in one place.

But the front end code is in one place, and that place is the server. It is true, though, that the experience greatly benefits the easier it is to manage and return partials from backend code. Some frameworks make it harder than others.

I'd rather have the often loaded static html running on a server that is optimised for that job, or served from a cache close to the user. The backend can then just serve up the dynamic content and be optimised for that job.

The 'often loaded' static html won't help if the 'often loaded' JS bundle is re-deployed (eg, when the devs make a 'small' change) and the cache is invalidated. In that case all the users will be forced to reload the giant JS bundle over and over again, as opposed to just reloading a single resource on a single page like they would with the htmx approach.

In the simplest web server, the server returns HTML. Having the backend return JSON is where you're adding complexity. Your front end code won't even work without some base HTML.

Having the html stored both on a static html site that can be cached and in the code base of a backend server is more complex to me than keeping these concerns separate.

That's why you just have the HTML in the backend server codebase...which can also make sure it's cached properly with HTTP caching techniques like last modification time, ETag, and so on.

What does the app give you that the website doesn't? I've never tried it as the website works just fine.

Just ease of use on a small screen really. I don't use it too much anymore anyway, I'm in Australia, so Amazon's not as big here as it is in the US. We mainly use Ali-Express or Temu, because those apps deliver from China, which is close and more convenient for here, relative to the US.

> Don't worry, when you blackhole the entire tiktok domain, you'll still be able to use grindr.

Grindr can still sell your data.

It was a response to same-origin tracking. I didn’t claim grindr would not sell your data.

Thats a shame, I used to be able to pass fake location data through on an app by app basis using an Xposded module. That was probably 10 years ago though.

Also it shouldn't be allowed in Supermarkets