Hey ! Sorry for the lack of updates on the core dev meeting, I've been travelling abroad for a few months and I forgot the file recording for the meeting #59 on my computer at home which means I couldn't upload it in time 😅. Meanwhile we went ahead and recorded the following meeting. So Here's a post with two in one ! I've only transcribed #60 as #59 is already kind of out of date.

@howo

And we are live. All right, so it's been forever, because we didn't do the June one. On my end, I have been struggling to update the last, the merge request for the muted reason, because all of the SQL has changed, and you know the whole process block, process post SQL, which is like 100 line PGS SQL thing. It has changed and developed, so which means that all of my changes need to be redone to accommodate that, so I've been working on this. Hopefully that will come soon enough, although I don't know what the current release schedule is like for, for our mind. I'm not sure there is any planned for a while.

@blocktrades

July, I think is the next planned release date. Yeah, okay, so we should be all right.

@howo

So that's been planned. Meanwhile, I've been also working on the next feature using the current not developed like, so the current muted reason feature works right now. I just need to, I mean, it works, but not against develop but meanwhile I've been working on the beneficiaries feature as well on HiveMind and I'll probably backtrack those changes against the changes that I do with the muted reason. And yeah, that's about it.

@blocktrades

Okay, I'll take it next, I guess. Well, as far as HiveD work goes, we're just about finished up the work on the lightweight blockchain nodes that don't require much storage space. There's a merge request open now. Apparently once that gets reviewed and merged in, I think that's pretty much all the changes we had planned for the lightweight nodes. So we're planning a new release of HiveD near the end of this month. So that'll probably be a good time for people to start testing out the lightweight nodes outside of, you know, internal testing here. There's also, as part of that update, we'll be changing the next hard fork trigger date. Right now we're planning to set it for near the end of September. The hard fork itself is mostly small changes because these high protocols pretty stable nowadays. So most of the changes we're doing are really aren't at the level of protocol changes. As you guys know, most of the new functionality is being added via the Hive applications. We're hoping to release a new updated version of Hive and the various Hive apps like Hivevine, Block Explorer etc. Sometime in July, a lot of these changes that we're making are performance improvements of various sorts, making some of the API calls faster, reducing storage requirements, that type of thing. We're also adding open API documentation to all the APIs. This is, I think, really important. Basically the way what we've got to allow you to do now is if you document your API using open API, we've got a chain setup, a process chain setup now that'll automatically generate SwaggerDocs. For those who don't know what SwaggerDocs are, that means it's like an interactive, you get interactive web pages that you could actually go to those web pages and test out your API calls in real time. It's really great for learning how API calls work because if you have an idea of what did you do, you could just try it and see if it works or not. So I think that'll be a great addition to our docs. We've also been continuing to work on some things, some new things related to HIVE. In this case, we're talking about light accounts. Light accounts is a concept that allows people to tie a name to a bunch of keys that aren't understood by the first layer, but can be useful by second layer applications. I've talked about that more elsewhere, so I probably won't go into that too much here unless somebody has questions about it, which I'm happy to answer. We're also as part of that work defining what we call second layer transactions. And second layer transactions are kind of just what they sound like. Whereas the first layer transaction is the way of processing a bunch of first layer operations as a whole, so that either all happen or don't. We're supporting a similar concept for second layer applications. And so we're defining a spec for how to describe a second layer transaction. And that work is being done not completely, but certainly partly in order for the second layer smart contract design we're doing. And again, that's still in early stages, but I think we're making good progress on all these front slide accounts, second layer transactions and second layer smart contracts. But nonetheless, I don't yet have a timeline for when we're gonna release that. I would like to say near the end of the year, but that's probably pretty aggressive, we'll just have to see. What else? I think we've got another two weeks working on documentation before we're ready to release Wax. Wax is our new multi-language API library. I originally was told or expected that we could probably get it released this week, but I've been reviewing everything and I think we've probably got at least another two weeks to get all the documentation ready. And maybe that's even a little hopeful, but I'm thinking we could really buckle down and try to get the documentation out as fast as possible. So we'll see. And finally, on the front end front, we've been working on denser, which is an open source replacement for condenser built on newer web technologies. We've completed the blogging side of denser at this point and now we've begun working on the, the quote, wallet side of it. So this is basically just the way dense condenser split up into two parts. We've been dividing up the work between those two categories of blogging and wallet functionality. Again, we don't know for sure, but we're hoping to have a demo ready for Hive Fest that just sort of shows what denser looks like. Not necessarily a production ready, but at least a pretty good idea of what it can do. Other than that, there's also more work going on in the Block Explorer. The UI, which is going to take advantage of changes, we've been making to the Block Explorer API and just also very fixing various things that have been reported over time by people. So that's about it for our work in a nutshell. There's a lot of other stuff going on on, I guess, the lower level, but it's too much to talk about really. So I'll just pass it off to whoever wants to talk next. Or if anyone has any questions.

@mcfarhat

Maybe I'll give a quick update from our end. Anyone has questions? All right, thanks. So not to focus on active side of things. I mean, we just push an update for our iOS version, but I'm more interested in updating you guys on recently. We assigned a couple of my team members to help out with some of the Block Explorer work. So I'm interested in chatting about this a bit with you, Dan. We started pushing a few minor changes or fixes. We have a small queue of things that we think would be helpful for the Block Explorer. I did set a few tasks for the team. I think will be useful. How do you want us to go about this? Should we create tasks on GitLab?

@blocktrades

No, no, just create new issues directly on GitLab. That way we know, best, when you first see a change, you want just throw an issue. And then you can also indicate if it's something you want your team to do, or if it's just if you're not really sure, just sort of throw out an issue. Basically just give me an impression of how important, what the issue is, who you think should work on it, and that kind of thing.

@mcfarhat

Yeah, yeah, yeah, all right, yeah. I think this makes things easier because last week I asked one of our team to add the timestamp display on the user transactions. And then once he finished the work, I saw that someone else from your team did that.

@blocktrades

Exactly. So I said, okay, put this on the set. That's why the issues is a really good way to do this.

@mcfarhat

Yeah, yeah, yeah, yeah. Precisely. So I told him, okay, don't waste your work. Let's, one improvement we can do is actually to do a mouse over and then you can display the actual time of the transaction because that's missing there. So it's not all lost, but yeah, I think it's great if we can have a solidified list of things that we can probably improve or we can work on fixing. One thing I noticed recently, an error that's occurring with no data from API endpoint regarding get account authority. I saw an issue on your tracker, but it doesn't mention any details. It's about upgrading the block explorer to align with the new endpoint, but there were no details at all.

@blocktrades

So that's all work, it's in progress. So, I mean, the work has been done on, I think in the backend and probably the front end that hasn't been updated to take advantage of the new data. And if there's an issue out for it and it's, I've got it marked as a high priority issue and I've just bugged the guy who's responsible for making those changes.

@mcfarhat

I saw it, I saw it. I knew there was something there. So, it had a priority.

@blocktrades

I have personally directed it the priority higher. I messaged him directly just a little bit before this meeting. So I'm hoping that in a day or two, that'll be done, but we'll see.

@mcfarhat

Okay, excellent. Do you think we need to update our half block explorer code, so that this gets fixed. Because it's saying no data from API endpoint and I think it's related to it.

@blocktrades

Yeah, yeah, we need, the UI needs to be updated. Well, if you're running, so you're running the latest UI, and it depends on which configuration. If you're running the latest UI and not the latest block explorer, then it should be okay. But I honestly don't know. I'll tell you what, I think once we get the change, probably what you're gonna do is, you're gonna wanna update. So you're telling me your production block explorer, right? You're not talking about your…

@mcfarhat

Yes, yes, production, yeah.

@blocktrades

Let's take it offline. I'll check off after the meeting. I can look at what you can show me the issue and I can tell you what's going on.

@mcfarhat

Okay, sure, sure.

@blocktrades

Find somebody to have you talk to, have talk to you about it.

@mcfarhat

Okay, excellent, excellent.

@Bartek

As far as I know, latest front-end code for block explorer requires newer version from the backend, which supports authority data collected for accounts. So to make it working, probably you need to have newer version of backend, which, as I hope, was already deployed to our explore open-hype network and HiveD open-hype network endpoints. And then latest version…

@blocktrades

Maybe it just point to that one for now.

@Bartek

So that's good test step to be sure that everything works fine and probably explore open-hype network already is pointed to such both versions. So front-end and backend should match there and they should work.

@mcfarhat

Yeah, I just shared the error message on chat.

@blocktrades

Yeah, I guess this brings up one issue, though. So if you're updating your front-end with develop and your backend, I mean, you're not running your... I mean, we're talking about production, right? I think you're probably going to separate your production and your backend, if possible, because right now the development front-end is always just assuming the development backend. But you don't wanna keep updating your production backend to update to the latest develop because it takes too long to update. You know, it takes days.

@mcfarhat

Yeah, you're right. I just saw a lot of nice improvements and I thought, hey, I need to bring those to the live environment. But we do run a development environment as well on a separate IP. I think what you're saying makes sense.

@blocktrades

Okay, okay. I just wanna be sure that was clear. So yeah, okay, so that's… Yeah, going forward, I would just wait on the production one before updating until both the back-end and UI are released and then that way you won't run into that kind of issue. But temporarily as a workaround, you can point your development front-end to Gandalf's API.

@mcfarhat

Yeah, okay, okay. Fair enough, fair enough.

@Bartek

From important changes done in half block explorer, which maybe wasn't yet merged completely, are changes specific to integration of reputation tracker. And this is one more application which collects reputation data specific to account. And it will require a little changes in setup, but appropriate merge request and work has been already done in half API node repository. But you always need to be sure that you are using latest version of that because otherwise some components will be missing and your application just failed. Since we had to add some parts of deployment code directly to half API node repo. So further updates of half block explorer will lead also to update half API node code.

@blocktrades

Right, and so that's officially not planned for probably sometime in July.

@mcfarhat

Yeah, I'll wait, I'll wait, no rush. Dan, should I just assign you, I don't wanna bother you with too many notifications on the GitLab, but I'll just put the issues.

@blocktrades

Well, don't assign me just, if you just put the issues on there, I will find out about them. I read basically everything that happens every day on GitLab, so if you make an issue, I'll see it. And then what I'd really like is if you would put, if you plan on somebody doing it, put who's you plan on having do it. So I assume they have a GitLab handle, if not maybe they can create one. And then if they get tagged, I'll know that you're planning on, I'll know it's something you plan on doing rather just something you would like to see.

@mcfarhat

Yeah, yeah, for now I'll assign them to myself because from my team, I mean, whoever is available, I'll probably just put it on a task.

@blocktrades

Got it, that's fine, okay. Okay, that also works. And so if I have any feedback, I'll just put it on the issue and it'll get to, you can get it to us.

@mcfarhat

Absolutely, yes, yes, thank you. Yeah, that's really it from my end.

@blocktrades

Okay, sounds good. Yeah, I mean, I guess, I don't know if our tech knows anything that's open. I mean, the decentralized badge thing sounds like a reasonable, I mean, it sounds like a good task for you because it's something you know about whereas, you know, our guys don't really.

@gtg

Actually, the idea was to implement it in the WAX, so then it could be just used, I mean, the high level.

@blocktrades

Well, how is it gonna be? I mean, he's talking about having a database associated with it.

@Bartek

As far as I remember, the idea was to reuse internally storage specific to follows. And just hide under WAX interface specific of such details. But to complete this task, some additional extension of queries specific to follows must be added just to make sure that queries from client side will be effective and we don't blow it by thousands of records, that were made from it. And probably this is not big deal to implement. So if Hoho has time, have time, he can try to go this way. But I don't think so. We need to add another table just for badges. Probably this way specific to specific follows should be sufficient, but we need to figure out some smart API call which effectively can return badges specific to give an account and that's all.

@blocktrades

Okay, let's maybe have a meeting discuss this board some point offline, because I don't really have enough background right now. I mean, I understand everything everyone said, but it doesn't tell me what the solution is or it sounds like we don't have one yet exactly. So I think we need to have a separate meeting to discuss this, maybe even maybe just form an issue. If we have an issue on it, we can write our ideas on the issue and then comment there as beginning point.

@howo

Yeah, there is an issue. I mean, as I said, it's really not something urgent. It's more like it wouldn't.

@blocktrades

Yeah, well, I mean, it's, I think it's a good, I think it's a pretty solid thing. And I mean, it's going to come up for us too with Denser, I guess, so. And it sounds like they want to incorporate lack functionality for it too. So lots of reasons, I think we should, yeah, it's not a huge issue, but it's certainly worth addressing. So yeah, maybe write down your thoughts on it and we'll hopefully Bartek will write some more about what he's thinking about the follow stuff or whoever's idea that was. And then I want to review it too and just throw in my input.

@Bartek

Actually, I have a question to Howo, which appeared today during my discussion with one of Denser developers. And this guy is trying to start new implementation of wallet in Denser. And one of its task is adding creation of community. And actually, documentation created for other operations specific to communities is quite well. And we use it already to build community operation builder in WAX. There is very small amount of information specific to community creation. And I know that actually most of the work is to create account which has some specific name, but my doubts are specific to what next? Do we need some other properties to be set immediately or some other custom JSON actions to be executed? If you Howo has some information specific to that, it would be very helpful if you could supplement communities markdown document in high minds to have it written there.

@howo

Yeah, totally, I can do that. Well, in practice, you don't really need to do anything. It's just that the community will not have any name or anything, so it's gonna be very blank. But if you're asking, does everything need to happen synchronously, in the same block, create the account and then send the JSONs, you don't really need to do that. But if you're telling me that the documentation is lacking on let's say the basic setups JSON, I will add that then.