Hi, yesterway was bi-weekly meeting #5, so I figured I would link it along with #4 and provide a tl;dr for both of them.
dev meeting 4:
agenda and tl;dr:
- Dev sync
it's better if you listen to this one, there is a lot of stuff
- Allow users to change the proposal title https://gitlab.syncad.com/hive/hive/-/issues/45
- Consider increasing proposal creation cost by 1HBD for each day it "lasts" over 10 days
https://gitlab.syncad.com/hive/hive/-/issues/44
Basically it's on that meeting that we decided that it would be a good idea to have the update_proposal operation along with a new fee structure.
- Referral system at the chain level https://gitlab.syncad.com/hive/hive/-/issues/43
Regarding the referral system, we thought it could be a cool idea to implement at the chain level similar to bitshares, but need more discussion on how exactly we should do it, add a buyback etc.
- Allow linking more than one permlink per proposal https://gitlab.syncad.com/hive/hive/-/issues/41
We didn't think it was that necessary, it adds a burden to the chain when we could just have the main post have a list of posts at the top
- Hard fork 24 and convert steemit stake to hdf
We figured it would be a good idea
- Node status page on hive.io ?
Technically status page is already implemented on a few services already, we should try to get a list of them on hive.io
- No longer remove expired proposals and instead allow filtering at the api level https://gitlab.syncad.com/hive/hive/-/issues/48
Better solved via hivemind instead of hive.
dev meeting 5:
agenda and tl;dr:
- Dev sync
same, listen in. But basically, I've been working on update_proposal and the new fee structure and blocktrade's team has been working on optimizing the chain and prepping the testnet.
- Consider increasing proposal creation cost by 1HBD for each day it "lasts" over 60 days feedback discussion https://peakd.com/hive-139531/@howo/some-extra-changes-are-being-bundled-into-hf24-regarding-the-proposal-system-we-want-your-opinion-on-it
We discussed a bit other solutions proposed in this post, and in the end thought that it was best to ship as is and update in a later fork if necessary.
- Discuss how to do "controversial" changes, and how to poll the community
Basically, we post on chain ideas, mostly in the Hive Improvement Community or post it on gitlab to discuss more technical things. And if the change is controversial, we'll make two proposals to poll the community.
- Proposal object permlink issue fix https://gitlab.syncad.com/hive/hive/-/issues/53
In the end, we figured that edge case was fine to be as it is, because it's super rare that it'll happen, and worst case it's more of a front end thing rather than a blockchain issue.
- Should we add support for "custom keys"? https://gitlab.syncad.com/hive/hive/-/issues/49
This one was interesting, we were mostly throwing ideas around, I think having custom keys is a bit too much of a burden on apps and on chain to manage. And I think that idea should be done via changing the give authority operation where you don't have to use your active key for it, if you want to give voting authority you should be able to do it with a posting key, but if you want to give witness voting authority, then you should be using an active key.
- downvote mana delegation
Same, mostly a discussion, I suggest you just listen in as there wasn't really a conclusion.
- increase max vote changes https://gitlab.syncad.com/hive/hive/-/issues/40
Why not, but we need to find out why this limit was put there in the first place before acting.
- @imwatsi was asking "I'm interested to know how I can get involved with hivemind, jussi or hive-python. Are there any priority issues I can tackle?"
The issue was that for this fork a lot of stuff changed, so any work would probably cause code conflicts (all the names have changed from steem to hive for instance), so we were kind of preventing outside help for a bit. After hf24 we will be much more open and have a lots of tasks that can be tackled by volunteers.
Also we had some discussion on leaving some easy tasks open (not work on them) tag them as "good for new contributors" so that new people can learn how to work on core subject with easy tasks.
FYI, those are streamed on the hiveio youtube account, and the next one is on the 22th of june at 5pm CET. Tune in to ask questions :)
Finally, please consider voting on my core development proposal here https://hivedao.com/proposals/97 and for the witness I co-manage @steempress
Regarding the matter of downvoting, would it be sufficient to just create a way for people to downvote anonymously (in addition to downvoting with their username)? So they can choose whether they want to downvote the usual way or anonymously. Seems better to me than creating the ability to delegate downvote mana which has those issues that were mentioned on the #5 meeting.
Anonymity is hard on blockchains where by nature, everything is public. There is currently no anonymity mechanism on hive (and I don't think there will be). So we can't do it that way.
anon downvotes are indeed better, but it's not technically possible right now.
Brainstorming on this further, it became more clear to me that even if anonymous downvoting were made possible, there would be undesirable sides to it. When it is clear who is doing the voting, then the community can regulate the downvoters. Every behavior on the blockchain has to be able to be regulated in order for the whole network to work. If that does not happen, we can foresee things like downvoting for reasons other than disagreement on payout - maybe for disliking the content or having personal vendettas or whatever. Anonymity would prevent mediation and/or regulation from happening.
So maybe a different approach would work better. I was thinking of something and it's still in rudimentary form but I thought I'd share. In essence, people could post a comment on a post and the comment would contain a keyword, for example:
#shitpost. Putting this keyword on a post means that the person sees the post as having no substance, contributing no value whatsoever and being made solely to get the rewards. Frontends and tools can then display a feed of posts that have this keyword in a comment under them. People will follow those feeds and will be able to view each post and decide whether to downvote it.Two main scenarios come to mind of how this could play out:
#shitpost. This way they can be rewarded by others (with upvotes) for discovering reward pool abuse. They can also be punished by others (with downvotes) if they abuse the keyword and use it inappropriately or too much. Possible negative ramifications for the person posting the comment is that the post author may be unhappy, the relationship may be tarnished, and even downvote retaliation may be sought. However, in the last scenario, there will still be the possibility of self-regulation of the community, where if a person gets downvoted for no good reason, others may rectify that through upvotes.#shitpost. In this case, I guess if there is abuse of the keyword usage, it is not completely clear if the anonymous service should be downvoted. An upside is that the person doesn't risk their relationship with the post author being tarnished.The issue of relationships being tarnished may also be tackled with education - if people understand that efforts to improve the platform as a whole will lead to their own stake being much more worth than currently, then many of them might stop shitposting. But I don't count on education alone being enough without a self-regulation system like the above.
I'm sure others can improve on the idea. But wanted to see if you have any thoughts on it.
Sorry for the delay,
I don't really thing anonymous downvotes are this bad, proof of brain in theory doesn't require you to know who is voting/downvoting you, it's like likes/dislikes on social media.
I believe what you suggested with tags has already been though of and even tried but I don't remember when. I think it was abandoned because people people would bot the service to get downvotes to people they didn't like even if the post was good.
I think curangel has something like this where people vote on posts to be downvoted.
But it's an interesting one, having a layer 2 service where people can vote on whether a post should be downvoted or not anonymously and then a bot on which people would delegate voting power to it would downvote depending on the results of such votes.
But downvoting is always tricky and causes a lot of frustration from users and downvoters, I honestly think that while proof of brain is great on paper, it fails in real life and we should try to find another model for reward distribution altogether.
Do you have any thoughts or ideas for what that model might look like?
Not yet but it's thoughts I've been having, I need to take some time to think this through.
Cool, keen to hear when you've had some chance to think more about it.
One thing I myself am quite interested in is allowing communities to experiment with different economic models. I'm not talking about SMTs, although of course they will come later and allow even more experimentation. But what if a community owner account can be set as the mandatory beneficiary of 100% of the rewards generated in that community? Maybe those who are solely interested in the rewards will not participate, or maybe they will, depending on what the community decides to do with the rewards (e.g. a local group can have monthly parties paid for by the community's rewards, etc.). How will people's behavior in that community be different if they don't personally seek to maximize their rewards or even participate for the rewards? Hive without the rewards seems like an interesting experiment which I think can easily be tried with some additions to Hivemind.
Thank you for the break down update, as a layman and just ordinary user, I still like to sort of know what is going on, and what is forthcoming. It was good to read about the opening up of the development process, I think as a core group you chose the right method by adding smaller task for the new 'would like to be on the team' developers.
It indeed is informative. Keep doing great job.
nice awesome
Great work!
So many things happenning here (Hive). The team is really strong.
Just listened to the meeting. Great to hear the progress being made. I'm looking forward to contributing after the Hardfork :)
Where is the meeting from the 22nd of June? Not on youtube. Also, why is everyone silent regarding the hardfork? The updates completely stopped.