How have I made your point at all?

You have acknowledged the importance of having multiple points of failure. It’s a good start because the defect at hand is software with a single point of failure.

You're a bit incoherent with what you're talking about.

I suppose I assumed I was talking to someone with a bit of engineering history. It’s becoming clear that you don’t grasp software design. You’ve apparently not had any formal training in engineering and likely (at best) you’ve just picked up how to write a bit of code along the way. Software engineering so much more than that. You are really missing the big picture.

This has nothing to do with software design or anything else along those lines.

What an absurd claim to make. Of course it does. When software fails to to protect the data it’s entrusted with, it’s broken. Either the design is broken, or the implementation is broken (but design in the case at hand). Data integrity is paramount to infosec and critical to the duty of an application. Integrity is basically infosec 101. If you ever enter an infosec program, it’s the very first concept you’ll be taught. Then later on you might be taught that a good software design is built with security integrated into the design in early stages, as opposed to being an afterthought. Another concept you’ve not yet encounted is the principle of security in depth, which basically means it’s a bad idea to rely on a single mechanism. E.g. if you rely on the user to make a backup copy but then fail to protect the primary copy, you’ve failed to create security in depth, which requires having BOTH a primary copy AND a secondary copy.

This is a simple thing. If your data is valuable you secure it yourself.

That has nothing to do with the software defect being reported. While indeed it is a good idea to create backups, this does not excuse or obviate a poor software design that entails data loss and ultimately triggers a need for data recovery. When a software defect triggers the need for data recovery, in effect you have lost one of the redundant points of failure you advocated for.

When you reach the university level, hopefully you will be given a human factors class of some kind. Or if your first tech job is in aerospace or a notably non-sloppy project, you’ll hopefully at least learn human factors on the job. If you write software that’s intolerant to human errors and which fails to account for human characteristics, you’ve created a poor design (or most likely, no design.. just straight to code). When you blame the user, you’ve not only failed as an engineer but also in accountablity. If a user suffers from data loss because your software failed to protect the data, and you blame the user, any respectable org will either sack you or correct you. It is the duty of tech creators to assume that humans fuck up and to produce tools that is resilient to that. (maybe not in the gaming industry but just about any other type of project)

Good software is better than your underdeveloped understanding of technology reveals.

Thinking that a federated service is going to have a uniform or homogenous approach to things is folly

Where do you get /uniform/ from? Where do you get /homogenous approach/ from? Mbin has a software defect that Lemmy does not. Reporting mbin’s defect in no way derives and expectation that mbin mirror Lemmy. Lemmy is merely an example of a tool that does not have the particular defect herein. Lemmy demonstrates one possible way to protect against data loss. There are many different ways mbin can solve this problem, but it has wholly failed because it did fuck all. It did nothing to protect from data loss.

on your end and a failure of understanding what the technology is.

It’s a failure on your part to understand how to design quality software. Judging from the quality of apps over the past couple decades, it seems kids are no longer getting instruction on how to build quality technology and you have been conditioned by this shift in recent decades toward poorly designed technology. It’s really sad to see.