Nothing about OP’s question indicated they were interested to know if there was a regular release schedule. Specifically they asked for the next release, therefore I tried to explain why there may not be a simple answer to their question.

Software development takes time and has many unanticipated challenges that makes time estimation difficult. When developers do provide estimates users, managers etc then get stroppy when they slip by.

Therefore the best strategy is just to ignore requests for time schedules because it’s a no win situation.

This guy seems to be presenting himself as such a monumental prick that it feels like theatre. Has it been the plan all along that he becomes the scapegoat for this policy?

He steps back, another puppet takes his place. And puppet 2.0 appeases the community by making some gesture of good will.

Perhaps halving the proposed API costs. Or taking the sensible route and making third party access open for Premium subscribers?

But at the end of the day they still achieve what they want: demonstrating to investors they have control over their users and boosting their income.

I always thought that NSFW was too vague a term. One person’s NSFW is different to another’s.

What would work better is specific content tags. That would work well for trigger warnings too.

It would cover porn: nudity, softcore, hardcore

But also content themes: Alcoholism, drug taking, violence, suicide, war, guns

It could even be used for spoilers.

Users could then select the specific themes they didn’t want to see. For better UX you could have a slider that had pre selected levels. “strict”, “relaxed”, “everything”.

Posts often present content warnings behind spoiler tags at the start. The idea being that some users don’t want the story spoiled by hearing what themes it contains. That’s why I believe this system would work. Rather than having the content warnings visible it all happens in the background through structured data. Your app already knows if it’s content you don’t want to see so it either hides it, or perhaps blurs it with a warning that you likely don’t want to read it.

Karma might work on a per instance basis, but if implemented on a federation wide scale you’d have to trust every instance. It would be far too easy to artificially increase your karma with your own rogue instance just by editing the database.