Today's meeting cancelled. I was wondering about myself. Yeah, I'm just writing them on a slack if it's happening today. So, let's see. Good afternoon everyone. Can you hear me? Yes, I can. Hello. Hello. I'm sorry. I forgot about the time completely. I was working on AFJ and I was very deeply focused. Quickly making an agenda, and then we can get started right away. All right. Let's get started. And welcome everyone to the Erasmus JavaScript workgroup call of July 28. I need to remind you to remember to have ledger code of conduct and anti-trust policy. If you would like to add yourself to the tennis list, feel free to do so. I'll just link in the chat. So, yeah, any status updates from the, we had a call two weeks ago. Any status updates you would like to share? There was an Aries working group call yesterday. The discussion mostly focused around some work that's been done on marketing copy. And the results of a survey that we're informing that marketing copy. So, and there were links in the, in the meeting notes to the survey results and to that marketing copy proposals. So if anybody wants to go and look at those. They're available. I think the intent is to make. Apply the changes to the main wiki sooner rather than later. And then iterate on it as necessary to try and get some of the benefit of the rework that's been done. That's number one. And there was also a presentation given on. Aries VCX, which is a library. Written in rust. That uses a whole bunch of the other rust libraries to provide a bunch of the Aries functionality. The intent is not to provide a complete batteries included agent, but rather all of the stuff that you would need to construct one or wallet or something else. Looks like they've made good progress. And there's work underway at the moment to provide great support for Mozilla's ffi project to export or describe all of the rust bindings to their primary API so that they can be made available in other languages. And that's using unify or Yes, I believe so. Okay. Cool. Thank you. Any other updates. The load testing framework. That's under the Aries mediator service. We recently used that to test over 12,000 users simultaneously. Cool. That's the soccer dog. Right. No, that's the load testing underneath the Aries mediator service. I'll drop a link in the chat. Okay. So this is a test year run to to test mediator load and you had 12,000 concurrent open sessions or So this is, it can be used more than just testing mediation has some other tests inside of it such as issuance. We're also working on adding verification workflow to it as well. So this is a test A of J as the client. He's as low as test the orchestrator. Cool. And so the difference with like the the air ice load generator is that this is one is fully focused on mediation. No. It started off with just mediation. We've added issuance into it. We're working on verification flow right now. Okay, cool. And do you know how it's comparison to the areas low generator. The areas low generator my understanding is that it starts up all of the services. The concept here with the areas mediator services it's focused on being a client to an existing infrastructure. Right now the issuance and verification flows focused on an API API end, but I'm sure it could be modified to use any other issuer or verifier as long as the end points updated, because it will contact the issuer and the entire API end points to request the connection and request the issuance or verification. So this is intended to be able to point at some areas infrastructure to be able to determine what its load characteristics are as opposed to the load generator which sparks up its own infrastructure. So primarily I guess to test. That's things don't tip over. I guess that would be the primary difference in the approach. Yeah, the goals to test the structure. That's existing. Okay. Good. Sounds interesting. Any other status updates. All right, I think we can get to the gender. Any other specific topics people would like to discuss on agenda today. Last time we went through a lot of the poor requests. And so, yeah, are there specific topics people would like to discuss otherwise we could maybe do also a quick quick tour and the poor requests again. Yeah, let's do that. I think there's a lot of progress being made. Maybe it's covered in the in the poll requests, Timo, but I would be interested in knowing where the work is in terms of supporting the newest versions of like expo and react native and dependencies and like. Yeah, and so the newest do you mean expo 49 and then or Warren, do you mean like the latest like expo 49 or what is meaning specifically. Yeah, I believe so I think there was work intended to be done to get like beyond react native 68 or 69 and and the related expo versions. I don't recall the exact version of nurse but Okay, yeah, so that work is is completed. And so we haven't tested with the latest expo version, but that came out like, I think two weeks ago or something. But I don't expect too many issues, but we have tested it with like we got it working with the latest versions and bear it did some very complex things that you make. We go to the, for example, the address. repo. So react native. It was mostly with Android, I think. Yeah, so. There's now custom logic for different react native versions. And as you can see it works like we have tested it upwards to zero dot 71. We haven't tested with zero 72 but that's also just came out so I think it should all just work out of the box and everything with auto linking and with an expo project. So if you would like to have an example is the Erdan wallet repo, which has an expo app in here, and that uses. Let me see. It uses react native zero dot 71. It uses the latest areas Oscar release, and it uses if j zero four zero without like native code so I think this this you can use this as an example if you're looking for how to set it up. Does that answer your question or. Yes, that's great. Thank you. Perfect. Yeah, so, and we need to. Yeah, add some more documentation exactly on how to set it up but it should all work. Cool. So, any PR people would like to discuss I haven't had a lot of time to to look at the hours we discussed last time there's some reviews I need to need to leave. Any PR people would like to discuss. Maybe. Then there are some issues we can maybe get some consensus on. One is that started in another PR for some updating of the samples but it's currently like with the rappers that only work in. Or like only in note 18 while we also support note 16 and it adds a lot of complexity is that we make the rappers only support note 18, because they basically already do. And the patched patched rap nappy to those rappers so you don't have to do the custom resolutions anymore. And we update a J to only support note 18 and we drop support for note 16, which is a bit ahead of the end of life which is in September, but I think it would make the setup a lot easier and improve performance so I'm curious if people are. If someone is like against dropping support for note 16. So this will be in zero dot five, because like it would be a breaking chain so zero dot four will keep support for note 16. Then for item. I was only successful in launching the areas workshop demo and as well as running through the tutorials of hyper ledger areas JavaScript by using note 16 on Linux and WSL to Windows Linux. I tried note 18. And it gave me a lot of errors. So I'm not for doing away support for note 16, primarily because of a lot of troubleshooting and blockages that I experienced. Okay. So, have you opened an issue for that or. I have not because I was successful with getting it running on note 16. I can log the issues for note 18. Yeah, if you could do that because usually what we do is when a note version reaches end of life, we will remove support for it. So that would be in September, which is like not that much in the future so if we can get that addressed. That would be great. They're like there may be some issues with the, the Linux sub shell on Windows where it's not working. So are you running it with India CK or with areas Oscar. So I just npm installed based on the tutorials based on documentation, and that didn't work. So it was just using the areas JavaScript online documentation. There was no mention for India Oscar prerequisites. Okay, so are you still on zero dot three. I downloaded the zero dot four zero repository and workshop demo, the one that was hosted last week. And I ran that successfully. But I think the older tutorials might be zero dot three. I don't think it's it was the latest actually because it's based on the documentation online. Okay, yeah. And then I think you're using the latest especially if you also followed it from the workshop. So yeah, then please open an issue. And then we'll take a look and then we'll make sure that that is resolved before we remove support for before we drop support for node 16. It's it's called Windows sub shell for Linux or something right. Yeah, WSL to Okay. What's your username and get that deniker 86 DNA I CK DNA. Okay, you posted in chat. Yes. Okay, any other concerns with dropping support for node 16. Okay. Perfect. So I just have one other comment I guess which is, do we know whether this will create a problem for the bifold for folks who are primary could actually they're not using the node version anyways right they're using react native so I guess it doesn't apply. No, so it doesn't apply. I think we know we I think we just we need to make sure that we set the engine version on only the earth framework slash nodes package and then it shouldn't be an issue. Perfect. All right, there was also discussion on breaking out the demo. I think. Yeah, this, I just need to comment on like something but I think it's not controversial. Are there any other issues people would like to discuss or would like to work on address that we need to discuss. There is a unqualified did migration update this is something that's being discussed in the the errors working group calls to be able to migrate from legacy did to qualify did. We already have a custom implementation that goes from unqualified to get beer one did. And I think we did with this we just have to update all the in all the did peer one did we have migrated from the unqualified did to now did peer two and did peer three did. We did store all the still the legacy did did documents so would be a migration script that we have to write I think we can get that into 0505 zero. That does raise the question on whether we should change the default did peer num algo that is used for creating connections so currently we in the did exchange protocol we use did peer one. Because for did exchange, you need to attach the did documents to to the did exchange message and then sign that problem is with did peer to the three you don't necessarily have a document because you resolve that based on the the did itself. So, and I think we had raised started this discussion in the areas working group call but we never came to a very concrete decision on how do you handle it if you don't have to document should you attach the did document either way so like just to resolve the document and and sign that. So, yeah. Should we change the default did peer method if we add this, or are we going to use did peer one for did exchange and migrate all the legacy. Did to did peer to slash tree. Does anyone have an opinion on this. I guess there would be a need to have agreement across the areas projects. In terms of did it, you know the did exchange, right. I don't know it's a decision we can make in isolation so I'm not sure that I have an opinion on it, but it is still on the agenda within the areas working group and so if we need like it sounds like it's getting time to get serious about finalizing that stuff so maybe you can raise it higher priority on the agenda for the next meeting. So, I think the one thing that isn't currently talked about and that's the, like the, the did exchange protocol, not having very clearly defined how to use non did peer one did so, whether it's public dates or like documents that you can resolve based on the, or did documents that you can resolve based on the did. I think there's maybe an issue opening RSRFC. And there is the, let me see. There is a legacy did this one. Yeah. This repo is there I think the idea is now to migrate this transformation script to go from like a legacy did to a did bear to, and I think Stephen added support for did bear three. I think with that we are mostly there in having the. Yeah, the, the process to find. So I guess that then comes down to do we want to go with the most recent SPAC, or do we want to go with something that might achieve lighter compatibility with folks who haven't gone there yet. I don't know. Yeah. So I think what they are suggesting also in the community coordinated updates is that you need to support. Let me see. Yeah, I think because it's a community coordinated update there will be quite a long period process where we see rework to step one step one is so I think what a step one here I think it's to support. Okay, first. Okay, so we need to agent bill must update or agent code basis and deployments to accept into all unqualified and new forms. During this step. Agent must continue to unqualified. Yeah, so what I'm uncertain about is that it says it should that agent builders must update all agent code base and deployments to use only fully qualified digital communication. And also include the connection protocol because in that case. It probably going to be very complex because like it has been implemented a few years ago, like it's very it uses an old way of structuring and the document well did bear to uses a new one. Currently, how we implemented an AFJ is we use just to unqualified exchange and then internally we translate it into a qualified identifier and use that. Well, I think this is just thing. I think we need to use deep peer to or deep peer tree everywhere, even in creating a connection for example. Is anyone involved in the discussions chair and know more about this or I've only been peripherally involved and so I don't feel equipped to like make any definitive statements about this. It seems to have been driven more by Stephen Curran and Sam. I'll leave a comment on this PR with these questions then. Yeah, it should be quite easy for us to to follow whatever is is described here and get that implemented while still supporting the the old ways of doing things without breaking backwards compatibility, because I don't think we should. Like, I don't think it's like if we do this like updating everything to use only fully qualified did it means we're going to break so much backwards compatibility with all implementations that have been made over the years and maybe are not going to adopt this. So it would be good if we can have a bit more of a like gradual a if you support qualified let's do that otherwise will keep using the unqualified ones directly. Are there any other feature issues people would like to to discuss here or rates. Okay, then I think we can just cut the meeting short for today. And we can. Yeah, continue with work on PR and issues. One thing. I do want to highlight is. I see your and mute. Do you want to say something or. Yeah, yeah. Good catch. I just wanted to raise my hand. Yeah, you were first. Yeah, I have a question. We don't have to discuss it. Now, but about it's it's about the migration to the AFJ like, like two new libraries of scar BDR and on grits. Is there any any documentation about that and a and a. A description about about some pain points or or like tricky part which we should be aware of. So, there is the migrating from zero three to zero four. Which introduced to break and changes, and they're good. Listen, migrating from in the SDK wallet to a risk Oscar. So, that's there. One thing that we haven't documented farewell is the migration from in the SDK to in the FDR, or in the SDK to on credits arrest so like the changes in the API are covered here. So, like that you now have to register on credits module but they should see this still uses the in the SDK module here. But there is in the agent setup it does define like okay how do you use the, the in the FDR module and configure it with the different ledgers. So, that's the documentation there is. And it's no specific like these are pain points or something to be aware of. Okay, yeah sounds good sounds good. I, I, I, I know that the, actually, I asked the baron or like Ariel on the on their presentation about the FJ for version zero four zero point four about this and my question was, was, if, like, if if we should migrate everything at once, or if there is specific process, if there is better, if there is some some process which might be better. And what I mean is that we have like zero point three right now with in the SDK, right so now it's a question like, I remember that Baron said that it should be maybe better to do everything at once. But I think that he also mentioned some that there are some issues probably with some part but I don't remember that that that what what exactly do you have, do you have any, do you know anything about that or. I think we have done mostly everything at once, also what we did in the bifold and some other projects we are just doing it all at once because we would like to get rid of the in the SDK as soon as possible. You can do it in two steps like you could do first and upgrade to zero four and use the in the SDK still, and then at another point you could do the upgrade to errors Oscar, for example, when zero five releases or whenever you're ready for it so it are two separate migrations you can do if you haven't just chosen to do it at once. If you don't have in the SDK wallet to migrate yet. So, haven't released your wallet to the stores for example, I would definitely recommend to do it all at once because then you don't have to do the in the SDK to Oscar migration, because that does require. Like we have to do this in the, in the bifold wallet, and it does require you to have like a custom package you need to on every agent started basically you need to do a check like okay what's our previously in the SDK wallet, if so I now need to migrate it and do that to an Oscar structure because like the database is completely different so we really have like to make a connection to the postgres database, create new tables, move the structure decrypt everything re encrypt so like if you can get away with not having this package. Yeah, I would say sure do it all at once. In our case we have it already out there so it's it's already in production we have we already we already did the migration from the VCX library to FJ as you know but there was also not only it was also not only about like frameworks, but also our data so we already did this migration in the SDK. Yeah and now it seems as we will have to do this migration with those libraries but I think it's great that there, if there is some. Let's call it script right to do this migration. Yeah, that's definitely great so I hope that it should be fine. But it's not that complex I can send you the. I think it's the implementation from the bifold wallet. See. Yeah, so. Basically, this is it. In the SDK, is it migrated to Oscar and if not there's a custom method implementation here that calls this in the SDK to Oscar migration update. Okay, cool, cool, that's great. Thanks. Yeah, I seem to recall so so two things one another thing that came up in the Aries call yesterday is that Stephen current is pushing towards officially deprecating in the SDK. And they'd like to do it sooner rather than later. And so is is trying to rally everybody to do that so just as a point of interest is that the wants to move and the SDK to archive to state as soon as possible. So I don't know whether that goes into your decision about your migration path and the and the like just so you know that's happening and if you have concerns with that then you should chime in and get in touch with Stephen and you know, let him know what your concerns are. And the other thing, the only thing I seem to recall as being an issue and it may have been resolved but with the migration was if with AFJ and ask our was if you were using multi tenant. I think there was that that's not supported in the current migration but I might be incorrect about that. So I just wanted to bring that up as a question in case that's something that is germane here. It isn't implemented yet. Like we need to do proper migrations for multi Tennessee needs to be implemented still anyway, it is something we are going to implement because we are using multi Tennessee with AFJ in zero for zero. I haven't written the migration for multi Tennessee and no just completely yet for Oscar is because we don't know anyone that is using and it's multi Tennessee in production. And so I added to like the docs and everything there's some warnings in like hey multi Tennessee is not supported. If you need it, please open an issue. But I don't didn't want to go through all the trouble and complexity if nobody is ever going to need it. Yeah, so if you are using multi Tennessee are on zero three within the SDK and you are in production and need to migrate it to Oscar then please open an issue and then we can look at getting that implemented. But for example we have mediators running with in the SDK in zero three and we have successfully migrated those to zero for and updating in the two Oscar. So for that use case. Yeah, it works fine but yeah you're right that that is not implemented that or that deprecating the in the UK might be a good one to discuss also. I'm in favor of it. I think it adds complexity to this project to also have to support it. And the installation is like very cumbersome also for newcomers. So, yeah, I'm totally on board with deprecating the in the SDK. Maybe what we do is already start adding notes to like we have for. We have in the, like experimental modules we have warnings like hey this is experimental, maybe we could also start adding like hey this is going to be deprecated. And then maybe we say we remove support for in the SDK in either zero five, but maybe we should set it for zero six release so people can still do one more upgrade with the in the SDK to zero five, but then in zeros dot six, we will remove support for the in the SDK. And if people are really interested in keeping support for 10 that would still be possible because like it's currently there's no logic in core to support in the SDK but I would then suggest that from zero six onwards we remove it out of the the errors from JavaScript repository and it could be like a custom maintained implementation outside of it if you really need in the SDK, but then. Yeah, I think that would provide the clear migration path. Kim. Yeah, if you have a clear migration path here it'd be good to let Steven know kind of the timeline, because one of the things that came up was removing some of the build artifacts from the repositories to encourage no longer using in the SDK and so having a timeline on that would be helpful for Steven to know when a good time would be to remove those build artifacts from various repositories. Yeah, and so build artifacts because I think we're moving built artifacts can mean that current deployments can break. Is that something we want. I think my preferred approach would more likely be to like not update it anymore so if you have like an older deployment it doesn't suddenly break. The concern there is deploying artifacts that aren't maintained anymore. So if there's security holds or things like that and so at some point. Having the artifacts deployed out there can be more of a liability than they are a benefit to anyone. Yeah, that makes sense. I think the thing that would require some communication with Steven then is about a prospective plan for, you know, you mentioned perhaps, you know, deprecate putting in deprecation warnings and removing support in 050 or maybe in 060. So if we had an idea of, you know what what you would desire to do there and what the timelines are, you know, at best guess at that point for this release, then that could inform some of the other stuff that that Steven and others are doing to try and wrangle the in the SDK to the ground to make sure we're coordinated on that stuff. Yeah. Yeah, it makes sense. Are people any people here that are using in the escape and don't intend to upgrade to Oscar and related libraries for zero five, or even zero six. Well, that's positive at least cool. And then final notice I think also mentioned this last time already, I'm not 100% sure, because it's two weeks ago already. And application in between so I wiped all my memory from before. And that's that we wanted to switch hosting the AFJ call to being bi-weekly, because there is like with grants, things that are happening I think having a bi-weekly call would be good enough. But if they're, well, in the future again arises like so much to discuss that we can do it in in the bi-weekly call then we can always go back to having weekly calls but I think a lot of the stuff can also be picked up in issues and pull requests. There are people against that here today that that would like to keep it at a weekly call people that are agreeing after bi-weekly call or have any opinions notes on this. I think it definitely makes sense during the summer occasions right. Maybe let's see again on in September or in autumn. So does it mean that we would skip next week and do it in two weeks again. Another call would be like in two weeks from now. Yeah, exactly. Okay, good. Okay, I think. Sorry, I just this is my first meeting. And I thoroughly enjoyed it. There's a lot of insight. And I'm a bit sad and if it goes to sort of further away further away from, you know, the consistency bi-weekly is it every two times a week or then twice every second week. Yeah, so it would be once every two weeks, two times a month basically. Because I've been away. I haven't, I was so desperately looking to be more involved in the community. And this is my first meeting and I, you know, thoroughly enjoyed it. So it'll be a bit sad on my part. Okay. Yeah. No, that's good to know. I think yeah. I, we have done it like for weekly, I think for a really long time already I think at first was bi-weekly. I just think with the conversations we have lately. Maybe it's something for the summer months. And then we can always reconsider it after the summer months. Or if there are enough topics to do it weekly. That would also be fine by me, but I think we can also. Yeah, we should have probably some more like we have in the past looked at a bit like doing alternating weeks of having a maintainers and a user's call, basically where the week will be really focused on in-depth discussions on the implementation. The other one would be more focused on the user side of things, having people give presentations on what have they built with AFJ, what can you do with it more from a user perspective. I think that's one of the things that I haven't had a lot of time lately to prepare well for the working group calls. And I think that's also one of the reasons why I would like to move it more to a bi-weekly call. Because yeah, having people to present on these things with presentations and everything I think that helps in making it a more well, a better working group call. I have also discussed a bit with Jakub and Ariel and Karim and Berend and asked to maybe do it a bit more in alternating fashion where we host the working group calls. I think that that could maybe also help a bit. But yeah, I'll definitely take it into account. I would like to propose for now to at least for the summer do it bi-weekly. And then as Jakub said, after the summer we can reconsider to see like what's the interest and do we want to make it weekly or bi-weekly. Yeah. And so if you have topics you would like to present or talk about on the Airstream just call presentation or something like that. Also please yeah, raise that to us. And then we can have those on the working group calls. Or unmute it. Yeah, I just wanted to say I think that the, you know, the cadence of the calls doesn't matter personally to me as as much one way or the one way or the other. But I will say that I think the last few months have been very busy for the project because there's been so much both refactoring of the framework. It's done pretty well as a lot of rework due to moving to shared components. And those two things have taken a lot of coordination and I think have needed the cadence of the calls to to maintain the velocity and coordinate those complex activities and so I'd like to pass on some congratulations I think to the group to for managing that like that's a very complicated set of things to to get to and deliver and I think it was done pretty well. And for the next little while it, you know, people need a break from that and there's a lot more, you know, independent work that can happen that doesn't require as much coordination than, you know, perhaps less regular calls might be might be appropriate you know, community will take that into account but I certainly do appreciate the amount of work that's been, you know, and the amount of coordination that's happened to happen over the last few months it's been pretty intense. Cool, thanks. Yeah, I think what you may what you say makes sense. Like there's been less activity in the last weeks and so after the a lot of the refactoring and that makes up that we have less to discuss yes. Okay, then let's just keep it biweekly for now but always keep it open, like we can have it more often when needed. I'll communicate this with Brian. And then we're out of time filter our nicely. Thanks everyone, and then we won't have to meeting next week, but we will have it the one after. Yeah, I need to think. Yeah, I'll be still yeah I'm going on vacation but the week after that so in two weeks I will be here with you. Thanks everyone. Thank you.


Hello, I am Kazuenishi and I attended LAYSF last year, but it wouldn't be possible with a proud funding campaign so I am here to give you some tips. First of all, you have to make a poster with a nice art and post on Instagram, Twitter, social medias in general and you have to convince the person reading about your story, how much you deserve to attend LAYSF and things like that. The second tip is there are many sites where you can raise money but find the one with the lowest fees. The third tip is don't shy. You have to tag big page and also famous people with big visibility. The fourth tip is try to read some news, local news and tell your story, tell again how much you deserve to be on LAYSF and if they have interest in sharing your story, it would be a huge help. The fifth tip is try to find a sponsor. For example, a local business. You can try to negotiate with them, like if you are presenting on Bazaar Day you can try to print their brand on your poster in exchange they will give you the tickets to LAYSF or part of the fee, something like that. And my last tip is keep yourself motivated. Some days you won't receive a donation and that's fine but you cannot get idle. Keep sharing your campaign every day. Well, that's it. Do not give up on LAYSF because it's a great opportunity and if you follow the tips, you for sure will be successful. Good luck.


Alright thank you everybody. So our next speakers are from NIST, which is the National Institute of Standards and Technology. These are the folks who help set national standards for a whole host of things, in this case elections. And so we've got both Mary Brady, who's the voting program manager, and works on voting specific standards and things like that. And Josh Franklin, who is a security engineer at NIST and works on security related things, including voting. And with that, I'll turn it over to you guys. Thank you everybody.  But I just want to say thanks to the organizing committee for inviting us to give this presentation. I'm really not going to say much other than I'm really excited to be here. I'm looking for meaningful ways to engage with the cybersecurity experts here. Josh will talk a little bit about some public working groups that we've established at NIST, one of them on cybersecurity. Some of you I know are already members of that group who we sure could use a lot more help. I'd be interested in some of your thoughts about meaningful ways in which we can engage with the community. And we're here to tell you a little bit about the work that we're doing, get some feedback from you, and look for ways to learn from the community. With that, let me hand it all over to Josh. I guess I'll roam. Yeah, born to roam. Howdy everyone. My name is Joshua Franklin. Welcome to Hacker Summer Camp. It's been fun so far. Today I'm going to talk a little bit about my experiences in the election community for the past 10, 12 years. A little bit about how we got here, where we are going. First off, I'm going to start with this slide. There was a man named Dr. Joseph Harris back in 1934. And he was basically looking at how elections are run in the U.S. back then. And he actually found these various election fraud types, as he called them. And it's really interesting looking at this list because we're still really, really worried about many of these issues today. We have since 1934 learned a little bit about how computers work and we've introduced e-voting. And what we've really seen is that now we have these same issues, but also modern electronic analogs to some of these same things. And so keep these in the back of your mind as we go through some of this. So who am I? Josh Franklin, IT security engineer at NIST. I typically do enterprise mobility LTE security. I also do electronic voting. I've been in this area since probably 2004 working in voting off and on. I currently co-chair the NIST EAC election cybersecurity working group. Prior to NIST, I was working at the U.S. election assistance commission helping to test and certify voting systems. I got to travel the U.S. and really understand what the elections landscape looks like there. Previous to that, I was working at KSU's center for election systems in Georgia. Learned a lot of things there. Helped install and maintain probably 22,000 voting systems there. I have been a poll worker in more states than anyone I think has. And I will keep saying that until someone proves me otherwise. So yeah. And I have an AM master's in infosec from Mason. So, you know, get to know an agency.  Believe it or not, the federal election commission has little to no role to play here. They are primarily focused on campaign finance law. The election assistance commission is what you really want to be looking at here. They are charged with providing assistance to local election officials, adopting the voluntary voting system guidelines, and running a testing and certification program for U.S. voting machines. NIST is in this space. We provide the scientific and engineering backing for the voluntary voting system guidelines. DHS is a brand new entrant into this area.  And then, of course, the good old FBI, they essentially prosecute domestic election crimes. At the state level, you have the Secretary of State's Office. They are primarily the lead election officer, first and foremost, deciding how elections are run in their given state or territory. They are typically third in line in a session in a state, so it's a fairly powerful elected position. And then, at the local level, this is where basically elections are actually run.  So, a little bit blurry. That wasn't just my pencil. On the right side, we actually have, you know, the voting machines that we all know and love. DREs, Opscans, ballot marking devices. These are the voting systems that are actually in the voting hacking village. I was planning on pointing at them right now, but they're not here. So, we have, in the top right, we have DREs. These are, you know, basically voting systems that store ballot selections electronically. We have optical scan systems, which, you know, read paper ballot selections, typically scantron machines, but, you know, modern ones are actually using computer vision algorithms to, you know, figure out what's a, you know, what's a vote.  These are a nice hybrid between the two systems. They actually have a touch screen interface, extremely usable, but they also have nice security properties of, you know, actually printing out a paper ballot. On the left side are basically all these other supporting election systems. These are things that there are not really best practices and guidelines and standards about, but they're actually, you know, they're very, very instrumental in the election process. You have, you know, local and online voter registration systems, electronic poll books. These are the things that you'll, you know, check in with at your polling place. You have candidate filing systems. If you're going to, you know, run for governor, you have to file your information with your state at these candidate filing systems. There's, you know, also ballot tracking. There's poll worker tracking. There's just a whole slew of other supporting election systems. Here you also have, you know, campaign voter information databases.  And they're actually holding a lot of really interesting information about all of us. And so when we're, you know, thinking about securing the election ecosystem, we actually need to have a larger pallet there. This is just for people reading these slides later. Cool. So, map plays is right.  Previously, we had a threat, a threat model that would, you know, well, at least election officials did. There was a threat, a threat model about, you know, physically proximate attackers. In terms of intelligent adversaries, they're extremely worried about poll workers. Poll workers are the, are, you know, one of the, the nation's largest temporary workforces. And, you know, poll workers aren't necessarily vetted. They, you know, to the, to the degree that, that you would want. They often have privileged system access passwords, and they have time to actually play around with these systems. Election officials are also extremely worried about accidental errors and, you know, events such as that. These are the things that more often than not will actually lead to an election, sorry, to an incorrect election outcome. So, elections officials are extremely worried about accidental errors. Natural disasters such as the 2012 Hurricane Sandy, I think it was 2012, that happened on the, you know, east coast. Definitely affected elections there. And just, you know, any real event that would, that would impact public confidence and trust in the election system. But since 2016, we, you know, we got the intelligence community report about, you know, meddling in our, in our elections. And what we're, you know, what we actually have evidence of now is basically nation state attackers, you know, hitting our election systems. We haven't yet seen attacks against vote capture and tab, tab, and tabulation systems. At least, you know, documented by the IC. But, yeah, we also saw issues of fishing of both election officials and voting system vendors. And the new threat model is really everything in the old threat model plus cyber, right? Yeah, so what are these voting systems actually look like? They are, you know, embedded legacy systems. That's how I would, you know, talk to someone about them today. They are typically running some UNIX or Linux variant. They might have a, a custom kernel for some reason. Some of them are, you know, running Windows CE 3.0. That's what was run in Georgia when I was there. Some of them have really old, you know, and pro, pro proprietary physical media. I am 30. I should not, like, I should not know what a PCM CIA card is, but I do. You know, that, you know, that could be a, a problem there. You know, so net, net, networking, wireless is a fairly common phenomenon. Infrared, Bluetooth, Wi-Fi, cellular. Those are definitely things deployed in US voting systems. And these, and these things are basically needed to last for a long time. Many states are still using systems purchased in 2002, and there's not really a clear upgrade path there. And these, and these systems really receive one to five updates over that whole lifetime. And these, you know, these updates are extremely expensive when they have to update. I, like, for my first real, you know, job when I wasn't a student assistant anymore at KSU, I was, you know, basically made to go and physically insert a, a PCM CIA card into 6,000 touch screen units across the state of Georgia to update an expired X.509 cert. Yeah, and it was, it was really interesting. I got some, I got some stories from that. I'll just, I'll just, I'll just say that. So, you know, now that we've talked about what these, you know, well, what these systems actually look like, what sort of issues have we seen previously? You can, you can look at some of the sources for our results at the very back of this. I will, I will tweet out these slides after this, after this presentation. But, you know, Barbara and David were, you know, talking about these independent reviews that we saw of these, you know, of U.S. voting systems. And it's really 15 to 20 independent reviews since probably 2004. So it's actually not a lot of outside scrutiny. And what, what NIST did recently is that we went through all these different papers, did a, you know, a literature review and looked at some of the, the, the, the various issues there and we then mapped them to common weakness enumeration types which are basically a standard for software bug types, go figure NIST like standards, right? And so these were the, these were the top five software bug types that we saw. These were fairly common issues, I would say very, very common issues in the, in the, in the papers that we re-viewed. And then just to, you know, up-level them a little bit, we basically saw a lot of input validation issues, you know, crypto and authentication. So it's, you know, everything's not on fire, right? There are, you know, good things happening in the, the voting arena. Risk limiting audits. These have been really, I would, you know, go as far to say that this is the, you know, single best innovation we've had in election security since the year 2000. These are really meaningful, statistical audits that are fairly efficient. They can be very, very practical and they don't have to be extremely expensive. And so they can give an election official pretty good confidence in the election outcome without spending tons of money and time. Software independence. This is a concept championed in 2007, 2008, basically meaning that a, a bug in the software can't affect the election outcome. There's a, there's a better way to say it. But in practically right now, this means paper, you know, paper, paper voting systems. But this is the up-level concept that's, you know, more, more what desirable characteristics do we actually need in voting, in voting systems? There are pro-posals for come, come a completely software independent, fully electronic voting systems. These are called ETE verifiable cryptographic protocols. These are really cool systems that have not really been used on large scales yet, but they, they essentially give a voter a receipt that guarantees them that their, that their vote was included in the final, in the final tally, but they can't sell their vote with that receipt. So it's really cool. Essentially domains be civic crypto. These things have been, they've been used in Cuma Park, Maryland and a couple of other places. There's definitely arguing about what, you know, what constitutes this type of system. But it's definitely a, a, you know, really interesting research area and a potential path forward. And then finally, recognition of usability as a security issue is a big, big problem. Well, it, it, it's sort of a new thing in that, you know, the community finally said, well, you know what, if it's not, you know, if it's not usable, availability drops to zero. And that can definitely affect the outcome, well, at least the, the security of the voting system. And so NIST really likes software end of, end the, uh, pendants. We are including it in our, you know, recommendations for, uh, you know, principles and guidelines for voting systems. Um, but, you know, paper itself is not a panacea in elections. Um, there are a, a number of, uh, physical security oriented issues that can really affect the election outcome. Um, you know, paper primarily gives you tamper detection and, and auditability, which is awesome. That's super, super great. Uh, but, you know, paper can be modified.  And if there's not a, a filled in, you know, bubble fill in that, uh, you know, fill in that bubble real, real fast.  Um, seals and chain of custody need to be, uh, verified. If you're not going to actually look at the paper trail, why have it? Um, there's, there's routine, you know, meaningful audits need to be per, per formed. You can't just have paper. You have to actually do something with it. Um, then, you know, just generally, we need to, you know, up the, the, uh, the, uh, level of, of cyber hygiene in this area. Looks like I'm doing pretty good on time. Okay. Um, testing and cert, certification. What does this process look like? Um, basically the election assistance commission runs a, uh, a, uh, testing and certification program for voting systems. There are, uh, there are multiple layers of testing and certification. Uh, the, the EAC performs a, uh, a federal cert, certification and then states do their own testing for, you know, their own needs.  It's like the, uh, the, uh, Pennsylvania cross vote is what people call it. And there's just, you know, tons of state specific voting logic issues that states are testing for. Um, what does this actually look like? Um, this is, you know, at a, at, at a, at a high level, uh, you know, vendors submit an application to be tested. Uh, the EAC, a, a third party lab and then the menu factures sit down. They figure out, uh, they essentially a testing contract. That's a test plan. Testing occurs. Uh, if there are issues, which, you know, I've never seen a testing campaign that, you know, doesn't have at least one issue. Uh, the, you know, vendor goes back, makes a change and then it gets tested again. Uh, ad, you know, ad nauseam. Um, at, at the end of the testing process, there's a test report. The EAC then says, yes, I would like to, um, you know, certify or no, I don't want to certify. If they do certify, uh, then you know, then a, a voting system goes into their quality monitoring program where states and labs and menu factures and everyone gives EAC information about how that per, per performance, uh, uh, how that system is performing in the, the, uh, field. Um, yeah, I'm gonna go back a slide for a second and say, uh, if you're really interested in, you know, knowing more technical information about voting systems, EAC.gov is literally the best place. They have a, a test plan and test reports section, uh, and they have, uh, information on new voting systems that aren't really out there yet. A lot of the systems that, you know, EAC has, has certified, uh, at least to the, to the newer standards, um, aren't necessarily deployed in the, uh, field yet or if they are there, you know, it's only in limited, limited areas. Um, but this is an excellent, excellent resource that they're, you know, doing a serious boon for this community. Um, in terms of voting standards, uh, the voluntary voting system guidelines, it's an awesome name for a standard, right? VVSG, um, uh, these, uh, standards are pri, are, are primarily for vote capture and tab, uh, and, uh, and, uh, tabulation systems. So nothing about voter registration, nothing about electronic poll books, election night reporting. Um, there is no federal law mandating that every system, uh, come, come, uh, apply with these standards. They're just, they're just isn't. Uh, the way elections work in the US is that it's, you know, typically, uh, the, you know, time and manner of choosing is left open to states. And so that's the same here in that, uh, you know, states can use, uh, come completely federally certified systems, uh, systems that are only, you know, partially certified. Uh, there are, you know, there's tons of variations out there. Um, in terms of security, um, well, just in, in general, uh, these are the, you know, various voting standards as I, as I see them. Uh, the 1990 VSS in 2002 voting system standards, these, these things were made, uh, not necessarily by the federal government. Um, uh, and, uh, it wasn't until the, um, the election assistance commission was created in 02, I think, that, um, that, you know, we actually got the modern VVSG. The modern VVSG has a whole section on, uh, security. Um, didn't really even have that previously that much. Um, uh, and there's been large changes in security as, uh, as new, uh, standards have been made. But, uh, most systems in, in, in the U.S. are still certified to the 2002 VSS or 2005 VVSG and it's mostly 2002 VSS. Um, but yeah, uh, in, in 2007, NIST made some recommendations for, uh, you know, for, uh, next generation voting systems. There was, uh, like a really robust, uh, security architecture that was recommended because of some various issues such as software independence pen, pen, pen, pen, uh, penetration testing. Those were not, uh, eventually, uh, adopted. Um, and so what, uh, what folks did is they took parts out of the 2007 and parts out of the 2005, smushed them together. They got the 2015. Um, and so yeah, that's the most recently adopted standard.  Uh, and we're, you know, putting together these next generation re, uh, requirements. Um, this, you know, this new, uh, structure is gonna have principles, guidelines, requirements and test assertions. Principles and, and guidelines are ultimately gonna be what's, what's adopted by the federal government and then re, the requirements and test assertions are going to be, um, a little more malleable, uh, because what we've really, uh, what we've really seen is that, um, you know, there's just been a lot of changes and sometimes folks get really, uh, locked into certain requirements and it doesn't really help to be locked into requirements from five or ten years ago. Um, from a security perspective, I am, you know, I'm co-chairing this, uh, this working group on, uh, you know, in this, in this area. Um, these are the seven high level principles that we have, um, listed. Each of these has a number of, you know, sub guidelines. They're all available at the, uh, at the NIST and EAC voting, Twickey. Um, uh, uh, a couple of things I'll sort of, uh, point out under audit, you know, under auditability, which is the single most important principle that the whole group felt really, really strongly about. Uh, software independence is included under, under, uh, uh, under that. Um, under access control. We have things like, you know, two factor authentication for privileged election operations, uh, for data protection. We have, um, you know, using well, uh, well vetted publicly available, you know, in standardized crypto, which is really, really nice. Um, for software integrity, which we're changing to system integrity, uh, we have, you know, things like only digitally signed code can actually run on a, uh, on a voting system. If you want to talk about these later, I'll be, I'll be, I'll be around. Um, so just to, you know, before we get to questions and stuff, um, these are some of the big things that I think really need to be addressed. Um, we need routine meaningful audits. Uh, I think that is a really important, uh, concept that needs to be enshrined here. Um, we need regular external scrutiny of voting systems. Uh, it is absolutely key. Uh, you know, the more folks who can, uh, take a look at these, I am of the opinion, the better. Um, but when folks do find issues, uh, that needs to be responsible vulnerability disclosure, um, do not release as freaking zero day a week before the, the election. Uh, just don't, don't, you know, um, there are, uh, you know, there are well-known, well, I mean, essentially if you have issues, uh, if you find an issue, uh, talk to the EAC, talk to, to DHS. And yes, if you want to make my, you know, Monday morning bad, you can send it to me too. Um, that's perfectly fine. Um, so I think that we need to augment how we, you know, really manage elections, uh, security. Um, I think risk assessment, threat, modeling, contingency planning need to be common terms for, for elections officials.  Um, voting systems need regular software updates just like, just like anything. Um, we need to figure out how to get voting systems regular software updates. Uh, I think it is untenable to have voting, uh, voting systems with, you know, CVSS, uh, score 10, right?  We need to, to find a way how to fix that. Um, and then election officials need actionable guidance. You can't just go yell at them and say, do this, do this. Um, that's not really going to help any, you know, any, any, uh, body. Um, they need to, uh, you know, like, they need guidance in the language that they speak. Um, and so you have to help speak their, their, uh, their language. Uh, they are typically not, uh, cyber security experts.  They do really complex operation and everything's all happening at one, at one time. Um, then to finally, you know, I'll, I'll basically stop here. Um, so help make a, a, uh, difference. Many of you came, uh, means that you seem to at least care a little bit. Um, go, like, register and actually vote. Uh, don't let apathy hurt the overall system. Uh, be a poll worker. Um, this is extremely important. Um, uh, it will really change how you look at elections. Uh, and this is how you can affect change in your local area. And local elections are the elections that will actually have an impact in your, in your, in your life in a fairly large way, fairly quickly. Um, work with your election official, not against them. Don't antagonize them. Help out. Be a force for good. Uh, and then just completely in a self-serving manner, join these public working groups. Uh, we're fairly nice people. Um, yeah. So, uh, uh, thanks everyone. Uh, Mary and I are here for questions. Yeah, definitely. Uh, yeah. So the, uh, the question was, uh, you mentioned joining public working groups to help local election officials. If you could tell us how to access those. So are you, are you bringing up the reference? So the, um, there's a set of seven, um, working groups. There's three election groups. It's for pre-election election, post-election. And there's four, uh, we call them constituency groups because they're just sort of help support the elections. But they're, uh, you in fact are so usability, accessibility, cybersecurity, interoperability, where a lot of, uh, a lot of the common data format work is being played out and testing. So you can, uh, follow a length that maybe is not coming up or the easy way. The easy way would be to go, go to vote.ness.gov. And there's a link off of that page to, to the working groups, uh, to the, the Twiki itself. And on there there's information about how to set up an account and how to, uh, to actually, uh, uh, join the mailing lists.  And if you have any questions, just ask us. Yeah, definitely. I'll, uh, tweak them out in a moment. Yeah, I was gonna say, on the Twitter. Cool. Yeah. So how are you addressing resiliency in terms of just, uh, maintainability and, and, and continued function as a security threat, uh, in how you're setting up the standards or how you're looking at these things? Because it seems like there's a bigger threat from DDoS by device failure in elections than there is from actual tampering with machines. Uh, we encountered a lot of that in the last election in Maryland where many of the optical scanners died during the election and there were, and votes were left piled up and in some cases unattended while voting machines were on, were the scanners weren't working. So how do we address the actual, uh, ease of operation and continued use, uh, as part of the security model and putting these standards together? Yeah, that's a great question. Um, so, uh, we do have a maintainability-oriented principle that is, you know, going to be in, you know, it, uh, like, we only saw seven of the actual principles. There's a whole list of other principles as, as, uh, as well.  Um, there are, uh, you know, programs that the EAC has, you know, looking into quality assurance areas. But some of that is going to be on the election official themselves, um, to make sure that they're taking, uh, you know, good care of their, of, of their election system.     Um, yeah, it, that's a, you know, resiliency and maintain a, you know, maintain ability are really important questions. Um, I, somehow these systems are still working for the most part, uh, since 2002. Always kind of, yeah, it is kind of amazing. I hope that helps. Uh, thank you very much. Two very quick questions. Number one, are any of the efforts to update the VVSG going to take into account not just voting systems, but also non-voting systems? Uh, no. Okay. Um, is EAC planning to address that issue as well? So the databases and the election management systems and, is NIST? And then, um, uh, to the extent that a lot of people, a lot of counties just aren't going to be able to replace their machines, is the problem that we cannot technically update these software systems or is the problem that we just don't do it? Yeah, I mean, yeah, there's there, yeah, updating voting system software. I mean, it is, so we, it costs sometimes over a million dollars to get a voting system certified. Yes. And so if even one software update occurs, um, then there needs to be, uh, a new cert, cert, certification process. Now the, you know, second layer cert, certification process, that second order process doesn't have to be a full million dollar process. Typically it can be really, really small. I think that the, that the EAC has gotten those done in like two or three months, uh, in my, in my experience. Um, but then a local election officials would have to pay for those software updates, typically.  I mean, uh, that's a very common thing and just elections aren't the most well funded, uh, operations. Let me just add a little bit to that. Um, I, the EAC, uh, prior to embarking on this effort to update the voluntary voting system standards, uh, led a group of, uh, led a group of folks that came up with some principles moving forward, not to be confused with the principles and guidelines. And, you know, one, one of the areas that, uh, they really do want to figure out, you know, what to do about is, how can we, you know, update this software? So, so it's in our minds. Uh, we, we don't yet have a solution because it's, you know, we really sort of have to look at the testing process and, and how it would feed into the testing process and how much it would cost and you know, like, how can this all work? So, if you have ideas, we're, we're certainly, you know. The voting is the, is the, um, domain of the states by constitution. Um, um, so the best that NIST can do is to set standards, correct? Is to set a standard and then the federal government can provide to the states money to assist the voting, um, system, correct? Um, am I talking into the mic? Okay. Okay. Okay. Okay. I just wanted to ask though, um, you may not want to be speaking for on behalf of NIST, but could you sort of share with us what your ideal voting system would be given the constitution, the way that the state, the voting works in this country, and also, um, part two of that may be not speaking for NIST again. Do you think that there has been widespread, uh, voter fraud, register, voter registration fraud? Okay. Uh, so for my ideal voting system, I might have to say I'll see you after class, uh, because that hasn't been approved by NIST management. Um, happy to talk to you out there, right? Okay. So, it was a multi-part question. Now, you're absolutely right. I mean, it's up to the states to determine whether or not they want to adopt the VVSG, and this is normally handled, uh, within the legislation, within the state legislature. So, some states, you know, require certification to, uh, require the use of certified systems. Some require, uh, the use of, uh, systems that are certified by a lab, but not necessarily by EAC, that are tested by a lab and certified, but not necessarily by the EAC. Some require you to, um, the certification to the VVSG, and they might grind their own state-sponsored programs, uh, to do that. So, you're absolutely right. We can set the standards, you know, but, you know, but we can't necessarily impose them, uh, you know, on the states. Uh, I'm not really sure what to say about my ideal voting system, because nothing's been approved by my management either, and I don't, I, I can't really comment on, on voter fraud. I mean, it's not, we're sort of kind of outside our, our area of expertise and what the things that we look at. The states are not required to use them. If the states don't have to do anything, why does it matter at all, and how can we force them to have some model of the time, so it's at least the baseline? So, let me just say that although the states are not required to use, uh, there, there was some, uh, recent study done by, uh, NCSL, the, and I always forget what that stands for in the National Council, Conference, Conference of State Legislatures, that, uh, indicates that 47 out of the 50 states do actually, um, that adhere to one of those areas, either, you know, use either certified systems, certified by lab, or, you know, to the VVSG, or, or somewhere, you know, even if they don't use those words, they use other words that, you know, that imply it. So, I, I do think that, uh, the majority of the states do actually want help. They're looking for help. They're looking for advice. Certainly there, there were quite a number of them that, uh, that voluntarily signed up for, uh, for some of the cyber hygiene services that were, uh, that were available via DHS. So, I, I, I think they're listening.  They, they want to, the elections to be secure.  Can you yell as well? Yeah. Yeah. What exactly are you trying to square there? I mean, like, uh, I don't think we've, have we said that? Okay. No, that's fine. No, no, no. Yeah.  Yeah.   I mean, yeah. I, I, I'm not really sure what you're looking for us to say. I, I mean, I guess what you're saying is on the one hand, there, there are public comments saying that we're not connected and we're standing here in front of you saying, you know, you got all of this, you know. It, uh, uh, yes, I, I mean, all, all of these, uh, you know, it, it's Josh is absolutely right. It depends on the state.  We don't have any control over what's said in public.  So, uh, we, we don't actually do the certification at NIST, the, the, uh, the voting system test laboratories go through, um, the, uh, the actual, uh, voting systems and there's a series of tests that they run. The tests are developed by the voting system test laboratories, although we provide, uh, guidance into what they should be. And one of the, the things that the voting system test laboratories do have is access to source code. And you know, they, all of the systems that, you know, that undergo that testing undergo a source code review. Oh, thank you. That's, uh, that's interesting. It's, uh, well, we'll wait and see what Congress does. No, I, I didn't. I can reach her. Okay. So since January, the department of homeland securities decision to, um, decide that election, voting systems, sorry, are critical infrastructure. Right. So January, they decided, okay, voting systems are now critical infrastructure. How is it that their critical infrastructure, yet the EAC, the federal entity that oversees voting systems has no teeth in essence. And that some states still do not have to abide by the voluntary voting system guidelines. When will the voluntary, the first V in that VVSG be dropped, since we now know that they are critical infrastructure, Wisconsin is one of your three states that in its statutes says it does not have to and will not only use certified machines. So it's a big issue in Wisconsin's a swing state and they're not interested in changing their voting systems. They like having that control. So what's your opinion of when we'll drop that first V? I think, yeah, I think Candice is right. Talk to your congressman or woman. We have no control over over dropping that first V. I haven't really heard serious pro-posals about about doing that either. I just haven't heard them discussed at all. I'm an activist and I've been doing it for many years and I thank you for your presentation. But I take exception with a few things. Okay. I take exception with the EAC when they certify something like virtual private networks and I go into a court case and the head guy of Wisconsin says, gee, I said, how could you let these virtual private networks be set up because we know most fraud is done by insiders. Okay. One person and he says, I wasn't me, was certified by the EAC. Okay. And when you look at those guidelines, okay, you know, when they pass the Help America Vote Act, there was no security standards until 2005. Two billion dollars that's been on these crap machines is what they really were. Okay. You know, I get very frustrated when an elections administrator says to me, we know it's working really well. We did a logic inaccuracy test before and after. Well, I know when that test was done, it probably worked right. All you got to remember is Volkswagen, my God, they passed 600,000 tests. The machine was rigged to pass. You buy a flat screen TV, says it's high energy efficient. Okay. You plug in the tester, the screen goes dim. It cheated. We need systems that are transparent, trackable, publicly verified.  I mean, what a way to do the voters to know that we live in a country that makes believe that we're that other country. We know how fraction magic works. We know how the systems are set up. And then to be insulted with these virtual private networks being set up and have somebody like I said, in court standups says, well, gee, we didn't certify it. The EAC did. Thank you.  You know, regularly. I think that is a powerful force. This is in, you know, this is a large collection of examples of basically outside of scrutiny. You know, it you know, definitely provides a a check against the the certification process. Yeah. Good question. Yeah, yeah. Um, so the actual standards that we're going to be, you know, making are basically, you know, going to be vendor agnostic. And so any number of vendors can, you know, submit their, their systems for certification.  It's diversity, a vendor. Yeah, yeah. Not a different. Yeah, yeah.  I do think it is a, a serious boon, but I mean, if you look on the internet, I mean, you're going to be able to find operating system versions and patch, and patch levels on a lot of places. And so I just don't want to put too much emphasis on that. I think, I think things like software independence and regular meaningful audits are a much more stronger security mechanism to make our, you know, overall system more secure, to be honest with you. Yeah, yeah. So one more thing, after these guys wrap up, I do want to give them a round of applause, but so we've already had our first two successful breaches in the voting village. A win vote was wirelessly hacked with the remote access already.  So an hour and 40 minutes in, and we've already got our first two successful hacks. So. All right.


Hi, this is Yoho Sakil Bhartiya and today we have to guest Arpith Joshipura, GM of Networking and H IoT at the Lenght Foundation and Kandan Kadarwal, technical studying committee chair of Nephew. Kandan Arpith, it's great to have you both on the show. Great to be here, great to be here. Yeah, and today we are going to talk about the release one of Nephew project, but I would love to know what is the project all about? Of course the story of the name and origin why it was created, what problem the community saw that you folks wanted to solve that led to this project. It's over a year now since this project has started. It was founded by a set of very motivated global ecosystem, vendors, service providers, and thanks to Google for taking the initiative. The problem Nephew wanted to solve was cloud native automation. And for that we gathered a team, you know, a community together, launched the project under the Lenght Foundation last year and it's been a year. And since then the momentum has been tremendous. From 25 founding members, we have tripled. There are over 75 now. All of the communities participate in the global TSCs. They work on creating a very simple extension of Kubernetes and implementing what is called cloud native automation, right? Now, from a vision perspective, as you know, the markets between telecom, enterprise and cloud were all distinct five years ago. And with cloud native principles, things started coming together. The carriers relied on the public clouds. The public clouds and carriers relied on enterprises to use them. And so we started looking architecturally and it was very clear that we needed a new way of doing cloud native network automation. So that's how we started. And obviously the name came about very interestingly. Kandan, you want to take that on in terms of what it means and how we got that. Nephew uses income based automation. This is a much needed automation technique that is needed by the telecom. And all the legacy automation system which were there before, usually those are fire and target. The automation sends out all the configurations and then the primary automation leaves to the monitoring system to the monitor and actually take care from there. But Nephew actually uses this intern based automation to sort of like take the configuration of the user, whatever it is the user want to accomplish. And then it converts into a configuration mechanism that goes and actually deploys this actually in a large scale. And this simplifies the automation quite a bit compared to the legacy automation approach. So the Nephew stands for, you know, intern based automation and the Kubernetes based approach that what the community is needed at this moment to make this automation perfect for telecom. How do you have seen the evolution of project? Because cloud native word is evolving at a very fast pace. At the same time, if you look at Linux foundation, you folks have you folks are like foundations of foundation. So you do collaborate with each other a lot. So how do you have seen the evolution of the project and collaboration with other Linux foundation project? If anything like that also happened? Yeah, so I think you said it nicely, like foundation of foundations. Similarly, Nephew is cloud of clouds, right? Just from a vocabulary perspective. And we are trying to make sure that the position of Nephew is very accurately architected in the end to end systems, right? So Nephew is not aimed at solving world hunger. It has a very specific purpose, whether it be, you know, within telecoms, within cloud and within enterprises, right? Across, but solving intent based cloud native automation, right? So that's the purpose. Now, with that said, because it is a Linux foundation project, we were able to have collaboration between Nephew and other adjacent projects, right? Specifically in Linux foundation networking, whether it's kind of on app on the top, whether it's CNCF, whether it's Kubernetes and some of the other CNCF projects, right? And we are also looking at, in some of the future releases, looking at collaboration with the edge and the access, specifically the ran layers, right? So because of the community being part of Linux foundation, we were able to include Nephew in events, in mini summits, in working groups, as well as in developer and test forum that allowed for that collaboration to make sure that we can provide an end-to-end open source-based solution, and not just a silo project. Now, Kannan, I also want to talk to you a bit about when we look at some of these projects. Linux is a very good example. It was created to solve a specific problem. Not today, everybody uses it with these open source projects, you know, you folks create it to solving one problem. And when you look at the whole cloud native community, folks look at the project, have you also seen any use cases on Nephew where you're like, you know, of course, it's in early phase, but where you're like, not that it was not your intention, but you're excited about the use cases, which are actually coming back and further improving the projects. Yes, I think this is a great question. So the use case for the Nephew is looking at this like a complete entire automation of cloud is back and all the interdependencies and the network functions for the telecom. And this is much needed because, you know, usually there are automation systems to address the cloud infrastructure, address the interdependencies like SRIOV, DPTK and these other configurations, then the network function has like entirely a different automation. So Nephew brings actually the full, cohesive automation techniques across all this entire stack. And this simplifies the part of it for automation techniques for the telecom. And the beauty is that, you know, it uses the Kubernetes, which is actually the proven technology that everybody is using to run the container. So it uses the Kubernetes to automate the Kubernetes. That's the real beauty of it. And the other important aspect, as you pointed out, is that, you know, there is a gap in the industry in terms of the configuration management for the entire stack for the telecom and the Nephew addresses that particular gap in a very efficient way. And it uses the Kubernetes resource model. And there's also a technique called the configuration as a data, which actually structures the configuration into a particular form. And that is the efficiency that the Nephew brings in. And this is much needed by the industry as of today. And R1 delivers that fundamental building blocks that is necessary for telecom to actually use this technique. And I would add, in terms of the use cases that are right on the horizon, now that we have a framework in place and we have kind of the first code prop in place, right, beyond the Google seed code that the community worked on. I call it multi-X, right? What that means is multi-cloud, multi-vendor network functions and multi-domain, right? Those three use cases are now looking very promising and the community is going to focus on those. If you look at the whole telecom industry, they are going through their own transformation. Now they are ahead of the curve now, but from black boxes to white boxes, commodity hardware, open source technologies, can you also talk about the impact that you have seen over the years of all these open source technologies, the work that you folks at Linux Foundation have done, because there is first of all so much code to be done. Also some of the industries are not, they don't have that many players as a lot of our interest. So there is too much work to be done, but this open source project, they help them move faster and help them collaborate. So talking a bit about not only just impact of, of course, left networking and the project that you folks are associated with, but open source in general. Ten years ago, as you said, the entire networking stack, whether it's carry the service providers, cloud service or telecom service providers, cloud service providers or enterprise networking, all proprietary, all vertically integrated. We all know that, right? Then came open daylight, you know, open stack, some of the other original open initiatives that kind of started this revolution, right? Now, in order to look at networking, you have to look at three places in the network, right? There is the access layer, right? Whether it's ran access, mobile access, enterprise access, then there's the edge layer, right? Edge computing that we call it, right? Whether it's IoT or, or anyway. And then there's the core and the cloud, right? There's the three layers. In the last three to five years, what we have seen is the core and the cloud layers have been completely enabled by open source networking, right? All the way from the data plane, right? DPDK, FDIO, OPI, et cetera, to the orchestration layers, to the intent based automation like nephew, to close group control, OSS, BSS, things like on app, right? Controllers like open daylight, all the way to EBVF life cycle management projects like LEAF, things like that, right? Everything from top to down on the core is now possible with open source. The same thing is happening in edge. There is a lot of blueprints that have been created by LF edge and other edge communities to allow for edge and IoT deployments to be built off open source software. The last piece of the puzzle is the access, okay? Enterprise access is still in an early stage, okay? Because they are going to utilize this this highly knowledgeable intent based pipe created by the public clouds and telecom providers to take services, right? And they don't need to build their own infrastructure, right? That's the enterprise access. But the ran part of it, the mobile access is still not open, okay? Only 50 percent is open. So if you're familiar with the O-RAN architecture, there are seven components, right? Four of them are open, like SMO can be built on own app pieces and if the eyes open, things like that. But the CUTU are you, which are the crux of O-RAN, not open, right? And if they're open, the licenses are not open source friendly, okay? So if long story short, I think we have about a couple of years, three years to go before your end to end systems can be all enabled by open source and vendors can differentiate on the top, okay? So that's a quick summary. When we look at all these projects and as I can also say in Taco, there are sometimes overleg, there are sometimes gaps and you know, we are trying to fill the gaps.  Can you also talk about when you look at, you know, zoom in on nephew, how does it kind of integrate with other projects, you know, or how do you folks leverage other projects? If you can talk about that, that would be great as well. Yeah. So I'll start and then Kanan can help. There is a philosophy difference, first of all, in the way CNCF community manages projects and the networking community manages projects, right? And the philosophy difference is let there be multiple options and solutions and the best solution and the most traction wins. OK, that's the CNCF philosophy. And the reason for that is that is how cloud native and cloud engineers work. OK. In telecom and networking, most of the developers are our business driven and they are not tens of thousands of engineers. So resources are still limited, which means we have a philosophy that we don't want five different ways to solve the same problem. OK, so Lennox Foundation and me particularly, I mean, I'm extremely interested in making sure that projects as they come in are harmonized. If there is an overlap, the technical communities understand the overlap. In some cases, they allow. In some cases, they merge. But most of the projects that we have have, you know, a very simple place in the network that are still not that those those that software has not yet resolved in an open solution like nephew, for example. Right. So if you look at the stack of the software and we can send you that the overall slide on that, that but, you know, from the data playing up, you've got Kubernetes, nephew sits on Kubernetes, right. And on top sits kind of own app and then all the others. Right. So that's kind of how they have been interoperating from a solutions perspective. And and then there there are other projects like M code that we had, which will probably be harmonized with nephew, since nephew is is kind of a more efficient way of doing it. I think nephew is the completely a complementary project. And this is much needed by the calakka in order to achieve the efficiency of the automation. And nephew primarily focus on the domain automation, but including actually the cloud infrastructure, the interdependencies and from a use case perspective, it can automate by being another workloads that the telecoms would have that including the fixed wireless and the private by G and the transport network. And this goes on like a whatever the telecom use cases like this can be addressed using the nephew. And as I said, like it's very complementary project. And there was a gap in the industry in terms of like, there is no configuration management best practices and implementation method, using a cloud native approach and nephew fills that gap. And that is why we see that, you know, like there is a, you know, 75 plus companies part of this particular journey. And they have been very actively participating in the ESC and as well as contributing the code. So we do see like a lot of traction with the nephew and with especially with the nephew or one that the people can really see the food that coming out of this particular community. Can you talk about some of the the major features, highlights of this specific release? Sure. And the nephew or one fundamental, it delivers the fundamental building blocks that is necessary to actually run the automation. And you can think of this as a control plane that is based on Kubernetes. And it's also provides the getups approach for management of the entire configuration. And it's provides the set of templates. You can think of this as a configuration templates, what we call as CRDs. And those CRDs can be used to automate like, you know, the entire stack. And then it also demonstrated the function automation using the same approach what I just talked about. And the community is looking forward to address like the many other use cases, but initially they focused on the 5G use case. And in our two and beyond, like additional uses of telecom would be addressed as well. Can you talk about what are the things that you folks are working on next? What are the things that are in the not exactly exact pipeline roadmap? But I want to just get a glimpse of, hey, these are the things that you folks are working on. Sure, I think community has to decide what the exact functionalities that has to be delivered. And there's already a planning going on in the community in terms of like, what does that office model look like? And I think that mainly the, you know, enhancement of the R1, the fundamental building blocks, plus like the supporting additional use cases, as Arbith mentioned that the intention of NEPIO is to support multi cloud, multi domain multi network function and primarily standardizing the configuration methodologies and structure. And that is a huge benefit for the industry. So the NEPIO R2 will focus on those areas. But again, community already started the work. And we're also looking forward to our second development summit for planning the entire R2 as well. How you have seen the growth of the community and what are the challenges you're seeing that the community is facing where you're likely you have to engage with more players? Or you're like, no, we are we are very good position, the players that we need all right there, all we have to do is just keep improving the project. So there's two parts to it, right? One is in the formation phase, right, which is just completed. You want to keep the community to the developers who actively contribute, right? You know, they are the ones who actually make it happen, right? I've always said open source is a duocracy. You do, you lead, okay?  So people who have been participating, including carriers like, you know, Bell and Telus and Orange and DT and, you know, LGO, you can get all the logos, right? They have all participated with the right engineers, right? And again, thanks to Google for the seed code and the participation and the technical leadership. A lot of it has been sort of kept in the neutral governance where people can bring in ideas and kind of develop this, right? So so the community and then there's a whole the top 10 vendors back it with engineers and things like that. So that's the formation phase, right? That's what it takes to get the release out. As we move forward, right? There is there is a growth that is planned where the second adopters, if you may, right? Not the the initial founders, but the second adopters. And there's a whole wave of, you know, companies within LF Networking or LF Edge or or CNCF or outside the core Nefio community that not only will contribute, but they will utilize Nefio, right, into their blueprints, into their solutions, right? And and then eventually contribute. So we we feel that that is the next phase of this project. And we are working to get that traction going, you know, jointly working with with the LF Networking teams and and and beyond. Okay. So that's kind of from a from a big picture perspective. And Kandan leads the technical community. So maybe, you know, a couple of words on on how the community, you know, jives together would be great. I think community did a very phenomenal work with respect to R1. And I think I see that huge excitement to sort of like a work towards R2 as well. And I think you can see in the social media, like the people are like a super excited about R1 and what's coming in R2 and beyond. So I think the 70 plus company coming together in a very short timeframe, and really forming the full structure around the community and keeping the process less and more code, as Arthur said, I think, you know, that was the purpose of this community. I think the community did an amazing job. And with a very short timeframe in delivering R1, as as artist said, you know, they took the Google seat code and further enhancing that seat code. And in delivering R1 in a very short timeframe is like a really phenomenal. Arpit, Kandan, thank you so much for taking time out today and talk about this project. And I can see there are a lot of, you know, things that are in the pipeline. So I would love to chat with you folks again. Thank you. Thank you very much. So thank you very much.


If you guys have heard Frank talk about the contemplative fitness AI or Bentino and his global enlightenment retreat uses the analogy of raindrops on windshield as you're in the car is that you kind of become sensation proof. So rather than having the sensation trigger a conditioning of separate self rather it's that windshield wiper or this contemplative fitness AI that's constantly running where their gap between a sensation coming and you recognizing how empty the sensation is is immediate it's immediate you recognize that it's all coming empty right away so there's no when you get to the really high levels that there's no even possibility even anymore for it to come and create a elevation of a conditioned contracted identity you what you ultimately that's this what we're talking about it getting to sensation proofing yourself would you like to also unpack this a bit for us Frank yeah so I'm just gonna read a post that I wrote because after I write something down I don't really think writing more so if I yes if I summarize it I'll be all over the place is it on your Instagram can I pull it up it's in my I posted on my story but I didn't make a post out of this I don't think you can see right now but I think it's in one of my highlights but I'll just read it yes I think the most direct and clearest way to put all those different stages of development in labels that we've been talking about under context is the direct realization the nature of sensations now think of sensations as the atoms of your subjective experience both inside and outside what a meditator or a contemplator does is quote-unquote zooming into deconstruct and dissecting and dissolving and shred your reality into sensations at the microscopic level all sensations are aware of themselves exactly where they are all sensations are devoid of both self with a small s and self with a capital s and spontaneously and co-dependently arising all sensations are in equal footing so no sensation cause or own another cluster of sensations different vibratory velocity of sensations gives rise to the difference between clinical air liquid and solid forms and all sensations self-liberate so sensations could be anything from body sensations to emotions to side sound emotions thoughts basically your entire field of experience is made up of sensations so all sensations are non-dual as in sensations in and of themselves can't tell the difference between God poop awareness consciousness emptiness eternity love intentions matter my being sober or being psychedelic or being drunk time space etc etc and since there is only clinical one substance there is no difference between the foreground and the background this is where we talk about deconstructing all the different stages and deconstructing even the background between the context and the content right because all sensations are homogenous therefore phenomenon do not arise and pass into some source that is what clinical real and permanent now the labeling of these sensations and the labeling of these phenomenons into concepts as you guessed it just more sensations you start to see that even concepts are sensations even labels are sensations no different from the things that they're labeling so you don't get attached even concepts so what's the difference between the awakened state in the egoic state now this is very important in the former the knots of perception is forever untied in the awakened state because the nature of sensations is penetrated permanently and experientially now all sensations in your entire field of experience lights up and are where themselves without a delay between the subject and an object between the perceiver and the perceived observer and observe the witness and the witnessing and this is your moment to moment experience of the clinical Godhead of infinity of eternal awareness because when sensations are experienced without a doer controller seer here thinker all 360 degrees panoramic are known and comprehended as itself without the delay between this or that that's reality feels omniscient in the egoic state certain cluster of sensations arise in the center of experience usually inside the head being behind the eyes and in place in some place inside the body that's hijacking other clusters of sensations to clinical take credit for other clusters of sensations in the field of experience and this is all due to conditioning that's what we talk about observer being trapped in an observer because it's taking credit for reality when this happens there's a contraction of energy when awareness or the ego is trying to you know hijack other field of sensations to be my there's a contraction of energy and that's identification that's the feeling of menace that's where the source of separation comes from that's it so when you zoom experiences down to the atomic level with max effort contraction like the paschina where you can no longer divide it this singularity ultimate loops back to the other side like a strange loop it becomes infinitely expensive that's the difference between you know the contraction method of the passionate versus the do-nothing meditation we simply just relax and let infinite consciousness return to its most natural state so all those practices merges one expansion and contraction this is why the practice starts out as dissecting atoms but at the end you end up repartializing the whole universe the very small is identical to the very large like the merging of quantum mechanics and cosmology love and death at the subjective level the parts is the whole and vice versa the atom is the universe now you can get to the same point either by contraction or expansion we talked about that and also you can you know do some psychedelic trips have glimpses of this or do the contraction expansion method you know while you are under the influence of psychedelics but you know I mean in my own path all my insights and in realizations came naturally I mean I've experienced it with psychedelics in my 20s and have viewed the empty trips but the reason why I advocate being doing it naturally is because I'm just biased because I give my natty my older credit anyway so I think that's pretty much it that was so good there's another one last part yeah so when you take to the end point contraction and expansion just lose meaning and this is when absolute infinity and absolute nothingness emerge simultaneously and this goes back to what I was saying about how the natural state is like a permanent secession the unconsciousness of the Banna or the ninth drama but also infinite consciousness of the sichuan now if if you don't see clearly the nature of sensations at all levels as being empty and for the same time and not self one critical level is always going to see more or less real or solidified they're another level that's why you started to identify with awareness or consciousness or this or that God state because just stations has been seen through so one level is always going to be more solidified right so that's when again contraction occurs identification takes place that's cleaning and suffering so if you understand sensation at the experiential level that's it but there's some pitfalls to this as well so the contemplative fitness AI enables cessation at the experiential level yeah and understanding sensation at the experiential level and understanding cessation of experiential level enables the master resides in dow the natty state perpetual yes but but here's a but I was posting this on a forum and then there were some responses saying this is by deconstructing experiences only down to the microscopic level of sensations can be a little bit reductive it's almost like a scientist who only cares about atoms which I don't disagree with because I've seen a lot of people that are really into the view passion on path at all about sensations they see every experience they just reduce it down to a microscopic level of sensations and then they're more in the emptiness side of the equation than the love the affinity in the fullness side but my counter argument is for those people they happen taking sensations all the way that's why there's a problem if you take sensations all the way like I said it loops back to infinity maybe you're taking sensations down to the 99% level but 99% and 100% it's quantum once you the passion I sensation down to the microscopic level and 100% you dissolve everything boom it's absolutely infinity which is Sam is absolutely nothingness yeah so that's why you can get to the same endpoint by either doing the passion at the theravada path or by doing sort of the zochen kind of practices like do the subversion of the ocean because the ocean is full this form is the natural state but there's subversions of where you can do the awareness of awareness practice abiding in consciousness kind of practice like the later form of genres kind of practice if you do that long enough you also lose back to the microscopic level yeah but there are I see a lot of people that sort of lean towards one side of the of the duality of the equation which is really interesting some people are more energetic they're talk about love a lot you know and then they did the way their vibe is it's like you know more more in touch with the Christ consciousness and both the stuff of Pat and some people are more into the emptiness path if you take this all the way you merge the two you do you merge the two if you take this all the way this is this is what this is it take this all the way this contemplative fitness AI take it all the way to see sensations at this most subatomic level if you do that you will recognize what we're talking about which is being sensation proof and enabling you to reside in life itself to dissolve into life fucking itself endlessly yes one more point so what exactly is the natural state that the natural the natural state is just the fact that once you see through how all sensations are in equal footing once you're not attached one club once one cluster of sensation isn't hijacking other cluster of sensations all sensations appear exactly where they are as it is okay I have a question would this would this be like today I'll go through this example and then we'll go to the night okay would this be this I feel like this is gonna funnel perfectly into this example today the trash service came and the other tenants in the building had been emptying some food and drink and whatnot into the bin so it had created a very big stench over the week so I'm bringing the trash bin back after it's already been emptied by the garbage truck I'm bringing it back to the house and I'm realizing that I'm gonna be washing the bin out and as I'm washing the bin out I realize that washing the dirty garbage bin that smells rancid is the exact same made of the same empty in full infinitude as having sex or drinking tea or watching hummingbirds okay it's just how everything is just made up of how scientists will tell you everything's made of atoms you know your God experience is made of atoms so is your your poop right and sensation is just observing and realizing this at the experiential and the subjective level so you don't cling on to any particular state the ego state the ego state is just thinking that all one cluster of sensation is more real more solidified because you haven't seen through it that's contraction if the state of awareness becomes this new cluster of sensations that you get solidified then that's also just another degree it's another degree that's transcended from the ego state but if there's any preference over any cluster of sensations in your field of experience then you cannot enter a state of perfect equanimity that's it that's it when there is no identification with anything at all sensations can just appear by spontaneously simultaneously they all call dependent arising and they just appear as they are spontaneous dependent origination without a contracted conditioned separate self to have preferences right right and this preference could be ice cream or infinite consciousness yes and attachment to those preferences which then creates the craving aversion suffering yeah yeah that's pretty much what the natural state is okay beautiful so let's have you continue defining this for us like with here when in the dock so we kind of talked about this permanent cessation well conscious