Status Core Developer, 3 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Core Devs Meeting

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

Right just going on YouTube and then we can start now Monu volunteers to be a note-taker.

B

A

Some weekly take notes great.

C

A

Thank you so much all right, so welcome to the eighth quarter, ko I thought, since we no longer sold do this.

A

Town hall updates regularly for teams. They might be a good idea to just give like a five-second one minute update, but what's going on in in Sofia's form the last week since the first I'm we're doing this, people might not be prepared prepared or whatever that's okay, but maybe we can start with core I know you go if you have a brief update when I like this sort of orientation for other people with what's been going on.

D

Sure it makes sense.

D

Should I start them yeah.

E

D

Okay, so what we've been working for the last two weeks are primarily the message: liability issues and slow, startup and PFS. These are three topics and we of course, in PFS I, mean also private group, chats and device.

D

So with message reliability, we deployed the cream that checks, consistency of their channels on our mail servers right now and we merge some stuff like receiving acknowledgments from on the whisper level and some smaller things as well. On the group syncing I guess it was profile, picture and username, and now we are going to public chats on the group chat, say yes yeah. They were there like disabled in the night with the, but they will be enabled soon and I. Guess the wisest ask was something about transferring could mean rights to someone else.

D

If you want to leave the group, something like this and in the background, I was also testing, Elias and ELC, which would get hit a little bit by this constant in Nepal's India, so quite a few bugs related to that. But we have finally merged the latest go aetherium to our code base and while we were testing their release and it seems to sink at least- but there are other things we mean say you were working on this. There is these two box or lesson you'll see. Yes, that's more or less in the broad strokes.

D

What was the most important about that core to know more things, but.

A

Right cool, any research subjects.

A

You I can say briefly just on the protocol side of things, so we started up, collaborating with them with free foundation and valid labs and smaller teams with ideas of figure. You know, are the bearers of um this repository where we are collaborating with them. It's sort of still a list a to know the recent stage. This will say the secure messaging companion has been given a place in in at the github awesome secure messaging. We cannot stop in also look at resources.

A

We also working with web free foundation to sort of try to figure out figure out the time for having some kind of workshop or we can get together and och, but I've been working on and also personally is worth looking into distributive state and asynchronous messaging and as well as sort of things like mix networks and how they they're, how they're different design wise and what those constraints mean for us in terms of topology and peer-to-peer these types of things and that's sort of an ongoing effort, also working on sort of getting a more final Swan proposal, set up with rough milestones and generally creating more of clear separation problem statements.

A

So they could be a technician where one of the milestones is also in terms of figure out. What what so far? What sort of this later we're working on it requires in terms of underlying Lipa, to be overlay network, whatever it is and what it can provide. So we can start to look at those things. Empower!

A

That's it for me anything else from other research, things or.

F

Well, I can mention a few things, so I, don't know how much you guys are following Nimbus development but or return 2.0 development, but briefly, what's been going on. There is basically that the foundation has cleaned up the specification really well now.

F

So if ever there was a good time to get into reading the two photos back and understanding a little bit about it now is actually starting to be a good time.

F

We have our dock writer Bruno that pushing out some great tutorials so make sure to check those out otherwise feel free to to just you know, ping me or anything and I'll be happy to have a conversation. But what if you're in 2.0, is about I'm like what that means for Nimbus and so on.

F

So basically we're taking on a few people there and we're splitting up we'll be focusing work on hearing one for a group of people, and then another group of people will be working on this hearing to basically- and we hope to have a little bit contain milestone up and running so that you can watch the black and white lion scroll by, as the things become log statements by the end of the year.

F

And then the plan is that for March, the various teams implementing clients will be communicating together in, like, like a pre-launch, Testament kind of thing.

F

Other things, research advocacy here, I wish you proceed with the you'll, see integration and.

F

There is also a project to.

F

Incentivize running nodes, which at some point we thought we should look at it in some shape or form. So that's the kind of stuff that interests you talking as well.

A

Cool awesome, what any product team updates.

E

So, with regards to 30, richard is currently working on open, create and closed function for the voting there, and that should be. We sought them over last week, Thursday so I suspect either this week or being testing with regards to liquid funding. Barry is working on migrating. The liquid pledging contracts to embark, as well as investigating some technical questions.

A

Cool anything from wallet or chat or daps I know that the duck team they are on a day, Cyril trip, but maybe small team.

G

Yeah from from the waterside we are currently implementing the Wallach redesigns so expect cool and user-friendly screen stones, that's more or less our update other than that. We are prioritizing the items and you know doing the planning, as that's the same one, that everyone else is this so yeah.

A

F

D

E

Yeah yeah, okay, so on chap team we are also setting up. We do three meetings a week and yeah. No, no important updates for now we're just moving on.

A

Man, testing or infra the DevOps or security.

H

Yeah, so I can start testing when it comes to infra. Well, this week has been out of work related to upgrad invention stuff, especially thanks to do two. Others work on increasing yarn, which also opens the path to upgrading a bunch of other things like android hit decay and possibly upgrading a node as a whole for all builds. So there's that I'm also working on setting up a search for our pages and that would work across all of our public resources. So we really have a gnostic search pastor that they cater to that right.

H

Now, writing a plug-in or hexa to index our pages. So you can search what else, because those are the main things that have been happening. There's more details, for example, we're trying to introduce snake for automatic loading of the mostly work from from curry, but I'm. Also taking part in that. That's, oh yeah! We now have a new my email server canary. Is that essentially check if the message is available on different servers in the fleet are the same and if there are discrepancies we'll get notified, so that's pretty cool.

H

That's thanks to Adam, where elsewhere else, yeah, oh and one cool thing. We now have checks, infections for our boats, so with every PR build a ninety build. There is a file called a shot, two five six and it includes checksums for all artifacts. That's kind of neat nice about it.

E

Okay, so automation automated testing, it's here and we are ready to block the ours without pull the past and turn test. But for that we need only one issue. A share now should be in reveal to be fixed and we can nourish a PR visual block, as appears if no pass test there. 100% pass tests also we added new desktop tests and there are two investigation projects regarding automated testing of key card and after meditation for nubs, the fits from us.

A

Right cool did I forget turn on. Anyone else. Has some updates before you move into other topics.

A

All right cool, so I guess we can start with decoupling, whispering what key and really wanna take the room. Yeah.

I

I

Yep, okay, so so we've been talking about this topic for a while and now that's we are implementing it. I would like to share the ideas here so that it's everyone knows, because it would be like a breaking breaking change and we have two different keys for wallets and whisper. So it's better to like work together on this, and so that, just to remember why we are doing this. So we're doing this for different reasons.

I

One is for privacy so that we are not sharing like in public charts and in general, in chart the wallet address and all the transactions that we made for security reasons, so that we have two different keys and we can also save it, save them in different ways and for the kicker, because the goal of the key card is actually having the wallet key on the key card, and you should never leave the card and it's used to sign transaction and then having like another key, which is the whisper key that can be downloaded from from the car to the to the client to encrypt and decrypt messages.

I

So for for the wallet key, we will continue using the normal the standard, VIP, 44, derivation path and then for the whisper key. We are proposing another like EAP for normal, let's keys, so I posted the link, there's a link in the notes and it's basically defining like a way to use, extending like the the the b.a.p 43:12 different keys, one for each purpose like one could be in general, like chat, and we will use it for four whisper and other keys like for other kinds of encryptions and everything.

I

So now that so there's a branch or a dingo theorem, sorry in stitches, go with also some changes in go Assyrian version, and it's already like the couple in the keys and using the two, the two different paths. The thing that we need to decide now is how we want to exchange addresses for in chat transactions.

I

So, basically now, when you are chatting with someone, you know the whisper public key, which is a chart like identity and you can derived what we do is like deriving the address and just sending in the transaction to that address without interaction. So now that we have two different keys- it's not possible anymore, so we need to to define a way to exchange these addresses, so one can be.

I

When I add you to my to my contacts, we are ready, sending some information, like my name and my picture, so we can also send the address or we can have like requests on demand.

I

So every time we want to send the transaction we can, we can ask for for the dress and the other user can decide to share or not so accepting the wallets address request, and so these are the mostly the the things that we need to to define and for the rest, I posted some some links to some discussions and the steps that I'm implementing in the status quo repository and also the the branch that I'm working on.

I

So if you have any idea or yeah about these, please share so that we can. We can sit together.

D

Yeah I still have this question that I wrote in the discuss forum. So I don't quite understand how would it work without the key card for the users? They don't have a key card because all the discussions were they were like. Okay, we story and based on the key card to store the key card. But what? If a user does.

D

I

It's a good question, so the actually the the first step is implementing the decoupling without even integrating the key card. So what it does is from the so when you create an account or you important account from your mnemonic Keys, we internally like generate the master key memory and then what we do is deriving the wallet address, which is the one defined with like the baby 44 path. And then we save these this key in the key as a key key file store in go theorem.

I

So what we are doing now is creating two of these keys, so that one is only used for for transactions.

I

So it's the wallet key, which is the the current one that we have and then the one that we saw. The key that we inject in whisper as a whisper identity will be the other one who's, the other path that we that we defined and yeah. So this one is even without talking about the card, and then this allows to to have basically the same so managing these two keys in the same way for for the key card as well.

I

The only thing is that the the when you use the key card, the wallets key, will be on the edge of.

D

Something like keychain.

D

So maybe if it will do something that will use key card, for instance, as a secure storage, maybe it makes sense to make it more generic or just also doesn't.

D

I

Yeah, it makes sense also because the way so now we are using go theorem for so all the.

I

Like destructions, so the way go theorem saves the keys, but actually we're not using the the rest of Goya theorem to select a key and everything. So it would be easy like to to move this. This part of the coin, just outside the square theorem.

B

So from a user perspective, is this going to be it? This will be a breaking change, I assume that will all be needed to generate completely new well in addresses. We won't be different deriving new ones from our Exton identities that we're using yes.

I

So the the one that will change would be the whisper identity, so the the public key that you used to in charge basically to be contacted, but the wallet address would be the same. So basically, if we feel installed in you up and you import your monic phrase, the wallet address will be exactly the same, but your chart address and your name. Your three words and everything will be will be different.

B

Which will mean that any history associated with the previous chat identity will be been lost or will be be so grandfathering in our lovely stored chat histories.

I

Sorry, I didn't understand, can you know repeat, use.

B

So at that point, will previous messages in the client be available under the legacy whisper key identity, or will they then be sidelined and lost with the issuance of a new whisper key.

I

So it depends on the way we implement some parts like on the way we I think visualize. The messages I think the the messages itself is still in their database and.

I

We need to decide how to to make this showing that and it was sent by your knots, but the message itself should be should be there if I have an correct.

C

I mean the existing key can prove that the new key is still theirs people by signing or something and then doing AC recover on the client side on the receiver side.

I

Yeah also, that's a good point.

E

Have you given much thought to what this will be like from the users experience, so they download a new version, they open up status and what will they see.

I

So some meaning upgrading and not just downloading the new app right right, mm-hmm yeah. This is something that you need to to decide so the way we want to upgrade like and do the first thing that we want to import the.

I

The mnemonic or doing something else for sure they need to import the the mnemonic somehow just for a reason because to derive the new key, we need the master key, the master keyed, the master key- is not stored in there in the phone.

I

So we need to like regenerate the the master key from the mem onic from the mnemonic. Now we can, we can derive the the other, the other key, so I, don't think, there's a there's another way to do it I think we hold.

C

On like, why can't we derive case from like we can treat the current one as the parent you can derive from that right. It.

I

Would be possible, but so only if we, if we, if we basically derived the whisper key from the the wallet key but the way so the way we proposed the EAP 1581 for non wallet keys is like taking another path from basically the already the the first level, the first part of the path. So basically it's like some level higher than then the wallet key. So the wallet key starts with M / 44, and something and and this one would be 43, because it's extending that way before the three and everything.

I

So it's a complete different range like.

C

So iconic curious: why don't we keep the if we're doing that if we're deriving from the last key? Why not keep the key structure as it is and instead in the client we generate a new new wallet address and we translate, we Auto transfer the funds from the whisper key into the new address. Wouldn't that be simpler,.

I

So what do you mean? You mean having I.

C

Mean I mean so so, instead of changing the public key for changing the whisper key, you keep the whisper key as it is, and since we were deriving another leaf from the roots that can be the wallet address and then, basically, when you open up a new client, it'll be like hey.

C

We are now transferring your funds away from your whisper key to to this other one in which that would in which that root whisper key can then be the parent for any new, subsequent whisper keys and the secondary leaf on on the root can be the root for all subsequent wallets and.

D

How would that work? It imported his account from meta mask or from somewhere else.

I

Yeah so just to understand, if I understand correctly, and if you correctly so basically we can use the so we can keep the current key that you have only for whisper, but what we change is like deriving another key for the wallet. So in that way it means that, if you, if you are, if you created an account, the meta mask you import it in in status and basically the the whisper key will be.

I

The first account in that you have a meta mask and then the second account that you have a meta mask will be actually our wallet so.

C

I mean if we're concerned about meta, mask and its compatibility there. Then we should be concerned about the derivation structures of every other wallet. It's out there right meta mask is not the only one so and they all have slightly different variations of what the structure should be.

I

Yes, I noticed that also ledger is, is changing soon. Yeah.

C

They say is a change from the previous one to when they created the new firmware in the new application. They changed it again, which was kind of frightening. For me, yeah.

I

I saw that's also another discussion about that. We had about like supports in different paths like this.

C

It sounds like we need to do a little bit more work in terms of either creating like a better standard between all of these different clients and or.

C

Whatever evasion paths, they want.

I

A

I, don't know we're just wondering there was some conversation at Def Con about different standards and so on. Does anyone know what the conclusion of that those meetings were in terms of creating some kind of key constant I believed was maybe wasn't on this type of section level? I I'm not familiar with details.

I

Which discussions about the house.

E

A

Was they would say, I think like a meeting between a bunch of like meta, mascots tear some hardware who all the providers were there.

E

I

There yeah it was yeah yeah, so we didn't talked about about this this thing, so we only talked about how to you're like supporting the the kicad. Basically.

A

I

A

I

Then we we proposed, like this ap 1581, for these reasons, so for the different keys that you can use outside of the wallet like not only for transactions but for different reasons, charts and other stuff. That's why we are like pushing on that direction and of course it's I mean we can just stick the side because it will be like making change so.

B

So this discussion is happening. Would.

A

It make sense to bring this up with the larger community in a form of like medicines or so over an EP in terms of how this should look and well across multiple. Yes,.

I

The AAP that we proposed was already is already merged in English idiom. Sorry in the EAP of the cerium.

I

Github, so I can check it. Okay and being.

C

Merge doesn't really mean.

I

That much yeah, it's just a draft but there's a discussions around it, and we can continue like the discussion on some this so that it's like not only for us but in general, for as I a peep.

B

So the wider discussion is happening, that on github and and is there anything being discussed in the wallet ring on a theory of magicians.

I

Yeah we posted, we posted that the links and discussion, so Mikayla was imagine this and we didn't sell a lot of the answers. So so we we paint someone from aetherium and we had a little conversation in this yeah. This pull request for the AP and now, as the emerges our draft, and we can maybe I just ask again and continue the conversation again in the Phaedo magician's forum and everything.

B

For a second and say that might be a good thing to do a blog post around this whole issue, with the links to the various things and and to get some push to a wider community, more publicity around it to draw on any other people that need to discuss about it. Yeah.

C

And I also think for developers to look at Micra do when you're signing a transaction that uses like an HD key and how they look at that and see how we should be, and then like use that as the basis of the UX research and on how we should actually go about this almost thing how they do. It is correct, but at least they give you an option between different modes.

E

A

Pakora estimate to be sent right now.

B

Well, this leads me to think about the identity work that Andres been doing as well, and the ability to have managing multiple identities with multiple wallets in the client. So it might be good to take a look at that work and, together with you, x2 to be considering these things that we have then potentially a legacy identity, and you can have a potentially completely new identity to couple those things together. When we make a decoupling from the whisper in the wallet key yeah.

C

I agree with that Michael, ultimately like we should be trying to strive to a point where private key will s are key. Pairs are ultimately disposable and on chain identities is probably where it's at but like. We should still good options to people who don't or reveal themselves in a form of an identity on one chain.

A

C

E

Requests a bias debunked to.

B

Basically, pull this all together that we get you do it's sort of like a unified launch when we're doing our new identity management that we we pair, that, together with decoupling, the keys and we'll need education and they user flow for that. So I think that would be a good convergence point for us to work towards.

F

A

All right cool, sometimes I, guess we can move on to the next item, which is you know, Fred.

A

Disgust and I think what we have seen is really about world dependencies being compromised, so there was I forgot one who once was it copay? Yes, so essentially they had like a nodejs dependency that had another dependency and that's that dependency was take. It was taken over so the original maintainer wasn't maintaining it anymore. Someone came along and took it over push new bush and had some obfuscated code and his hands.

A

They sat there for three months and ended up with the specific wallet like people use this or that wallet loosing their funds like a very simple attack victim and in the recent in hit us it's mostly because of luck and that we aren't used that much yet otherwise. This could easily be targeted with us and it's a form of like super super chain exploit and I guess for context.

A

Right now we are sort of using reckon a tip and we have around like thousand dependencies underneath that was a huge problem, so what we saw when I figure out this world. What we can do about this and I saw what's implies for development going forward in priorities, because this is something is very sort of say well, yeah. We work on it, but we need to chain some drastic that otherwise. This will happen to us. Yeah.

D

Because the biggest problem with NPM- technically it was not that is like we had these dependencies, but that NPM never really checked that what was download. That is what was requested. So we essentially never used to log files. So as soon as we got some dependencies whenever they were audited and the version was like what I was ero 101 for instance, and then someone republish explosion, 101 with a different binary, we didn't have any mechanics to check it.

D

That's how essentially I guess that's how this thing went through, because I guess this guy hit first, he essentially published the same version version with the different binary and then NPM what it does it just almost whatever binary there is and doesn't create the checksums, even though it writes into log file. So what we did instead was so waiting threw away their completely.

D

Yeah, sorry, you continue. No, the.

B

Two things so Corey's work on auditing dependencies was that's has to do with the implementation of snake that the Jacob mentioned earlier, that we can start identifying which, which ones are audited and then making a note of what isn't and I guess then, also the shift to yard, where we can freeze to specific builds as well as another way that we're approaching it. The attack vector one.

D

Example, that's exactly what the are that's exactly. What yarn does that essentially looks to the specific binaries hashes and checks them and if they are wrong- and that was exactly what we have changed so if some some binary with the same version was downloaded, but the hash of it was wrong for some reason, then we just it won't build anymore. So.

H

The dependence is changing to something that has a vulnerability, but it doesn't actually solve the problem of dependence. We've already been using for a while. That might still have the vulnerabilities, and that is the point of snake.

D

Trying to emphasize some yarn because the regional point in auditing dependencies, if they can be changed at any time and we can really detect if they were change. It's essentially, you can you, you can just skip all the audits in quotes forever, because someone can replace it. Then it won't be audited anymore. So that's.

H

D

Yeah, that's why yarn is like the first step, that's a baseline, without which we were able to.

E

A

Its greats to partial console, step, I guess to launch a question of like what do we do with the fact that, like someone can update their dependencies and they can say well, oh, this is small bug fix or whatever, but really this is obvious kind of thing and like how?

A

How are we actually going to change how we develop because I mean it like we it's a problem right when, when, as we get bigger and people start to put funds in us like serious amount of money, like will become a target and like it's it's kind of trivial, considering all the dependents that we have to just do something innocent change. So we need a more structured approach. That sort of this is commensurate with the phret mall that we are facing right.

A

H

Comment because it plugs into github and it actually checks every PR for for changes in dependencies and I haven't looked a bit at configuration, I haven't seen all of it, but there might be settings where you can, for example, block pr's. We don't have explicit check on the dependencies changed or added, and that's what part of what what me and Korey will be doing so any dependency changes are, are better audited and checked, appears.

D

And we probably need to expand it to the other languages as well, because right now my fix did you have a script? So we are fixing the JavaScript stuff, but they're also like at least two more dependency managers that we use to build or three more to be exact right. So there is like dependency manager and go, which is a little bit simpler because it's just download source files, so you can't really get it without see the source files changed in your repository, then the second one is cocoapods.

D

When we download something for react, native, iOS components and the third one is Gradle or maven, that's runs behind it. Let's actually download some closure and Android artifacts from whatever it downloaded them. So this this thing should be also covered, which they are more hidden than JavaScript they're, much less of them, but they are not so.

A

What one one console like one thing that makes me uneasy about this is that even though these are so, it helps mitigate problem to some extent, but it's still you're a Texan like the keycode is great, but, like other other ways, we can be not be one mistake away from people losing the funds. That's the kind of property I would like to like.

A

We should be two steps away from some kind of compromise and whether that's because this is the way you have if you want have secure code is by having like no no code right like no dependencies. So so, how do we move closer to that when it matters? That's the question. I would like to explore how we can sort of create some kind of corner where things are secure and.

B

A

Exposed to randomness right.

F

So security should stay hiding complexity and it sounds a little bit like we're trying to solve this issue by adding more complexity by bringing in more tools by bringing in more things that check that the things that are supposed to check that we're safe, so I'd probably want to repeat what I just said. Is that a dependency which you don't have is one that you don't have to worry about?

F

Is there any way we can simplify things instead of adding more things that would lead us to a more secure world, because we address one problem but but we've had. We hide like the fact that these things they happen because they're hidden inside of complexity, inside of processes that people don't understand and when people don't understand things. That's when you can apply things like social engineering like which, which tends to be the biggest threat back there right.

F

So even if we lock down the version now, there's in that complexity might be hidden a different way to socially engineer the vulnerability.

D

I mean we can just make a conscious effort to just minimize penances, as we can, which I'm being a little bit skeptical about in terms of JavaScript, because I looked at the NPM itself, the command-line utility, and it has like 1500 dependencies itself, and it looks like that's that's how JavaScript works right now and I'm, not sure if we will be, and since we have the biggest issue is not our dependencies first there we don't have that much our dependence. We have a lot of transitive dependencies.

D

That's like react native has a five Brazilian dependencies itself. The other libraries so I'm, not sure what we can, of course try to remove one thing, another thing, but unless we keep in say, react native, we'll just probably keep over a thousand dependency same way or maybe over 500. Something like that. So I'm not sure how to tackle it.

A

It's some way to to gain.

A

Odd but in software we are like a separate process and some kind of communication is more limited. It's not an option to some extent.

D

What this is that vulnerability as I understand this was done like this NPM thing is that they managed to overwrite retrieving the private key method and it'll go through two minutes ended, so we probably might isolate all the key management into something super small that has zero dependencies. That also doesn't have any API API to get the keys out of it. So it can sign stuff itself, so think things like that might help to isolate a.

E

Situation, yeah.

D

So and make sure that this key won't, so you won't be able to retrieve it like you can just generate it or you can somehow import it. You know generate inside by something, but then you can only sign using it and that's.

F

And how do we make this a culture as well? How do we make sure that it's in great thing in the organization to think in these terms, for example, you could use sound boxing as a model.

D

We should probably the review phase in this phase on new features and repeat this over and over you know what maybe some education will help, how.

F

Does it go with the stride framework and the introduction of security champions.

D

Well, it didn't go very far Frank, so it's right now. After all these changes, I guess they're. Only a few security champions left right. We.

D

A

Isn't here, I think the last last I heard was that there was a general conversation within the security I mean like security.

A

Elegance that was lasting ion.

D

We thought about three: creating security champions with the new teams, but much less of them right and I think that we probably need to continue discussing this with Koreans start doing things more to discuss emerging because it's yeah we just essentially what did happen with this is security champions is that we started doing them and then yeah lots of things, change and organization structures changed, and then the teams that supposed to have champions weren't exist in this.

B

Think we do Jared. Do you want to say something about that in terms of how it is that we should move forward? Now that we've had all these organizations changes, we have any spontaneous ideas, or could we little or some sort of direction from you about this.

C

Thanks for putting on the spot.

E

H

About how about it.

C

How about every like every swarm has to have a security champion, or something like that like I mean I'm, not your dad like there's like this, should.

E

C

Like this would be, that was like everyone thinking about this stuff.

D

A

Mean I think there's a specific issue we're talking about, because the ease of think that, like I, mean çiçek, was saying like you, you try to figure out complexity. You you try to fight like stupid complexity, but but really when it comes to this specific type of vulnerability.

A

Like sure this all this sort of cultural things and so on, but if we're talking about private keys and and signing like, like a dependency even being able to do that kind of thing, like that's a kind of a simple Phet model and and and just solving, that would be like a very clear like 80/20 and industry and nice things we can do on top of that. But I think just getting that point then getting to some kind of sandbox state would be useful.

A

It's not clear to me what that path looks like or what sort options are or mobile, I think that that brand, some research, but what we did the nice thing about, that is that, then you can. It doesn't matter what kind of things go on around it just like if you're a keycard you, you can make some kind of guarantees in the face of uncertainty. So so that to me seems like a first step and then there's other things we can do as well, but just getting to that will be useful right.

G

Yeah there's some architectural decisions we could use to to help us move in that direction. Specifically right now we have, we hold all all Arab state, DUI states, at least in one big fat, every big, so any changes in one part of the app can accidentally leak into the other part of the app. So it's not actually easy to do to manage any specific module in in isolation. So you know what what I'm trying to say is that we were discussing.

G

We were discussing purposeful, intentional attack, vector due to some guy, taking over some dependency and doing this all this stuff with it on purpose, but we can also have a completely incidental, basically bugs that also can that can also cause damage. The only difference, in my opinion, is the intention or lack of it, but you know the damage is the same. So so, basically, we should probably isolate related parts of the code into modules that have clear, api's and you know protected state.

A

Sorry, I think a good one good step first, that was this would be to have some I said a model that doesn't touch react at all right if that's sort of where most of our dependents come from. In terms of this specific class of attack or randomness, that seems to me- and it would also probably lead us to a good place and stop to think about this in better ways and so on. You're.

G

Talking about dependencies like external dependencies that we load into like yeah separation.

A

Of concerns right the fact that it's it's handled in the same space, it seems like a problem to me. Yeah.

G

A

Is like a straightforward to fix and then then there are other things that we need to do and more subtle effects, but that's a no brainer kind of thing: yeah.

G

Yeah, but my point was that, for example, if you're fixing some feature in wallet, you do have all the access to the state needed by chat. So you could even accidentally break something else, no, never mind my intentional attack, it's even possible to breaking things accidentally. So if, if the app is less fragile, it will be also less susceptible to two attacks. But yeah I agree that it's an order of magnitude, less important than say reasonably straightforward and easy easy way to attack through some kind of a dependency.

A

So we should probably have a separate call for this and it would be good to have core on it, but but just think in terms of isolation like you can have a hard wallet whatever you have a trusty display right and then there's only so much communication. It goes like you see things on the display right and we can do things like that with the key card, but it says somewhere we can regain the same kind of trusted, use interfacing, key handling without being exposed to, like some random dependency did or whatever type of thing.

A

G

But the problem is that the key card in generally store a safe storage of keys, isn't going to solve all our problems. For example, let's say you want to send a large amount of eater to someone. A bad dependency could, for example, manipulate I know the way the address is being displayed or change.

A

You need some trusted UI and, if that you wise it does more subtle to attack vector- maybe that's that's yeah I, don't know yeah.

G

Yeah but yeah first things: first, there every I.

D

Think one more relatively easy thing would be to also implement native UI components for some security, critical places like use them and also they might have no dependencies whatsoever. Because, okay, one view with the text field shouldn't have a dependency on.

D

A

And think that's a good way to think about, because Greeson we have a key college, because you don't trust your phone right. So that's sort of the secret again we can t we make there, but if you're, using Apple or Android and security guarantee, we want to make clear. Is that as long as your phone is not compromised, it should be fine right and even then maybe it's still fine. The problem is that we we sort of have fewer security edits and that because of letting in this sort of randomness and complexity.

A

So if we can regain that in some way or having native user interface of critical things or whatever right, that would be a way to make sure that if the Apple sandbox not always secured and our physical or whatever right having the same kind of level, yeah.

D

We also want sense, necessary events like two JavaScript code, when you type so it will be for JavaScript. It will be completely invisible. Essentially, you can just short-circuited to I, don't know the gold module or something like this.

D

A

Kissing up like a separate chat with the core team and maybe wallet and anchoring.

A

Any other thoughts on this then on topic.

D

So uh the last small thing about what I guess last thing we discussed with Cory was to have champions by technology really like two people for like closers part and one person for the go side. This was the last idea.

E

A

And then guess moving on if we have time we have some time so that drive the point on keeping track of artifacts using a build I. Think Peters not here. Does someone want to talk about this, or should we skip this for next one I.

A

Guess we can skip it and then Igor you had some but upgradable message: IDs yeah.

D

So there was a topic for a while that was breaking a few times already, so we were discussing the way like me.

D

And Andrea were discussing how to deal with it, especially in terms of like replies and seeing messages like that they kind of have to have to mention other messages. So there were different proposals and things so what we ended up with that's. Actually, the idea to keep message IDs as the hashes of messages is okay, but we really implemented it in the wrong way. So what I want to discuss right now is just to you know, bounce this idea and maybe get some critique on it and some conversation about where it might not work.

D

So what's the idea voices that we hashed the message here, there's the hashes, the idea of the message, and it should theoretically work as long as you have the message before trying to interpret and deserialize, because right now, what we did wrong I think is that we as I understand, try to interpret the message and try to validate into something. So we don't just take the raw payload and hash it, but we have some like hash of interpreted version and that, of course, changed changes depending on how what's the code interprets it.

D

So if it was version 1 that interpreted in one way and version 2000 then IDs does information it fails. But what I thought in the end? That's if we don't do any interpretation at all while generating the idea. So we just take the rope, I load, what's whisper or whatever transport goddess and just hash it, then it should be pretty much guarantee that what was sent the same was delivered and then doesn't matter. How do you interpret it? Which fields will you miss or which fields can you interpret or not? And things like that?

D

So that's the idea. So I was hoping to just talk of there any edge cases that won't work in this and things like that.

D

Ok and I can say like two words on how: how did we come to this idea? It was essentially with replies, so the idea was that we want to maybe do normalize and include the original message in the reply, but then how would we figure out that it wasn't tampered with and that we need to sign this message? And if we need to sign this message, then we need to sign the whole contents of this original message and then it's not better than hash of this whole message.

D

So why don't use hash of the whole message, but it doesn't work, but why doesn't work because we try to interpret it because before hashing anything so yeah? That's the idea that hash of Rho payload should be good enough and.

J

I think they would later odd, so basically from there. You know the course is relevant that there is a PR out that you know for the release. Basically, we would change message, ID format at some point in Knightley's, and this PR had some some code 200 days and now currently works and is basically ready to be released. The message ad that we changed formatted in 9, please like this- is not the one described here. So if we do change it again, we to keep compatibility.

J

We need to add code to support 3 version of IDs now, so this is obviously not desirable, but there are some time constraints on the release as well. So if you'd be good to go to make a decision, whether we want to sort up the lady's PR get the implementation. You know name I'm, not saying right, but you know like as best as we can so that we don't know that we're gonna actually have to upgrade like next week and push out the PR or push.

E

J

Out as it is and just bite the bullet and have you know have to you know, support this: could it's good again or make a pretty package so such like the pragmatic decision? What we're going to do with this PR I.

F

Would push back a little bit against the idea that maintaining several competing versions necessarily? Is that costly I mean that's the kind of thing that you should be able to isolate like from a functionality point of view? They all do the same thing that you should technically. You should be able to isolate that and like having the three different versions is good, because then you can compare them as well for a slightly longer period of time, as maybe it's a maybe like.

F

This is a problem that we'll be facing over and over and over and over and over again. So perhaps it's good to introduce some infrastructure in the code in order to make that and handling those kind of situations, not so costly.

J

Yeah I think that is an option. The only thing is that the whole code is no structural to sort of support these and so like, even even just looking at the query, looks a bit confusing so complicated. What.

A

Makes a what makes it difficult to like what why why, at.

J

This point you know like we want to have like then versioning is like they. You know that finger new message. The new ad is called probably just new message. Id, for example, is a field called new message ID, so next field will be new new message. Id, you know if weird, maybe then I was going to just add versioning, probably or something like that. I'm not going to be a look to be are very briefly.

D

Let's have the variables in the code, so they could be pretty much.

B

D

We don't we don't encode this ID anywhere.

J

We might be doing that no.

D

So yeah I should I think we should just introduce version and click right now. It should be a very simple change to this yeah, just instead of a new message and you just message: ID v2 or something like this.

D

Would do this we want me to but I I agree music that sooner or later, we'll have to face this issue. So what's.

A

The difference between this, this rationing and I mean we have worsening in other parts of the code right like what's the difference when we do so the realm schemas for messages and so on, like what's the difference.

D

I think the difference is that it's a part of the message payload in some cases, so.

A

It's not the same. It's not off the case for what the things we store wrong.

K

So, like questioning poor young for some reason or message.

F

K

Ego these two things are different things, so like real stuff wouldn't help here. But the problem right now is that we actually can trade, the pistachio version and other stuff, but if you want to release application in two days that we can do this right now, no.

D

Infrastructure to have.

E

To answer Oscar, we own is really different, because the migrations are local and in the case of.

I

Migrations of message ID, it means.

E

You send the message ID, as well as the.

I

Message for the old versions.

E

We cannot upgrade the skill, the the message ID for all those versions.

C

Yes, isn't it backwards compatibility.

F

But I'm arguing that you can do this in the backwards-compatible way too much it later and you think and that it cost is zero yeah. But but it's like in general, as a mantra, the cost is near zero. It's a couple of bytes in the message: it's like nothing right and if you approach it structurally in the code the right way, it's also going to be close to zero. But it's a killer feature for for users. It's like they're, like people, are very impressed.

F

If you're able to maintain compatibility and then we can make informed choices to remove things based on specific criteria or say security right, so that we can keep the agility of having of being able to choose good technical solutions and, at the same time like have a structured way of dealing with this problem so that it doesn't sort out every time it comes up. It doesn't enter in the developers mind at all, it's so costly to add another version or whatever.

A

Does anyone disagree with that reasoning.

E

Well, I agree, but it means we have to break compatibility first to introduce.

D

I mean why I don't see how I mean if you have like, if you stored some messages like yeah, you might have problems with mentioning messages that were already in the database, because we don't store all content anywhere all right, but all the new received messages. You will be able to generate everything. Just fine.

E

Yeah, but what about all clients that will receive the new messages available to him.

K

So right now this is handled this parent. We actually can do this. We can send the same filter as reference and before and it will be compatible with previous fashions, like nothing prevents us from sending the same data to all the time for previous fashion or protocol.

K

You does it make sense, then yeah.

D

It might be on the cost of traffic a little bit because you're introducing that the second field, instead of changing.

K

You have some handshake for this, and then we will know that some specific wattage this one-to-one messages require some specific version of messages in order to communicate, etc like well. We can do this. The question is, how cost it will be and how fast we can do this, because we need this for our release. That's what I am repeating all the time, because, right now, we.

D

K

D

I guess what we did for release is just to add one more field. So reply to and reply to you too so reply to still contains the old format. Id and v2 essentially contains the new format of ID. So the old clients won't open the old one, because you about it always and the new clients who can will be able to just ignore the old one and use the new one.

A

So I guess internal I mean I. Think cadenzas, like we like this absolute discussion like maybe we don't, we want to maintain compatibility and- and it just may be because we haven't been grated in the past. So it's seen as this like optional thing, but really it's not optional so like maybe we can.

A

We maybe don't need to bring this up in this house cause like it's like, maintain, compatibility and like it is a really really good reason like security-related or it's impossible, because we screwed up sometime, then fine, but I feel like this is like we can generalize this to general comfortable of discuss. Let's go spinning coming up a few times last few months. Does anyone disagree with that.

J

I think it's a finger issue slightly different like here we are all set. You know we all agreed and maintaining couple disease is. The thing is that next week we'll have to change the ad format. Basically- and you know we're just pushing out these- these quick fix, even though we know for a fact that you know like we'll, have to answer to me. It seems like a bit of wasted effort.

J

That's all as a you know like if there's any chance that we can fix ad format today and push it out the new version, so we don't have to jump to v3 next week, so where's this.

A

Pressure to push it out right now, likewise after I think.

A

Maybe that's the problem like the fact that we are tightly like we wish. We are saying that we are okay with I. Don't like it. Maybe that's not a good quality.

J

Is exactly like the same issue exactly like last I think last release of last two releases two years ago, where they say exactly same issue, fixing necessarily compatibility at the very last.

A

Things that should be in a beliefs may go for aesthetic event. Maybe that could be done like with some planning. So it's not this last week effort and to fix things up like patch this up, because that gets reared as an event is like an emergency and I. Don't I feel like we should be on that stage now, I don't know, Chad was some mess in a comment from point of view on like why we are rushing with.

D

E

Part of the problem is has been a disconnect between the like events and marketing needs with indicating things, but to help remedy that I did it discuss post last week, Asli no I did in a discuss post asking for dates to give us some more lead time. It's a kind of a recurrent problem that we're trying to nip in the bud, but definitely more notice from from marketing and the event site is useful. So sorry,.

C

What was in the releases coming up, this has to be there for the event.

E

Its extensions related stuff for the brochure.

A

So I would argue if that's, if there's a problem with lead time and stuff that that shouldn't impact like development really like, then that's a in terms of oh. So so we wasn't communicated in time right like that's, that's fine! We can get better that, but that doesn't mean that we should rush things. That should mean oh, so so we can't release this release and this way it is that's how I say it, because I feel like it's doing us more harm than good and.

B

Essentially, chad posted that hey, let's it's more uptime with release and then the people who are on the Asia, Roadshow I think is Julian and mentioned that that's what it is that we need to have a release for the roadshow. So it didn't really come from marketing that side that there's there's a push for this release. That's happening right now, I.

C

Mean I: don't really care about the how, but to that point, but like I mean how can we prevent this from being a nation future.

J

Well, one thing is that, for example, like the code should always be realizable at any point and clearly was not because we had so that was I think a code issue like at any point. We should be saying: okay, we can release today if it's in develop theoretically, so I think that's kind of important.

D

Yeah but again we will make it like, essentially that there's one thing that's was yeah: we got better at it, but we can do better, but on the other hand like in any event planning, it would be nice to have some checklists. That says that if there is anything that needs to be released by this event, please communicated- or this please communicate the schedule like it not like a week in advance, because, most probably it wasn't planned that we didn't plan straight. How.

C

Does extensions modify the message ID.

C

So there's no overlap between the message. Id and what's archived for extensions, am I just saying that yes, so.

E

C

Not just delay the message stuff until the next release.

K

Well, it's already in the box.

K

A

It be put under a flag or.

E

C

So to me, sorry, I'm talking I.

C

Mean shouldn't we just like it sounds like if it's already in developed, and we know that the new message message ID is bad shouldn't. We just roll that back and then fix it properly.

K

K

Need one poor request if we decided the way how we discuss to calculate this message, it is fine. I can file this parity one or two hours. That's it. Then we measure it in merely 40 studies. The Bayesian is if we want to have a proper versioning for messages that will require much more time to develop our.

A

K

Time track, but we actually can do this after this for all the stuff you.

B

C

So I mean it seems like we can just go back to the previous message-id as it currently stands, and then we can spend more time implementing versioning and then like redo the PR it for the next release.

K

One point here: all this stuff lead to new message ad, it's kind of related to a slow signing, in the reason why it was changed that we have this immigration on some previous version when we changed message ad and we kind of checked, duplicates messages used in old message ad and new message ad and all the stuff was really slow and was done at the startup of application. So message said you was changed in order to fix this issue.

K

So if we roll roll back all this stuff, we can have all this 40 seconds or minute for signing. Well.

H

A

Feel like this is a liquid developer. What sorry Grutter.

F

I just wanted to add note also to different marketing or or really anybody that comes with ideas right. The problem is not coming up with an idea and sometimes good ideas come late. That's that's a fact of life like you have it, especially with events right, because you have a discussion when you meet people- and you have this great idea right so I, don't think we should ever be trying to hold back the presentation of an idea yeah.

F

But what might happen is that we might say no to an idea and have that freedom to make sure there's yeah yeah.

A

A

Sorry, no exactly that that that cool River is releasing that they can be a gatekeeper and it's a great idea, but that's put a pendant or whatever for quality purposes.

A

Sorry I cut you off, so maybe this this can be a discussion between the people who are familiar with this with details of the code but in general, keep compatibility I, don't know to what extent that the extension stuff is absolutely needed, but Sumida stand figure out the way that we can either flag it or revert to commit or whatever needs to happen, to get released a long time. That does seem reasonable or are there any big.

C

Drama yeah I mean just to add to that. Like I mean if the extension stuff is needed, look everyone knows, status is slow to sign in and they're not gonna, be. It's not gonna, be like a huge change. If it's still slow to sign in for another two weeks so and if they're all new users like they were waiting, act them as much.

D

E

B

Yeah I'm on the fan of backwards compatibility and we're gonna do backwards compatibility. We should do it right. It takes your time to do it and if we can, if it's not necessary to push this out for the extensions that Julie needs for the for the roadshow, then yeah I think would be the best for us to move forward properly on that issue. If we.

E

B

Because there's no people be.

E

Unfinished: okay, no I was just thinking about people who has already migrated. I, don't know if people will be impacted. If we revert this, they will have to recover their.

I

Accounts I imagine I.

D

D

We unfortunately can we should have some freedom.

K

And if we migrated to the new message ad in the next poll, requests include all the stock in the next piece. It will work just fine. So what is the problem with this? I? Don't get yeah.

D

It's actually a good question because just to again make everyone aware, so this pool request conceptually just Etsy. It won another field to the message and that's it. That's essentially shows the IDS for replies, that's how it works.

K

C

Right so the messages will be janky, but nobody will know and then we'll fix it later sounds good.

K

It will not be junk it'll work, just fine I mean for someone who grades from all 931 to the next list. It'll be just fine.

F

Especially if you feature like it also gives you the freedom to roll back a live version like a feature that turned out to be bad. If you keep compatibility, so if all clients support both versions and the new version is that to be bad, you can remove it. It's it's a fantastic freedom to have.

K

Well, for now, that's a bit bigger thing, because we also have versions for database and we can just downgrade application if we waited like database name. Your schema, it's kind of another part which would need to have some changes in other to start to work as you. Why.

D

Should it be a language you can upgrade it with the changes that are undoing the changes that were before you can make a version. That's version 11. With this one field version 12 has two fields and version.

K

Kind of migrations.

D

Yeah but that's a topic about this.

D

D

Don't think it's worth like I think it's the second part of this.

A

Maybe it can be a follow-up discussion, but in terms of looking at the code specifically, but the people are most familiar with, it I think there's general consensus about how to think about these things. For the purpose of this call.

B

We're gonna closes I'd like to bring up one final point: we were looking at 7th of December for okay, ours from different teams and and individuals is everybody moving forward and keeping that in their eyes, like it's a week away? Basically, next Monday.

D

How does it matches with the gun chance and just things in.

C

Yeah I wasn't really aware that we had started okay, our process, yeah.

C

B

Having a feel about that process running so is that now dropped Jared with the new Gantt management structure that you're doing with swarms well,.

C

B

C

The god stuff is like it's a purely separate thing, but like I, didn't I wasn't aware that there was any other chaos things happening at the moment, sir yeah.

B

That was that came out of the whole presentation from from the bill for the for the gamba ha and that's where everybody was tracking, there's multiple notes and and different different versions of people moving towards okay, ours and it I never heard anywhere saw anywhere posted that okay, ours, we're not going to get done. So guess we need some sort of clarity on that. Whether that's part of this, this process or not.

A

Okay, maybe we can talk about this outside call that I feel like it's yeah I wasn't aware to see either I think to some it's not humped and clear. Maybe we could have a person discuss about or talk about it after call, yeah.

B

I think that's fine I think it would be great, would be if Jared and the deal can get together on that, and let us know what it is. That's what's happening because I mean there's, you know.

C

Bertie bingum.

B

Okay, because there was discussed posts and multiple things and I'd been assisting the different teams moving towards zero chaos, and so hadn't really heard when you present at the Town Hall I.

C

Told I told them a bill that, let's not do any other chaos until we understand exactly what we're doing in terms of the next six months in terms of development, so I'm happy to do it, chaos I, quite frankly, I. Don't like the you, a chaos as they currently stand, like none of them were measured and recorded in a central location. So it kind of made the whole thing useless and it was a massive managerial overhead.

B

The consensus on that was to be using github the way that Mozilla did seem to be the consensus that had come. That's where the central repository for okay, ours was going to be okay,.

C

But even if we're talking about okay, ours, like those two, no there's still no direction at all in terms of what we should be doing so.

A

So we almost have time might I suggest we bring this up. We can talk about it. Often so that's I guess just two things. So one is already sort of technical things that people should be aware of things that upcoming and changed anything like any quick announcements, all right, cool and then and just a brief question on sort of time, because I think we drifted. This was anchored in UTC where, as the Town Hall one is one hour ahead is this time. Okay, would people prefer to have one hour later.

E

I would prefer one hour later. It's start it kind of burns in the middle of lunch hour. So if, if it's the same for everyone, I wouldn't mind if it was one hour later.

B

Yeah wistfully.

A

All right cool: let's push it one hour later. Next, one cool thanks, Aaron, um see you in two weeks.