Hello ! I haven't done one of those in a while, usually I link to development happening in the core dev meetings. But because a lot of things happened over the christmas break I figured I'd take time to write a post to explain some of them. And also I figured it was important to bring transparency and light on things that sometimes just don't work or time is spent on things that aren't features.
These days I'm 100% on hivemind, so all those will concern hivemind
The bad: performance issues and reverts
Performance issue with the new communities type
The @blocktrades team identified a performance issue with one of my changes @howo/communities-is-getting-an-update--what-to-expect
These are kind of tricky to detect because you need to do a full sync, which is very time consuming. So there is no automated tests to cover those. In the end I figured out that the issue came from an SQL query. The problem was quickly found and fixed in this merge request: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/619
Reverted the setRole / setTitle feature
About four months ago I built a feature to prevent community owners from setting an user as moderator or giving it a special title, this is because we saw people were given those roles even thought they didn't want it or weren't aware as a way to make a community seem more legit than it actually is (eg: setting @acidyo as moderator of a community titled "zing's fans" even though he isn't associated with it). We had to revert it, thanks to some testing from @mahdiyari. We found out that this broke historical changes for communities.
After some back and forth we thought about some solutions but all of them were technically too heavy for the feature and we didn't want to push those so close to the deadline, so we decided to remove it until we can think of a good solution (Basically introduce versioning within hivemind so that some changes only trigger after a specific date, similar to hard forks)
This happened in https://gitlab.syncad.com/hive/hivemind/-/merge_requests/631
The good
Fixed an issue where beneficiaries rewards were not counted in the apis
The problem is explained here: https://gitlab.syncad.com/hive/hivemind/-/issues/204 basically if you look at a post after the payout and that post had beneficiaries all the benficiary rewards will not be included in the "total rewards" portion of a post, eg this post shocases a 14.48 hbd reward @badge-696969/hotshots--52223 but in reality the reward is 29.014 because all the author reward went to beneficiaries.
So I pushed a fix which should go live soon: https://gitlab.syncad.com/hive/hivemind/-/issues/204
Made good progress on community beneficiaries
Community beneficiaries is a feature that allow a community owner to set a minimum beneficiary setting, and if the minimum is not set, the post will be automatically muted. This allows communities to enforce a "common pot" to build things or just make the owner some money if the community is enticing enough. This is basically another tool towards paid communities to make them into businesses.
The work is happening in there: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/621
But while working on it I realized there was big performance hurdles, so I had to work on another feature to clear those out. Namely:
Muted reasons feature
Right now a post can be muted (bridge_api_object has grey to true) for those reasons:
- user has less than 1 rep
- The post is muted (by a community mod)
- User role is muted (in a community)
- User posted in a type 2 or 3 community when they didn't have the right to (non-member posting in an member only community for instance)
- The post is a comment and it's parent is muted
This can get confusing for users "why am I muted here ?" and some front ends may decide to honor "grey" in different ways or have it up to the user (eg: I want to see posts from minus 1 rep).
So I built a feature so that the api endpoint returns the reason why a certain post is muted (eg: a mod muted this post). This will allow greater muted flexibility and improve UX.
Work is almost done and happening here: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/626
Mock helper script
This one is waaay less relevant to you unless you're specifically a hivemind dev, but I built some helper tooling to easily push mocked blocks onto hivemind to test various features without having to resync. Overall this saves bit of time but that's something you end up doing all the time when developing so that's quite usedful.
Work is done and can be seen here: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/620
Conclusion
And that's it ! I'm going to continue working on hivemind for the foreseeable future as there's a lot of work to be done (most of them being quick wins).
