Core developers meeting #16

in #hive9 months ago (edited)

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
@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

Sort:  

08:00 The modular concept sounds pretty good, even as a non-programmer I do understand that most programs are built on modules and not all programs need all the information that is available, so modules would make for lighter weight programs it seems.

11:00 Nice to hear that the big changes are pretty much done and opening up of individual wants and needs being opened up.

35:00 Recovery Account Person, information was somewhat nice to hear about, I may not have understood the full discussion, but it is nice to hear account protection is still one of the things always on the minds of the developers. A nice thing would be just a notification your requested recovery account person has been successfully changed

48:00 IBC, that sounds pretty complex, but it could be a very telling tool for many people in the investment fields. I also think once the coin change is able, it would not be much of a step from information sharing like how in the early stages AOL and CompuServe were separate, the internet explorers brought the two and many to one.

Just think you are surfing the net, you see a very compelling post or page and you click a vote button and can give them a tip in any coin you own.


Thanks all it was an interesting show, and nice to hear about the information above.

re:modularity: this is especially important as hivemind requires like 600gb of space currently

Thanks for always commenting :)

Actually hivemind's storage footprint is now down to 440GB.

Now that will increase a few hundred GBs if we move the account history data from hived to hivemind as we're planning (but it's not necessarily a net increase, since we can potentially stop storing that same data on disk for hived at that point).

Is a roadmap available for this year from the core dev team?

Is SMT still a thing or is this now a "nobody cares" from the dev team thing.

for @blocktrades : https://peakd.com/hive-139531/@blocktrades/roadmap-for-hive-related-work-by-blocktrades-in-the-next-6-months

On my end I don't have a long term roadmap (as I'm alone) I'm mostly acting as a support to do r&d and build small features, although I may be working on something big soon :)

Smts are still on the table

Thank you!

Any updates on the native SMT layer?

We are still investigating layer 1 vs layer 2 solutions. More news to come regarding this soon:tm:

Welcome for the Core developers meeting. You are solving problems on HIVE. Really we need a way to easily handle payments, recurrent transfers.

Thanks for sharing