Daniel Quinn

Well if you do decide to attach it exclusively to domains, you might want to consider developing a DNS TXT standard format so this sort of information can be stored in DNS and cached accordingly.

and I don’t see any value in limiting classification to the domain level. How would one classify wikipedia.org in this scenario? Would it not make more sense to define an open standard that’d leverage this system but allow domain managers to define it themselves?

To take my university.tld as the example, that university might host a file called at https://university.tld/ocs.json that looks something like this:

{
  "/": "EDU"
  "/math": "MAT",
  "/journalism": "JOU",
}

(Heads up to OP: there’s no journalism in your current spec. That feels like an oversight.)

This would allow the high-content site admins to classify parts of the site differently. The /ocs.json file might even be dynamically generated for complex sites like Wikipedia.

I’m curious as to why you’d limit this to the domain level. A university for example might have thousands of URLs in it with wildly different subjects:

• university.tld/math/student-name/thesis-on-mathy-subject/
• university.tld/journalism/student-name/big-story-about-politics

How would your system account for this?

Back in the days when WordPress started out, 1GB of RAM was a lot! You’d be surprised what you can do when you’re just running a server.

It sounds like a pretty cool project, thanks for sharing! As a browser-based project designed to run offline, you might want to consider shipping it as an electron app.

[LLM executes it to test]

This wasn’t nearly as interesting as the headline made it sound.

It’s a physical box you purchase to effectively break the law, so some of the architecture is going to be shady because it has to be.

• it polls multiple domain servers to get around blocks (and probably updates that list regularly)
• it obfuscates the endpoints it hits because they’re trying to secure a box they’re handing to someone else from tinkering that would allow people to access their (pirate) services without buying a box.
• it obfuscates its user agent when connecting to a weather service to avoid being blocked.

There’s nothing special or nefarious here. Indeed I’ve worked on projects that had to take the same considerations into account.

The “someone else’s Hulu account” claim sounds like bullshit to me because it doesn’t make sense from a business perspective. They’d want to control the accounts in question and rotate the passwords regularly, again to avoid freeloaders. More likely they’ve paid for 25ish Hulu subscriptions in every region (hence the initial call for IP geolocation) and are then relaying credentials to a box based on this info.

The only really sketchy thing in this whole video was the disabling of TLS checking, which was likely done to get around sketchy pirate websites with bad or nonexistent certs. It wasn’t clear though which part of the OS this applied to. If it’s only doing this for the pirate streaming, that’s sort of a bullet you have to take if you want the service. So long as the only data being sourced unencrypted/unverified is some audio and video, you’re fine (assuming you’ve already accounted for streaming such data in your jurisdiction, ie. you’ve got a VPN). If you’re pulling down software updates though, you’re gonna have a bad time.