https://www.youtube.com/watch?v=llOSnRfJK84 meeting points + tl;dr: ### Dev sync: better if you listen to this one, apologies for sound problems on my end. But basically I worked on recurrent transfers + adding a virtual operation for recovery account changes ### language tag in hivemind (who/when/how): who: probably @howo unless too busy with other core dev work (meaning feel free to take this) when: we need to sync more on how we do it and how soon front ends need it how: some debate between using a tag vs adding it as a hidden property of a post ### followup on documentation work: @inertia put up a [proposal](https://peakd.com/hive-139531/@inertia/proposal-hive-developer-documentation-2021) @gandalf is still discussing with someone internally from the @blocktrades team I decided to not add my guy in the end as I felt it would be too many resources on the same task ### remove failing recurrent transfers or not After some debate back and forth we agreed that failing recurrent transfers should be removed. ### use required actions for recurrent transfers ? @howo will do some r&d work to see if that piece of code from the smt code is usable for other purposes. And try to integrate recurrent transfers to it. If not he might just build another system. As we need a way to easily handle automated actions (proposal expiration, payments, recurrent transfers etc) ### Add a "time until next recovery account change" to account_object Lots of discussion there, conclusion is that yes we can add that to hivemind, no one tagged on who will do it yet. ### proposal end date update (from @guiltyparties) Change the update proposal endpoint to allow updating the end date as well (to make it sooner, we won't allow increasing the proposal time), we decided yes @howo will do it ### Cutoff amount for a proposal (from @guiltyparties) The idea is to ask for a certain amount and have the proposal deleted once it has reached that threshold. We feel like it's low hanging fruit that can easily let more people use the proposal system without fearing not getting funded, and let the proposal system work in a more trustless way. An example is if a proposal asks for 2000 hbd to handle cases where the proposal is not funded in time, but only needs 1000 hbd, we would no longer need to trust that they actually delete the proposal after receiving the 1000 hbd. We decided yes @howo will do it. ### IBC - inter-blockchain communication protocol, How complicated it is to add support for IBC or what things to consider to allow communication with other protocols? (from @good-karma) @blocktrades went on a very interesting monologue there, you should listen in. That's it. This is a very rough summary please, listen in for the full picture :) next meeting is on 2021/02/01 18 UTC. @howo

See: Core developers meeting #16 by @howo