nybble41

Except it's not even that indirect. The government of Texas invented this novel class of private liability, and their courts are the ones enforcing it. That's the same as banning it themselves, and blatantly unconstitutional.

I'm a bit surprised they didn't implement this as a tax. That would be just as bad, but the federal government has a long history of imposing punitive taxes on things they aren't allowed to ban; it would have been harder to fight it that way without forcing an overhaul of the entire tax system… and politicians are so very fond of special-purpose taxes and credits.

"Normal world" knowledge often does play a part, but more than that I think part of the draw of isekai stories is that the audience can more easily empathize with a character originally from our world trying to make sense of the fantasy they find themselves in than characters who are from the fantasy world and thus don't find the setting particularly special.

It's not like straight fantasy stories have died out, though. In the current anime season alone you have Sousou no Frieren, Goblin Slayer, S-Rank Musume, and Mahoutsukai no Yome—and no doubt several more—where the protagonists are native to their respective fantasy settings. That's not even counting ones set in fantasy VRMMOs, which aren't exactly isekai either.

If you can read emails sent to a given address, and send replies from that address, it basically is your email address for all practical purposes no matter who was meant to be using the account. This is not necessarily a good thing and better end-to-end security would be nice but it is what it is. Odds are the app itself would let anyone change the password and log in provided they can read the emails, unless it's using some form of 2FA.

So you're not remapping the source ports to be unique? There's no mechanism to avoid collisions when multiple clients use the same source port? Full Cone NAT implies that you have to remember the mapping (potentially indefinitely—if you ever reassign a given external IP:port combination to a different internal IP or port after it's been used you're not implementing Full Cone NAT), but not that the internal and external ports need to be identical. It would generally only be used when you have a large enough pool of external IP addresses available to assign a unique external IP:port for every internal IP:port. Which usually implies a unique external IP for each internal IP, as you can't restrict the number of unique ports used by each client. This is why most routers only implement Symmetric NAT.

(If you do have sufficient external IPs the Linux kernel can do Full Cone NAT by translating only the IP addresses and not the ports, via SNAT/DNAT prefix mapping. The part it lacks, for very practical reasons, is support for attempting to create permanent unique mappings from a larger number of unconstrained internal IP:port combinations to a smaller number of external ones.)

What "increased risks as far as csam"? You're not hosting any yourself, encrypted or otherwise. You have no access to any data being routed through your node, as it's encrypted end-to-end and your node is not one of the endpoints. If someone did use I2P or Tor to access CSAM and your node was randomly selected as one of the intermediate onion routers there is no reason for you to have any greater liability for it than any of the ISPs who are also carrying the same traffic without being able to inspect the contents. (Which would be equally true for CSAM shared over HTTPS—I2P & Tor grant anonymity but any standard password-protected web server with TLS would obscure the content itself from prying eyes.)

Not every work produced by a LLM should count as a derivative work—just the ones that embody unique, identifiable creative elements from specific work(s) in the training set. We don't consider every work produced by a human to be a derivative work of everything they were trained on; work produced by (a human using) an AI should be no different.

I'm fairly certain that last one is UB in C. The result of an assignment operator is not an lvalue, and even if it were it's UB (at least in C99) to modify the stored value of an object more than once between two adjacent sequence points. It might work in C++, though.

No, that's not how I2P works.

First, let's start with the basics. An exit node is a node which interfaces between the encrypted network (I2P or Tor) and the regular Internet. A user attempting to access a regular Internet site over I2P or Tor would route their traffic through the encrypted network to an exit node, which then sends the request over the Internet without the I2P/Tor encryption. Responses follow the reverse path back to the user. Nodes which only establish encrypted connections to other I2P or Tor nodes, including ones used for internal (onion) routing, are not exit nodes.

Both I2P and Tor support the creation of services hosted directly through the encrypted network. In Tor these are referred to as onion services and are accessed through *.onion hostnames. In I2P these internal services (*.i2p or *.b32) are the only kind of service the protocol directly supports—though you can configure a specific I2P service linked to a HTTP/HTTPS proxy to handle non-I2P URLs in the client configuration. There are only a few such proxy services as this is not how I2P is primarily intended to be used.

Tor, by contrast, has built-in support for exit nodes. Routing traffic anonymously from Tor users to the Internet is the original model for the Tor network; onion services were added later. There is no need to choose an exit node in Tor—the system maintains a list and picks one automatically. Becoming a Tor exit node is a simple matter of enabling an option in the settings, whereas in I2P you would need to manually configure a proxy server, inform others about it, and have them adjust their proxy configuration to use it.

If you set up an I2P node and do not go out of your way to expose a HTTP/HTTPS proxy as an I2P service then no traffic from the I2P network can be routed to non-I2P destinations via your node. This is equivalent to running a Tor internal, non-exit node, possibly hosting one or more onion services.

They should still be using the CPU's built-in AES hardware acceleration, yes? It seems they have good reason not to trust the SSD to handle the encryption but that doesn't mean it has to be entirely implemented in software. CPU-accelerated AES shouldn't be that much slower.

It is not true that every node is an exit node in I2P. The I2P protocol does not officially have exit nodes—all I2P communication terminates at some node within the I2P network, encrypted end-to-end. It is possible to run a local proxy server and make it accessible to other users as an I2P service, creating an "exit node" of sorts, but this is something that must be set up deliberately; it's not the default or recommended configuration. Users would need to select a specific I2P proxy service (exit node) to forward non-I2P traffic through and configure their browser (or other network-based programs) to use it.

"Off topic" is a legitimate reason to downvote a post or comment, even one made respectfully and in good faith.

I do sometimes wish more sites had adopted something like the system Slashdot used, with multiple categories of up or down votes (insightful, informative, off-topic, flamebait, etc.) which users could weight according to their own preferences. The simplistic "either up, down, or neutral" model is a rather blunt instrument.

The more users spread out into smaller, more easily censored instances, the more the remaining fragmented bits of the Lemmy ecosystem still talking to each other will turn into echo chambers full of groupthink. This low threshold for defederation is the Fediverse's greatest weakness. Sure, it's possible to work around it—but how many separate Lemmy accounts are users expected to create? Even if you have accounts on every instance of note you'd need to manually cross-post messages to each balkanized server and their comment sections wouldn't be shared—exactly the sort of thing federation was meant to avoid.

Email, another federated system, has this same weakness. It's why it's increasingly difficult to run your own (outgoing) email server which other systems will accept messages from without going through a well-known third party like Google. Especially when trying to push content to a large audience (e.g. mailing lists), which happens to be Lemmy's core function.