2:47 - Intro(Howo)
3:34 - (Blocktrades) - changes and future planning
8:53 - RC plugin
10:40 - Usage of memory
15:33 - incoming RC delegation api feature
17:08 - json operation limit per block
21:46 - Testnet + Bug bounty
22:54 - Hive stem hackathon
26:01 - test voice on another platform like jitsi and stop paying zoom fees
26:53 - move the meeting ahead by few hours
29:18 - Soft cap hf25 or hf26
31:00 - Max curation rewards on top of author rewards
33:15 : Review Issues on gitlab

If you're listening to the whole thing, please post timestamps as a comment, the first one to do so (and correctly) will get a 100% upvote from me :)

meeting tl;dr:

Dev sync

As usual it's better to listen to this part

RC delegations

@blocktrades and team are concerned about some design decisions (operations in a non consensus plugin), after some offline discussions we realized that it was fine, we were just not aligned on semantics.

Then there are some memory concerns (a lot of new data is stored). I will be running some tests this week to build a million delegations and see the memory impact it would have on nodes, it shouldn't cost more than a extra gig of ram. So I'll be building a test to monitor this.

Also while we were discussing offline, we realized that rc delegates were non consensus meaning that it could be rolled out without a hard fork, and ultimately decided to push them to hf25.1, the reasoning being that there is no reason to risk the health of the chain making a big release when we can release hf25 and then a bit later release hf25.1 with rc delegations. I know it will come as a disapointment to some, but one of the core principles of the dev team is risk averse and if we can avoid a risk / spread it over multiple smaller releases, we will do it.

Incoming rc delegations index

Us implementing the index or not will depend on the result from the memory cost of the rc plugin, but it may have to be done via L2

Increase custom json operation limit per block

Would be a problem as we go into the middle of 2021 with a lot of applications relying on it, it's actually not a problem, as the limit is "per account per block" and not "per block".

Testnet setup + date (?) + bug bounty ?

Testnet will be setup by voluntary witnesses (most likely myself), date is still kinda undetermined, but could be as early as the end of the week, the "human" cost of organizing a bug bounty was deemed to big compared to the benefits it brings.

HiveStem hackathon on core dev things ?

We figured that it would be interesting to let people hack on hivemind, so I will be creating a guide on how to setup a dev hivemind environment so participants can participate on it if they want (things like communities, sorting algorithms etc)

Test another platform like jitsi and stop paying zoom fees

We'll need to see with @roelandp who currently pays for the account and @crimsonclad who manages the stream but we are inclined to use any platform really.

Move the meeting ahead by a few hours

There is a bit of wiggle room (1/2 hours early, an hour after), we'll run a poll with current regular participants to see what would fit them best.

soft cap in hf25 or hf26

https://gitlab.syncad.com/hive/hive/-/issues/140 we will roll out a fix on hf25, it's a very small change but an important one for hive -> hbd conversions.

from @guiltyparties:

Review of open issues on gitlab (who, when, ...). Some are 1 year old.

The possibility for authors/dapps to set a) max accepted rewards to author AND b) max accepted rewards to curator ---- both values required or set to default. Usecase: dapp wants to limit rewards for posts through it to 1$ for authors but to $10 for curators.

I think it would be possible to get close to that output via beneficiaries and max payout, I can't remember if curation rewards are before or after beneficiaries (before would make more sense) so let's say you want 1$ to the author and 10$ to curators, you can set the max reward to 20$, and a 90% beneficiary to @null, that way when it's computed you get:

50% of the reward goes to curators = 10$, out of the remaining 10$ for the author 9$ goes to @null, and 1$ goes to the author.

Something to play around with, but I think this can be done purely using the existing chain functionalities.

from @arcange: