Status Core Developer, 8 Feb 2021

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Core Dev Call #46

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).

A

Yeah sure so it's not much basically to it. So so what I found that uh flat list is definitely slow and it has some number of bugs and uh it's definitely not designed for such tasks. We have so to add to have many dynamically items which is added from both sides.

A

So it's more like starting, you can add, like some items in the end of the list, but if you are trying to so the major issue is, then you start scrolling really fast.

A

You need to add dynamically lots of items uh in both directions, and it's unfortunately, flat least is can't, uh show any performance here and then start like taking more and more memory, and it's trying to um to calculate, I would say all items and uh also- and you reach the end of the list before you add more items. So it's like you if you use or scroll really fast- and we can't add items so fast, so it never reached the end.

A

For example, if you uh try in all other messengers like telegram or whatsapp, if you scroll really fast, it adds new messages and you never reach the end of that. For example, if you in the middle of the of the huge list like for example, you have like thousands of messages and you are like in the middle- and you start scrolling fast in both direction back or to the new messages or old, you will never reach the no. I mean.

A

You can scroll as fast as you can, but you always will see the new messages or new items, but with flatless it's impossible. You reach the end really fast and it can't handle like so many messages. Also we don't have control on scroll or whatever.

A

So it's like just events and there is no event on reaching the beginning. Then we can load more messages in the beginning. So we have to use the on scroll events, but they are really late and then user scroll really fast. There is no enough information and not enough events, so we can react really fast on that so yeah. If we want to.

A

To implement this, so currently we refresh list each time you open chat and we load latest messages.

A

So you don't need to scroll, uh you can scroll down, I mean to the new messages, because you each time you open chat, we load the latest and newest message and we have on, we add dynamically, only old messages when you scroll back but currently in status, you can simply reproduce you start scrolling fast and you reach the label of the chat and it's big like big circle, and you can see it and if you scroll fast and want to navigate to the history, you will always see this blinking big circle and it's also the issue.

A

Probably we want to solve and that's we need more control on the list and we can try to. uh There are some implementation components in the on the github. We can try them. They are like more more flexible and then works in both directions. So we can try them and and also we can try to implement our all our own implementation.

A

But with the react native and third option we can go native and in in that case we could use, we could load messages directly from status, go to native and don't use the react native thread at all. So it will be just native list because currently, if at least we load the data messages from the status go convert to.

B

A

B

Send it to the native part, hello.

A

Yeah, so that's.

A

That's how it works so.

B

A

Yeah, we just need to decide how we can go next, and probably we could just try to investigate the react native and create a few example.

A

Examples how it might work outside the status, for example, just application with the scroll and see how it works in both directions. If we can just load messages fast, because.

C

A

Mean if we, if we load the all messages in the list, I don't think it will work pretty good because we need to navigate. For example, if we have thousands of messages and we and users scroll back to the few thousand items back, we need to next time he will open chat. We need to show exactly this place.

A

That means we need. We can do two things first load all messages in the list, which is not won't work, I believe really fast and second one. We can load, for example, 20 and start loading more than he scrolls down for to the new messages.

B

C

Okay, so, just to make sure I understand correctly like if you highlighted the three different possible options that we have and one is to use some components already existing component that scrolls both way that are available on github.

C

The second one is to basically like write our own react native component um and the third one is that to write a completely native uh component. So just to summarize, essentially like correct me from around the the drawbacks- and you know the pros and cons of of each one, reusing, uh obviously using a github component doesn't give us much. Flexibility probably might solve the issue uh and it's low.

A

Effort the second.

C

Is obviously like a way in between so we write our own issue, they have our own um list implementation of list. We can't reuse any of the component that the rendering of items probably.

A

Yes, right right.

C

A

C

It's kind of like a moderate, a moderate left foot and the third one is obviously a lot of effort, but it gives us the flexibility.

B

And the best performance we.

C

Could basically get essentially um so my question would be obviously if anyone has any comment, it would be interesting and as well like do we how how because, obviously using a component, I know that you know like in-house. You know we know how to how to do it and do we have the expertise essentially like do you understand the efforts required for option two and three roughly because the issue is risk essentially like in my in my view, because, like we, you know we, I don't know what we know about these.

C

Essentially we could spend months or weeks or you know like, and I have myself. I have no.

A

C

How long it would take so if anyone has any opinion on the matter.

A

uh I I believe, the third one we could ask the desktop team because they implemented the I I would say I I'm not sure how it works in this club by the way. So.

B

Well, it shouldn't be the same as an android, and I just I suppose, even if they implemented it, that's kiki, probably they're using qt. As far as I remember, that's a totally different thing, I'm not sure it's.

A

B

I assume they're using qt for everything, so it'll be totally different.

A

Yeah I mean if they use, for example, if they're a list implementation list component in qt or they use just uh scroll component and insert items by their cell. I don't know I mean in android and ios. You have a list, I mean scroll component, so you can use it right, but how it's implemented in qt.

C

So essentially, the question is just to just reframe it. A bit is essentially like.

C

Do people in desktop have implemented their own version of a list, but they used an out of the box component, because if they implemented their own version of the list, then there is definitely some knowledge that they probably acquire that they can be used.

B

In the case of testo, we are using a component from qt called the list view, and also to do the sorting yeah for the sorting of the messages. We also have another component from cutie as well called a model delegate or something like that where we can uh put a function to sort the messages but yeah, we are mostly using stuff from cote d directly. We are not developing components on our own.

D

Now I don't know much about mobile development, but I'd say the snappiness of the chat window is probably absolutely crucial and if it is not snappy as people expect it to be based on drafts, there's gonna annoy people all the time, which is every time they use a chat right. Probably so I would probably say that native solution would be the most sensible, even though it might be the highest effort right.

B

I can I completely agree with everything that uh jacob just said. I was going to say exactly the same thing. He said what I was going to say.

C

Yeah, I think we we are in a good position in terms of like we have a very good baseline, which is discord. It's called up is written in react native, so any you know the stack is slightly different from ours. You know we use closure script, so there might be some differences based on that, but we can achieve. We know that, theoretically, we can achieve the same snappiness as this chord. It's called um I mean some people might have a better idea.

A

C

What the performance are to be looks acceptable, uh so I think this is something that, and also we've been talking about this for a long time, so to stop learning about it. It would be good to start moving in direction.

C

It's just a matter of like understanding. What's the best path now I myself are trying to get in contact with the discord developers. If anyone has a contact with, you know that they haven't replied and they don't expect them to reply, um but just to get some suggestions about whether it's worth it. What they've done you know like in some sort, but if anyone.

A

C

Any anyone who has a similar experience- it will be good as well if we can get more information as possible before we commit to a.

C

Strategy: okay, so just to what do people think if we decide to first look.

B

C

The github components and then see how it works if there's anything out of the box that we can use and after that, we just regroup and decide whether we got whether to go for option two and option three.

B

That makes sense if we'll spend like few days with it, makes sense.

C

Andre, what do you think.

A

Yeah, I agree. It sounds good.

C

Okay and if anyone knows anyone who in the company has experience with that and we obviously have native but also related components, you know the show- that's the right time to tell us so that we can um better understand. Basically, the efforts required.

C

Okay, so if there's nothing else, we can move to the next point, which is basically metamask compatibility.

C

So there was a discussion in the market in internal uh recently, basically again andre correct me if I, if I'm wrong, uh so there was an issue with that, I don't remember which, which type was? Basically, it wouldn't work with status bar wallet? uh Well, it would work with, for example, metamasking as opposed to trust.

C

The reason being is that he was making a call to get the accounts and status bro status. Census browsers was following the um the specs and it was throwing an error, because the dot did not request permissions.

C

Well, it would work a meta mask, because metamask would not throw an error, but instead return an empty array, and so it would work in that place and it seems like this is a bit of a recurring issue where metamask is the de facto reference implementation, and sometimes when it disagrees with the specs people will code against metamask instead of calling against the specs, which puts us in a bit of a tough spot because, essentially like we tend to follow the specs.

C

But that also means that dapps tend to break because they call developers tend to code against metamasking metamath, because this works um and it's a matter of you know. What should we do about this?

C

And do people have an opinion in general like we know that the right thing to do is to follow the specs, but we are paying the price of you know being compatible with the metamask. Essentially, so I wonder if there are other.

C

C

Anyone has any opinion on the.

C

Matter: okay, so.

D

My well, I guess in in this case it doesn't actually affect anything like security, because you're returning an empty lease, so it's not like you're breaking specs in order to provide data that shouldn't be provided. It's your breaking specs to just not break comp compatibility with how dots are implemented right. So it's not like you are endangering any data or anything like that. You're, just uh essentially bending the rules in order to not break but.

C

You might break compatibility with with adapts that respect that, for example, if you yeah, if the dark, expect an error and says okay, I haven't asked for permission. Then they would expect it would interpret empty array as there.

D

C

D

And I assumed that that breaks is the exception of the rule. Most apps would not break, or do we do have any information like which is more prevalent.

B

D

B

Can throw a curveball in there too? I know um metamask recently changed their behavior after the beginning of 2021.. uh They did an overhaul of of how the metamask client is supposed to be interacted with, so we might have to watch out for that too.

C

D

So it's a bit of tough.

C

It's a really tough spot, like the the best I can think is to provide a metamask compatibility mode uh to users, uh which is not great and it's difficult to explain to the user. But you know like that's the best thing you can do like you know. If, if an error is thrown and kind of understand that the error might be in compatibility, you could say reload that using metamask compatibility mode and we provide that and at the same time, pressure metamask rather end up. You know basically creators to be consistent with the specs.

C

It doesn't sound like a great solution to me.

A

Yeah, I think it's this problems, it's not the first time we have met them because in the past we had like loads of such cases. Then mr musk implemented something and supported some specific, dedicated dub and uh it didn't work in status and uh currently metamask.

A

um They just keep different implementations and it's currently we're discussing the one case, but there will be more and we can't just implement all these in our app, because I mean because, for example, meta masks still support dubs without the permissions and status doesn't support such dubs, and we can't like in enable with mode just because metamask doesn't force it or whatever.

A

So I would say we should try to.

A

Should try to keep um specs implementation and force, I would say most dubs use the web 3 provider, libraries and we should just force this linkman spec, and this is the best what we could do. I believe.

C

Other opinions on the matter.

D

Yes, specs are the word of god or, as close as we can get.

C

D

Yes, I would argue that to.

C

Be honest like I think there is a lot of value in.

A

Reference implementations.

C

uh um When you have specs, you should also accompany them with levels. Implementation, because uh specs can lie code can have bugs, and that's true, but it's easy if you only write things on paper, to miss some personal aspects of the implementation that that happened with mathematics many times that.

C

The the specs were not implemented correctly. Metamorphically became the developer standard. Unfortunate I mean a set of tests is probably like find a lot of these issues, but that's a different set very separate, separate issue. um Okay, so that's the the two points that we wanted to discuss.

C

um Anyone has any announcement anything else that you would like that. We would like to discuss.

C

Okay, so that's that for today so yeah. Thank you very much for joining the call and talk to you in a couple of weeks. Thank you. Bye thanks.

B

Thank you, bye, hi, everyone.