Check out this one: https://thegradient.pub/othello/

In it, researchers built a custom LLM trained to play a board game just by predicting the next move in a series of moves, with no input at all about the game state. They found evidence of an internal representation of the current game state, although the model had never been told what that game state looks like.

The name of the color according to Bricklink is “Satin Trans-Brown”, here’s the link to it: https://www.bricklink.com/catalogItemIn.asp?P=44375b&colorID=229&in=A Seems to have a couple of different numbers, Bricklink lists it as “44375b”, molded on the piece it says “35327”. By now I also have that dish in Satin Trans-Light Blue, which might actually look better on the snail

Oh wow, been ages since I’ve seen that term last! Thanks!

For note taking, you might even get by without self-hosting, looking at software like Obsidian which works perfectly fine with just SyncThing to sync between devices, or just literally any other file syncing solution, self-hosted or otherwise.

I know that, but if that’s not the goal, then what else do they hope to achieve by implementing ActivityPub? It means they plan to federate with the larger fediverse, and you can bet that there’s a carefully calculated business reasoning behind it.

ActivityPub was just an easy protocall to build off of quickly

If they didn’t want to federate, they wouldnt have a need for ActivityPub or any kind of similar protocol.

Genuinely curious, why do you not like PWAs?

I don’t think it’s quite that bad/simple. Viewing your main instance as the Controller and other instances as Processors in GDPR terms won’t work, because instances don’t have the necessary control over each other for that, as you say.

However, you could circumvent that issue by making the case that each instance actually acts as an independent Controller. By participating on a federated service, you are explicitly agreeing to the data you provide (your profile, posts, comments, etc.) being made public and shared with other compatible services. That should be enough as the basis for other instances to reasonably assume you want your data to be processed by them, which (I think, not a lawyer) is sufficient justification for processing the data independently, as long as it’s in line with how you generally expect the fediverse to work.

This would mean that each federated instance is its own, independent entity that processes your data, and to make use of your rights under GDPR, you need to do that with each of them individually. They effectively become their own “original data collection point”, in your words, even if that data collection was not explicitly triggered by you.

The only thing missing for that to be legal (again, in my layman’s view) is transparency about who’s processing your data and how, which is necessary under GDPR. Every instance that receives your data via federation would need to let you know about that, and make available to you information on how exactly your data is processed and how you can make use of your rights under GDPR with them. That, in turn, would probably be easiest if the protocol spoken between fediverse servers were extend with automated and standardized ways to propagate GDPR requests from your home instance to any other instance that is processing your data, so that you don’t have to actually deal with every single server yourself to get your rights enacted. Defederation in the meantime might be a problem, but there’s ways around that, too.