Melmi

LLMs are very good at giving what seems like the right answer for the context. Whatever “rationality” jailbreak you did on it is going to bias its answers just as much as any other prompt. If you put in a prompt that talks about the importance of rationality and not being personal, it’s only natural that it would then respond that a personal tone is harmful to the user—you basically told it to believe that.

Classic

mom-and-pop style datacenters

I find this wording very funny for some reason. I do wonder what a more-decentralized internet would look like though, rather than 90% of it being in the hands of a few megacorps.

The cursed LLM thing uses buttplug.io on the backend, I just wanted to share it because the premise is very funny to me.

You’re in luck

Tailscale is just a bunch of extra fancy stuff on top of Wireguard. If you don’t need the fancy stuff, using raw Wireguard can be more lightweight, but might require more networking knowledge.

The biggest thing Tailscale brings you the table is NAT traversal. On top of that it uses direct Wireguard tunnels as necessary instead of creating a mesh like you usually would if you were using raw Wireguard. It also offers convenient bits of sugar like internal DNS, and it handles key exchanges for you so it’s just generally easier to configure. When you do raw Wireguard you’re doing all the config yourself, which could be a pro or a con depending on your needs—and you’ll be editing config files, unlike Tailscale which has a GUI for most things. It also supports some more detailed security options like ACLs and I think SSO, while Wireguard is reliant on your existing firewall for that.

Here’s what Tailscale has to say about it: https://tailscale.com/compare/wireguard

I’ve messed around with Tailscale myself, but ultimately settled on running Wireguard. The reason I do that though is because I trust my LAN, and I only run Wireguard at the edge. Tailscale really wants to be run on every node, which in turn is something that raw Wireguard theoretically can do but would be onerous to maintain. If I didn’t trust my LAN, I’d probably switch to Tailscale.

A lot of people have suggested Tailscale and it’s basically the perfect solution to all your requirements.

You keep saying you need ProtonVPN which means you can’t use Tailscale, but Tailscale actually supports setting up an exit node which is what you need. Put Protonvpn on the Raspberry Pi, then set it up as an exit node for your tailnet. There’s a lot of people talking about how they did this online. It looks like they even have native support for bypassing the manual setup if you use Mullvad.

As long as every client has the ability to use Tailscale (I.e. no weird TVs or anything) this seems like it checks all your boxes. And since everything is E2EE from Tailscale, TLS is redundant and you can just use HTTP.

I’m not a lawyer so this is just my layperson’s read, but looking at the actual law it seems like in order for it to actually count as “deceptive” it needs to be presented as real. If there’s a disclaimer saying it’s fake, it wouldn’t be illegal under this law, so it seems like satire isn’t the main target.

One use for wireguard in a container is that if you’re using other containers on the same host you can use container magic to route the traffic of specific containers through the wireguard tunnel, while other containers bypass the tunnel.

I kinda of lean towards the idea of “private accounts” being a bad idea as a result, just because it creates a false sense of security. But I’m not in the target demographic so idk

The issue is that if you don’t default to federation, it becomes essentially impossible for new instances to join the fediverse. A potential new instance would have to go around to every single existing instance and ask to be allowlisted, which is onerous for both the new instances and for the large server admins who would be getting tons of requests. It would also essentially kill small-scale selfhosting as a result.

Most people earn their currency in-game, which would make it awkward to have a real-world conversion attached to everything—especially when there’s no way to pull it out so it’s not really meaningful.

It’s already hard enough getting people to undock and risk their internet spaceships, it’d be even harder if there were little real-world price estimates attached to everything.

A better solution would be to attach the prices only to PLEX (the premium currency), since that’s what maps directly to real-world money and would be what you’re spending your money on. They could also post the going exchange rate for euro to isk on the market itself without having to attach price tags to every individual item.

A big part of IPv4’s persistence I think is that people insist that IPv6 is complicated, but then refuse to learn it or think outside their IPv4-brain. It’s just different enough that it’s easier to stay in v4, even if it requires a million hackjob fixes to keep around.

If anything is to blame for that, it’s the lack of momentum behind IPv6. We’re out of IPv4, so NAT is inevitable, and IPv6 doesn’t have enough inertia for single-stack to be viable (certainly wouldn’t be described as “no drama” at least).

The brigading wasn’t from the same person who made the pull request, and happened three years later. The thread isn’t even that toxic as far as GitHub threads can get.

It’s not a great example of what you’re talking about.

Indexes start from zero because they’re memory offsets, but array[0] is still the first element because it’s an ordinal number, not an offset. It’s literally counting each element of the array. It lines up with the cardinality—you wouldn’t say ['A', 'B', 'C'] has two elements, despite array[2] being the last element.

deleted by creator

When done correctly, the banner is actually a consent banner. It’s a legal thing, not necessarily trying to discourage criminals. It’s informing users that all use will be monitored and it implies their consent to the technology policies of the organization. It’s more for regular users than criminals.

When it’s just “unauthorized access is prohibited”, though, especially on a single-user server? Not really any point. But since this article was based on compliance guidelines that aren’t all relevant to the homelab, I can see how it got warped into the empty “you no hack” banner.

But how will you get a “universal” view of the fediverse? No single authoritative view exists.

You yourself acknowledge that this is complicated, but I honestly don’t understand what appeal a hacked together fake centralized system would have for people if they don’t care about decentralization in the first place. Any such solution is almost inevitably gonna end up being janky and hacked together just to present a façade of worse Reddit.

Lemmy’s strength is its decentralization and federation. It’s not a problem to be solved, it’s a feature that’s attractive in its own right. It doesn’t need mass appeal, it’s a niche project and probably always will be. I don’t think papering over the fundamental design of the software will make it meaningfully more attractive to the non-technically minded.

Yes, but only if your firewall is set to reject instead of drop. The documentation you linked mentions this; that’s why open ports are listed as open|filtered because any port that’s “open” might actually be being filtered (dropped).

On a modern firewall, an nmap scan will show every port as open|filtered, regardless of whether it’s open or not.

Edit: Here’s the relevant bit from the documentation:

The most curious element of this table may be the open|filtered state. It is a symptom of the biggest challenges with UDP scanning: open ports rarely respond to empty probes. Those ports for which Nmap has a protocol-specific payload are more likely to get a response and be marked open, but for the rest, the target TCP/IP stack simply passes the empty packet up to a listening application, which usually discards it immediately as invalid. If ports in all other states would respond, then open ports could all be deduced by elimination. Unfortunately, firewalls and filtering devices are also known to drop packets without responding. So when Nmap receives no response after several attempts, it cannot determine whether the port is open or filtered. When Nmap was released, filtering devices were rare enough that Nmap could (and did) simply assume that the port was open. The Internet is better guarded now, so Nmap changed in 2004 (version 3.70) to report non-responsive UDP ports as open|filtered instead.