Sven Slootweg @joepie91@pixie.town

Basically, learn to say "I don't know" or "the best solution I've been able to find...".

I really dislike how shaky of a grip developers seem to have on the distinction between 'truth' and 'opinion', and how little care they often take to distinguish between the two in how they communicate.

You can measure objective truth for something with clear, exhaustive parameters and outcomes. You can't do so for something that's based in personal beliefs or limited perspective! And likewise, when there *is* an objective truth, it's not a matter of opinion either.

It's not a surprise that misinformation spreads so readily in software development circles, if you look at how eg. a lot of new programmers are constantly faced with 'senior developers' framing their personal preferences and conclusions as the ultimate and only truth.

Federation isn't always the right answer, when designing a self-hosted or autonomous software thing. Here are some reasons why it might not be (non-exhaustive):

1. Difficulty of moderation - you not only have to account for the users on your own service, but also that on every other service. This will be a familiar one to many fedi instance admins.

2. Difficulty of limit enforcement - if you're trying to keep the content size manageable by eg. introducing storage limits, it's hard to enforce these across the federation, as anyone can change the limits on their instance and it'd be weird if eg. large files are allowed from external users but not local ones. And blocking large external data is essentially partial defederation, and gets messy.

3. Protocol lock-in - the more interoperable instances you have of something, the harder it becomes to change anything in how it works, because everyone will have to agree with you on the change, at least to a point of compatibility.

4. Network traffic - content has to be distributed between servers, and that can generate quite a lot more traffic than you would expect. Not always a downside; it depends on whether the federated content is actually being accessed frequently on remote servers, because if so, you otherwise would've had to serve all those users directly. But this often isn't the case with opportunistic federation of data.

5. Context collapse - it is very difficult to provide a global network view across a federated network, at least in a way that doesn't use absurd amounts of resources. In practice everyone will usually only see a part of the network, and that can rip eg. conflicts out of their original context, causing them to escalate unnecessarily.

Note that most of these apply to fully-decentralized systems too (and those have some problems of their own); often the optimal solution is many self-hosted centralized instances, rather than full decentralization or P2P systems.

There are definitely some cases where federation still makes sense, like in a chat system where semi-universal reachability is the point, much like a phone network.

But federation isn't free; don't make something federated just because you can; often it's better to run many copies on single servers, and maybe just share an account or identity system, or some similar 'restricted' form of interoperability.

Ended up on the LTT subreddit by accident, on a thread about the Honey scam, and all I can say is: what on earth is going on there?

Everybody there seems to be losing their shit about MegaLag's video supposedly being a hit piece on LTT and I have to wonder whether they saw an entirely different video than I did, because I'm not sure anyone outside of that community is perceiving it as such. Far as I can tell there was some mild criticism in the video about LTT not denouncing their sponsor more clearly and that's it?

The 'emergent communities' mechanism of fedi is kinda neat, like how communities form from mutual relations without clear boundaries, however it also means that there's no way to say "this community is at its maximum sustainable size, we are not accepting any new members" and that's a problem actually