If this is about a personal relationship, all you should focus on is minimizing harm. Assume that any fear on one party is valid, and help to keep them separate from a potential attacker. Don't invalidate the feelings of either party - we may not always get to learn the truth, but many times we have to mitigate with incomplete information, but also that it is not your responsibility to fix alone. Remember that your strength is for protection, not destruction. Everyone sees things differently, including you, so there might be red flags that one party sees clearly that you missed - assume their judgment is right. If you are super positive, double checked, super sure that there is no risk of harm, then you dont need to directly intervene, but you can still emotionally support both sides without invalidating the other one, and it's their loss if this is only about turning you into the rope in a tug of war for attention. Make some different friends if this is only about manipulating you.

If this, however, is about politics, then you must remember that the only true natural law is that the biggest army wins, therefore, there is no such thing as neutrality. You cannot stand for all sides, nor should you stand for nothing and you should move to protect your family, friends and community from acts of hatred. Use your strength for protection, never against the weak and powerless, lest your own alliances and friendships be short lived; History shows repeatedly that movements formed from hatred are weak, short sighted, make poor allegiences, never learn from history, and are self destructive. Distrust any source of information that makes you feel scared and angry - especially if they use stereotypes to do so - since these are wedges to separate you from your community and to keep you addicted to propaganda. Keep your sources of information as varied as a healthy diet would be. And never ever, no matter how bad things seem to get, lose your faith in humanity. In the art of trying to be well informed, you will stare into the abyss. And the 1/3 of the human population made of evil hearts will dominate this information. You wont hear any of the other 2/3. Especially that last third made of good hearts. Hold onto this hope, and you will know any voice against the whole of society is wrong.

Sad to hear about ID. They're often the only Nestle competetor in the cream section. Black coffee it is then.

That's because authoritarianism isnt an idealology outside of authority worship, it just hijacks the surrounding culture, reclaims it for itself, and transforms all symbols into meaningless team colors. Notice how trump supporters say they represent democracy and freedom despite being opposed to it. Or how christion authoritarians throw around Jesus's name without understanding a word he ever said. Or how Stalinists insist that they're left leaning communists despite cheering for the tanks that crush their comrades. This pattern continues worldwide and affects every nationality and religion.

Authoritarians dont have principles. They have loyalty only, they cannot comprehend non-loyalty principled thinking, and so they see symbols only as a team identifier.

Political compasses dont work for principled worldviews, because principled worldviews cant be graphed on axes. It's just a horoscope effect. Principled worldviews are distinct like pokemon types are. They have to be individually studied to be understood. It is not possible to extrapolate from your first beleif system.

Responding as a java/kotlin maintainer of one single large system with frequent requirement changes. what i call "high entropy" programs. Other developers have different priorities and may answer differently based on what kind of system they work in, and their answers are also valid, but you do need to care about what kind of systems they work on when you decide whether or not to follow their advice.

In my experience, if the builder of the original system didn't care about maintainability, then it's probably faster to rewrite it.

Of course, then you'd have to be able to tell what maintainable code looks like, which is the tricky part, but includes things like,

• Interfaces
• Dependency injection
• Avoidance of static or const functions
• Avoidance of "indirect recursion" or what I call spaghetti jank that makes class internals really hard to understand.
• Class names indicate design patterns being used. Such as "Facade". This indicates that the original builder was doing some top-down software design in an effort to write maintainable code.
• Data has one, and only one, source of truth. A lot of refactoring pain comes from trying to align multiple sources of truth, since disgreements cause mayhem to the program state.

Bad signs:

• Oops, all concrete classes.
• Inheritance. You get one Base Class, and only one, before you should give the code the death glare. Its extremely difficult for a programmer to be able to tell a true "is a" relationship from a false one. For starters you have to have rock solid class definitions to start with. If the presence of Inheritance smells like the original builder was only using it to save time building the feature, burn it with fire! Its anti-maintainable.
• Too much organizing - you have to open 20 files to find out what one algorithm does. That's a sign that the original builder didn't know the difference between organizing for organizing sake and keeping code together that changes together.
• Too little organizing - the original builder shoved eveything into one God class so they could use a bunch of global variables. You'd probably have a hard time replacing a component so big. Also, it probably won't let you replace parts of itself - this style forces you to burn down the whole thing to make a change.
• Multiple sources of truth for data: classes that keep their own copies of data as member variables are a prime example of this kind of mistake.

Don't do meth.

Ah, so that's what the pro gamers are doing.

It's one of those pads you put on top to keep dirt from getting in between the keys

As someone with stubby, short legs, I'm always partying like it's 1999.

Apple and Google's 30% not only hits the base price, but every single transaction that happens inside apps as well. Imagine a toll bridge in front of your nearest supermarket where the people working the toll booth inspect every bag of grocery you bought and then charged you toll based on what you bought there.

Apps arent entirely like video games. If you wanted to open a non-subscription based music store or book store or whatever, you'd find it economically impossible to pay the publishers their cut, apple their cut, your server host their cut, and have anything left over for yourself without charging your customers their arms and legs. This is why all those kinds of apps are subscription based. You can cleverly batch and bundle stuff in a monthly subscription fee which gives you room to dance around google and apples high fees and have enough money to keep your lights on.

You asked

How should tags be integrated into Lemmy?

Which is a generic question that goes beyond the scope of one change, so I assume you also wanted to shore up probable future changes, all of which built on top of the first change. Forseeing problems in advance can prevent problems from propagating down the chain like this, so my contribution here is to reiterate the mistakes Ive seen other failed social networks make. That is, if spam bots have a way to output sludge faster than genuine content can be created, people will leave. I dont know lemmys specifics and its not my job to learn that, and this is not a code review. I do expect defederation to add some unknown complexity, so literally all i am asking is to just have a strategy for the final implementation and not handwave stuff as someone elses problem or take moderators for granted like reddit did.

I'm less concerned about the client side ui layout, so much as for enabling spamvertisements. So for example if a feature is added to be able to search by tag someday, then theres a potential for people to try and abuse that by labeling irrevelant things under tags in order to get attention.

I've experimented with other platforms before, and whenever a search feature gets added in any system that supports multiple tags, you start seeing posts with literally two dozen or more trending tags, and its irrevelant spam. I think the big proprietary platforms like tumblr have tools to moderate these, but I am aware that a community-led version of fighting spam has different needs and tools

Theres likely a way to incorporate downvotes into the server search algo, so it isnt surfacing junk for example. All of that is just one idea of a complete plan for helping the community to moderate spam. I'm not proposing any complete strategy here.

All I'm trying to get across: don't forget to anticipate spam, and give the platform and users tools to defeat it.

A lot of the time its impatient management who want the fastest solution right now, demanding their jenga tower built from hollowing out the middle and never allowing time to fill in the gaps with any new blocks.

But i've also seen just plain inexperience from devs who have never seen a project become technically bankrupt. Some people just carry the expectations for a short lived app into a constantly iterated long lived app, not realizing that is the way to crunch and missed deadlines.

Compounding the inexperience issue is the use of bad architecture. Architecture is a bigger picture thing, not something to bang together a bunch of use cases and a bunch of factories. The purpose of architecture is to keep development easy and smooth for now and the future. If it doesnt feel nice to work in, it's not doing its job. If devs keep trying to cheat it, its time to add convienience tools to encourage them to do it right.

Clean Architecture for example is very nice, it really shines in projects intended to be iterated continuously on for over 5 years and many more. It mitigates the pain of replacing and upgrading old obsolete stuff. Using it for one marketing campaign app that's going to live for only 3 months is overkill though. For very short projects, you can see how its the wrong tool for the job.

Selecting the right architecture involves understanding the patterns used and knowing what problems those patterns were meant to solve. Thats the way to know if those problems are relevant to your project.