meeting tl;dr:
Dev sync
As usual listen to this one is better
hived proposal payout maintenance time drifting fix in hf25 or not hive!168
Lots of discussion on this one that branched into two problems, one is the proposal time drift issue, the other is about the unit tests behaving strangely due to the skipping logic.
The output of that point is that I will try to fix it for hf25 and see how the unit tests go, but if I see that it takes too much time, I'll skip it and we'll fix it for hf26. It's a minor issue.
Incoming recurrent transfer api: hived or hivemind ? Broader discussion on should hivemind support recurrent transfers
Incoming recurrent transfers will be done via hivemind, and yes hivemind will support them, we will do it after hf25 has shipped though.
Update the beem used for unit tests in hived to one that is more up to date:
Relatively short discussion, and since @holger80 implemented the hybrid transactions in the mainline github, we'll move towards using the version on github instead of gitlab.
Hived split block log in chunks and be able to sync those independently
There was lots of discussions on this in the dev channels. It's not the focus right now as hf25 is upon us, there was some discussions on using external tools instead of implementing it directly within hived. To be rediscussed.
Hivemind Communities type 2/3 and account level mutes hivemind#125 / hivemind#145
Bt's team is building tests, we'll then then who takes this on, potentially bt's team as I'll be tied to hived
Hivemind communities beneficiaries support hivemind#149 +parameter naming: reward_share vs beneficiaries
We also discussed changing the data type of the communities data from text to jsonb (https://gitlab.syncad.com/hive/hivemind/-/issues/153)
Basically we'll use beneficiaries and the current implementations ideas are a bit early, we(I) are waiting for the changes to take place in communities type 2/3 + account level mutes to take place before taking this on.
Hivemind Communities metadata (topics/tags) hivemind#148
Yes why not, we'll add a new field to store a few "communities tags" and a new api to search for communities via said tags. The idea is to be able to tag a community like "crypto nft games" or "sport tennis" etc to make content discovery easier
Adding more stats for communities
A bit early to tell what we'll add but I'll definitely look into adding more stats and ways to sort communities with it.
Conclusion
In the end lots of hivemind talks but those are mostly preliminary, our focus is hf25 we are tentatively(this is not an official date or anything, it's more like an "ideally we would like it to be done by but might slip if needs be") looking at april 15 for locking the core code and build a testnet for hf25. This is when all the features for hf25 are set in stone and we stop adding new features to the core code. So all developments HAVE to be done by then.
This is why I'll be mostly focusing on hive core for the next month to get all of my ongoing code merged and included in hf25.
See you around for the next dev meeting on march 29th :)
@howo
One thing to consider for some of the community features indicated in your post is if it will be a Json transaction that an admin can do or if it will need the account owner to put the info into the community account metadata with an active key. Or mix of both.
For example we will have a couple features coming up that we are doing this method with the account metadata even though letting the admin make changes sure would be nicer for user experience specially if it's something that needs to be edited often.
Also community stats that deal with comments or rewards are problematic because it is largely a reflection on the individuals following and their ability to bring in comments and rewards and it is uncertain what the community had to do with it. Not saying we have to get rid of those stats but given better options those ones should be related way down in the list.
So I am in favor of stats that show a user what the community is actually doing.
Those seem to be directly related stats to what the community experience. It also indicates to the new user what they can expect after they follow the community (what will happen to their follow feed)
I'm not sure what you mean, are you talking about the beneficiaries or the TEXT vs jsonb thing ?
on the stats I agree, we will open the discussion more broadly on what we want + what we can do when we get to implement them, I'm sure there are a ton of them that are easy to do and bring a lot of value.
When a community member with the role of admin wants to change something on the community they publish a Json and that makes a change to the community in those specific fields like description, community name, Rules and additions of moderators or muting.
I'm saying we could add a couple more things there OR just add it to the @hive-xxxx account metadata which can only be edited by the owner of the hive-xxxx account.
Ah I see, It will be done on with the json props operation (publishing json), it makes more sense to bundle everything under the same communities operation
Well it's obviously nice but of course it's work so i wasn't assuming.
I should probably mention that we will be adding two more aspects to community we have planned to add them to the hive-xxxx account metadata. Assuming if they get used a lot we thought maybe they'll switch specially if other interfaces start to use them.
Preferred-Topics ... these are names of topic-tags (on posts) that the community wants to see the most and that interfaces can help the users zoom in on and consume. It's basically a way of filtering the content in a community. But will also be presented to the content writer when writing a post as what is preferred for tagging. So the admins would basically just present an ordered list of #tags.
The other is a short list of the actively used community titles (labels) or whatever they're called. they could help sort community members and communities could use these titles in all sorts of ways including hierarchal achievements.
Eventually we believe those labels will be more useful when communities can add in a BOT that automatically approves any user who selects a community title from the communities approve list of titles and essentially it moves to users deciding their own titles which you see a lot on reddits like sports reddits with only some of the labels active.
But the question is how often would these be changed and is account meta-data sufficient. I'm guessing while not often they may be changed more than some of the other data that admins get to change there.
cc @asgarth
Hmmm I feel like all of these should be done at the hivemind level, It's basically a way to change the sorting/viewing algorithm, and approving posts make little sense when we could instead make the algorithm show the posts (or not) automatically.
If you haven't started working on it, if I were you I would be enclined just look at the hivemind code and implement them there, the code is pretty straightforward, but I do get that it would be much faster to just implement them at peakd's level.
How often these would change would be pretty rare I would assume.
As of yesterday can actually go to beta.peakd.com and see how we are looking at doing the proffered topic list on account metadata (community settings option)... it will be easy to transfer the info to hivemind.
But I'll cc @asgarth and see what he thinks
And as I played with this list yesterday with one of my communities I actually changed the list a bunch of times but maybe once I get it set then I would rarely change it.
One again thank you for the post. It is nice to see we may actually have a second HF that the primary focus is the user and continuation of solidifying the foundation. Very nice to here a tentative date, and also that the witness situation is pretty much done.
Also of import is the talk of keeping things streamlined and running well like the post/vote results and splitting them so as to save speed is what it sounded like to me which shows me that performance issues are still a top priority with the team, that is good, so often the small things get pushed aside and end up getting everyone stuck in the mud, you guys have done a great job of cleaning the code up it seems to me, so thanks.
I think most hfs will have the user as it's man focus from now on, hf24 was the only special one where we almost exclusively worked on "core" things because it was the moment where we were truly making hive ours instead of "steem 2"
It's mostly blocktrades that's to thank for this :D
Ooh... 🤩 Serious talk of beefing up community functionality? Woohoo!
Yes it's awesome news!
Thank you for joining the discussion, great man.
I think I heard something mentioned about potentially excluding RC delegation pools from HF25 if they are not ready on time. I think the community will overwhelmingly agree that we prefer the HF25 date to be set a month or two later so RC delegation pools can be included. It seems like one of the most important features to help us onboard new users. And the bull market is now, so we can expect tons of new users. If possible, please poll the community for views on postponing the hardfork date so this feature can be included.