Lightning Talks (Wednesday) with Andrew Mshar

Speaker 1: So, hopefully that works. That looks much better than it did before. Hello! I am Hans Kelsen. I um I write interesting software that's marginally serious. If you saw my lightning talk two years ago, it's a cool thing that I built. I write websites that are much more serious than that for work. This is where I work. I also write other things. Alright, magical digital creatures that will save you time and make you more efficient. Sort of, if you use them right. So at work we had a problem. Our staff meetings were slow. They took forever. We had this wonderful Google Doc where everybody put your subjects to discuss in, and we go down the list

Speaker 1: in order. That meant somebody always went first and somebody always went last. And the person who went last, their item never really got discussed because we were all ready to get out of there. Alphabetical order by name, it just didn't work We all had the whole document in front of us, so we're switching back and forth and discussing everything. Crosstalk abounded. We were not focused until the agenda hat. What is this? This is a program which you put in all of your agenda items into the into the database. This is a Django app, of course. Put in all your agenda items in the database, and then uh when it comes time to do your meeting, you go down the list in a random order and it pulls them out of a hat for you.

Speaker 1: Why? Why not? I mean sure you could write it down on paper and literally pull them out of a hat, or you could just be more disciplined and focused in your meetings, but who wants to do that? This is way more fun. Well it's pretty obvious, right? It's a stupid Django app. Barely does anything. Run SQLite because If you're running something like this in a big enough installation that you need Postgres, you're doing it wrong. But um, you know, every bit of this is vanilla CSS animations. HTMX, Hyperscript, and Django. I wrote it in about three days. Check it out on GitHub if you want to

Speaker 1: if you want to know more. There's a Docker image. Works. I'm gonna cut a new release today because I just fixed some stuff to make it work for this talk. So Cool stuff if you want to check it out. Now, why am I up here giving a lightning talk? This is hopefully to inspire anyone who thinks, well, I only want to work on projects that are serious. No, no, no. Do silly things, cause sometimes even silly things are useful. This has literally saved my workplace hours and hours and hours in real life in meetings and made everybody less frustrated and we all still laugh at it two years after I first put it into production. So there you go Lighten things up a bit, build cool stuff even if it's silly.

Speaker 1: Thank you.

Speaker 2: All right, hi. I'm Chris Watkins. I'm about six feet up. This is my first uh Django Con. It's great to be here. Thank you. Thank you. Thank you. Um now I gotta get my mouse back. All right. Went through that already. Okay, so years ago, I had 72 hours to save a contract. Not at my current employer, at a prior employer. And uh The problem was that we were shipping uh a broken release, literally every release. Uh we had zero functional or integration testing. We had over 95%. Unit test coverage, everyone thought everything was roast. Excuse me. Everyone thought everything was rosy and it was just

Speaker 2: blowing up. It was a sorry, it was a major It was a major um problem for me in my personal life, right? It was it was eating up eating up a lot of my time. Um let's see. I kept asking for time to fix the problem. Right? The tests suck. Our releases are broken. Everyone's working all the time. We're getting a high turnover. The teams are frustrated. But it I never got that time and I spent a lot of time thinking about why I could never get that time. I these are things I heard all the time. It can wait until it's an issue. It doesn't sound like a high priority for the team. We'll get to a next sprint. You aren't going to need it. You are going to need it, by the way.

Speaker 2: The key for me was eventually I realized that the problem wasn't actually the tests. The problem wasn't actually the lack of monitoring. The problem was that we weren't framing the need in a way that the business understood. Right? Don't say we have missing tests. Don't ask for time to fix technical debt. Ask time ask for time to lower teams iteration speed and spot problems early. Are you missing monitoring? Ask for the ability to detect and respond to issues efficiently. Don't ask for I need time to build monitoring. TechDeck compounds negatively, right? Robust engineering processes compound positively. You can make that work for you instead of against you Essentially you're fighting the delayed gratification bias, right?

Speaker 2: Before months to ship, things are broken when they ship. After you're developing and deploying safely in minutes. And that's the kind of thing that gets the business's attention. That's the kind of thing that gives you your life back. That's the kind of kind of thing that makes your product better and makes your users' experiences better. Not everything, not every backlog item you have is going to be critical and add value. And it it your credibility depends on being able to make that distinction, right? And really you can think about it, you know, your particular pain point, what's the blast radius? Is this pain shared? What capabilities are blocked, right? What business outcomes will be possible if I was unblocked Right? Like going back to uh functional or integration testing uh for a lot of projects

Speaker 2: uh That gives you the ability to iterate safely at speed. You can make a change and you have tests that could catch it. Then you don't have to spend time six months later catching the breakage when things are on fire and your customers are mad and right. And that's my lightning talk. Thanks for your time. Hi

Speaker 3: again, everyone. My name is Emmanuel, a GIS consultant at UNGSC in Valencia. I'm a geospatial software engineer and the founder of Spartia Node. Today I'll be making a presentation on FER, an AI assistant mapping partner we developed in collaboration with the humanitarian OpenStreetMap team. Fair is solving a critical problem that happens or that occurs in humanitarian response, and that's manual mapping. So when disasters occur in a particular area How we help forced responders is to manually digitize buildings, lines, and roads to support their operations. However, that's very slow and it's resource

Speaker 3: intensive because When you have disaster you want to respond fast. So we built fair to automate this process using AHI. computer avion technique specifically and how fair works is it's we have a base model popular base models like YOLO and RAMP And then we kind of fine-tune this model for local areas. So we don't have like a gigantic model that can extract features for the old world. We have local specific models for different areas of interest and that's what makes Fair very powerful. So Fair is built on Django. And Django is the framework that's powering everything about fair. And why did we use Django? Because why not Django in the first place?

Speaker 3: Django is very fast. It helped us to like prototype the Features we wanted to build very fast and most importantly is the geospatial support because we are building a geospatial product. We want to do some geospatial and geometry operations And Django has a very good support for PostGee's, which makes it easier for us to use uh PostG functions, for instance. And it's scalable, like a lot of good things, good stuff about Django already. And then another thing is the API parts because we wanted to display the You know, the extracted features on the web map and we need a GeoJSON response. So Django Rest framework GIS made this really easier for us to to use. And Fair is already existing, it's live, it's deployed, it's in production, and it's working and it has all these features we've listed here.

Speaker 3: And we also plan to add more features in the future because it's really cool. We want to have like an organ phase for geospatial models where we can collaboratively collaboratively share geospatial models and also integrate map swipe. So map swipe is like a street level street view imagery. We want to be able to detect buildings as well from these imageries And thank you so much for your time. Fair is very interesting. Unfortunately, I won't be able to talk more in this lightning talk. But if you want to learn more about Fair, please feel free to reach out to me. And you can check the code base as well. Everything about FAI is on GitHub. It's public, both the front end and the back end. You can scan the QR code to check out the code base. Thank you so much.

Speaker 3: Uh

Speaker 4: my name is Santos. I'm from Ecuador. I'm a core developer on Videodox and today I'm going to tell you about how you can improve your documentation review workflow. Uh Reads is an open source platform that allows you to build, host your documentation for free for open source projects. And when someone opens a pull request on your repository, Reed Docs automatically builds your documentation from the pull request and you can preview those changes before merging, which is great. But uh you usually want to check the specific changes in the documentation, the files in the sections that modify Doing that manually is a pain. You need to navigate to each file or maybe try to guess the final URL

Speaker 4: of the page. I usually try to save time to the reviewer by putting the links of the files the change in the pull request description, but that isn't perfect because it's still like manual process and takes time and what time it takes is my time. So to solve this problem, Creedoc now lists the change files that are resulting from building the pull requests and allows you to see the div in line on the render HTML like you can see there Uh we also added client integration with GitHub so you can see the list of change files directly in the pull quest that's from our bot. Um you may be thinking, hey, doesn't GitHub already list the files to change and show you the div? Yes, but that div

Speaker 4: from GitHub is from the source files, not the render HTML, which is what your users will see. And also sometimes not really clear um what the changes on the renderer HTML are going to look like because sometimes like what happens if you include doc strings from your code into the render HTML. So for me, both divs are complementing each other and also knowing the file is the word deleted. is useful to create redirects so you so so we avoid broken links in our documentation. You can use all of these features today. Here is a link to the documentation so you know who to enable this feature on your projects. I was in charge of the implementation of the FDF

Speaker 4: detection and the GitHub integration. So if you want to know more details about how this works or you have any feedback or just want to say hi or talk in Spanish, uh I'll be around. Thank you ,

Speaker 5: okay In human language, you can say thank you in many ways. In Spanish, you would say gracias. In Portuguese, you would say obrigada. So, what about in Python? What is the Pythonic way to express your gratitude? So let me tell you all the different ways you can say thanks to the Python people and you wouldn't believe what number five is. Let's begin! Level zero is actually say thanks to the person that's been helpful. And I put level zero here not because it's not important, but you know we're programmers, right? We start from zero And I know you're already doing this. I I hear it all over during this conference, and I know this is really easy to do, so keep doing it. Level one. Say thanks in public.

Speaker 5: Don't keep things to yourself. Share the joy with your friends, your colleague, your network, their boss especially. By saying thanks in public, you're giving visibility of their work, the recognition they deserve, and you'll also be helping to further amplify the impact of their contributions. helping them helping their content reach more audience, helping their tools and library be discovered and used by more people. And maybe you're you're um you're afraid to embarrass the people you're uh to who did great work or maybe you're embarrassed yourself. So do not be embarrassed. Accomplishment is not a shame, it should be celebrated. Level two. Like and subscribe.

Speaker 5: I know it's cheesy, but just show you're interested in their work. Show that you want them to continue continue maintaining the library. You want them to give more talks. You want them to put next year's conference. Like you don't have to wait until they're done doing all of the those great works. You can show your supports, show your interested and it it helps validate them knowing that you find their work meaningful. So support them by subscribing or if they have blog or YouTube or follow them on social media, just show your interest. Level three. Contribute and volunteer. So don't just use the library, contribute meaningfully. Find their GitHub repo, check the contributing guide.

Speaker 5: learn the workflow, learn their vision of the project, and start contributing. So and don't just attend conferences and meetup Offer to help and volunteer. So help lessen their burden and responsibilities by helping them out. Level four, getting a little bit harder Don't have time to actually contribute or volunteer. Give them money. Sponsor your favorite open source maintainer on GitHub, Open Collective, Patreon So many options these days. Buy them coffee, send them PayPal, whatever. And if you couldn't find how to support them, ask them. Tell them I wanna help you. What can I do? Just little tokens of appreciation

Speaker 5: If they don't yet have GitHub sponsors or maybe they didn't know about these things, tell them so that they can sign up and you can start sponsoring them. And if you have favorite Python or Django conference, check their sponsorship prospectus, tell your employer about it, and encourage your employer to sponsor. Now, this is the ultimate way on how you can say thanks to the Python community members who've done really good work You nominate them for awards. And there are so many of this in the community. Some of this even come with monetary reward. Don't have your own money to give, use other people's money. And people don't just magically receive this. People don't just magically receive awards.

Speaker 5: In order for them to receive this, someone else needs to be to be submitting this nomination, need to tell them the work they're doing. You can be the one helping them. And it's just much more stronger if more people are vouching for it and for their their work, you know And don't assume that they already received the award. And this is one of the biggest mistakes I've seen. People thinking, oh, of course, this person is so great. Of course, they already nominated for this, they already received the award. Don't Check the list of award recipients and nominate. I also encourage you to like go outside Outside of North America. We're in North America. Sometimes we get news about North American community, but there are a lot of people doing great

Speaker 5: work putting on conferences out there in all over the world, Asia, Europe, Africa. Go check them out and let us in North America know about the great work in the global Python community. So now go thank the Python people, the people in this conference, the organizers, the speakers, the volunteers. If you want to learn more, wanting to learn more how to actually nominate people, I have a blog post and you can scan this QR code. Thank you so much.

Speaker 6: All right. So I'm Drew Winstall. I've been on the DEFNA board since 2021. I've been to DjangoCon's US since 17. And uh today I'm here to ask you if you want to bring DjangoCon US to your city. So under the Deaf Umbrella, we've been to Austin, Philly. Spokane, San Diego, San Diego again. Let's not talk about 2020. We went all fully online in 21. And back to San Diego in 22, and then we were in Durham in 23 and 24. 25, you're here. Thank you. 2026. I don't really have anything to announce yet. All I will say is stay tuned for the closing remarks for that. So let's look forward to 2027. We don't know where we're gonna be.

Speaker 6: We have no idea. Maybe you want to be there. Let's find out. So the call for venue proposals is live. It went live this morning. It goes until January fifteenth of next year. You've got plenty of time. This is not an urgent thing. Uh what are we looking for? We want a city, first of all. Where are we gonna go? I mean as you've seen right there, DjangoCon US has been to six states in the 10 years that the DEFNE has been running it. There's plenty more of the country to go visit. We need venue names, could be one or more hotels, uh conference centers. Doesn't even have to be a proper hotel. I mean remember 2016 was at the Wharton School as at a university in Pennsylvania in Philadelphia. Dates dates are important because we have uh contractual obligations with the DSF that we can't conflict with certain religious holidays on the Christian, Muslim, and Jewish calendars.

Speaker 6: You can let us if you have questions about that. We're happy to help with that. Contacts at those venues are super helpful as well, so we know who can we can ask if we have questions that you all may not know offhand. No big deal. Local organizers. What do we mean by local organizers? I'll come back to that in just a moment. But first, let's talk about the city. You know, we want a group of people on the ground that can really help us out with um Finding places, doing the local research, going to find like a place for a speaker and organizer dinner, or good suggestions for local restaurants and options, things along that. Someone who can go walk in walk into the venue and say, hey, how big is this room and how does the layout actually work in person? Because floor plan plans only take you so far. And the big thing also in the city is for those of you who were here in 2022 in San Diego, remember the keynote by Jay and Melanie

Speaker 6: talking about the diversity of their venues? This is crucial. We need to be in a place where it's not just a bunch of people who look like me. The venue itself, we need to have two tra space for two tracks. One room, the large room like we're in right now, should have capacity for about 450 people. The smaller room should be about 200 people. We need a green room, we need a quiet room, a lactation room, and an organizer room. Those are pretty small side rooms. Any convention center should be able to help that, no problem. We need more information on their catering plans and room for sponsor tables. Catering, this is another big one. We all need to eat, right? You need to be able to handle dietary restrictions. At the least, we need uh gluten-free, vegetarian, vegan, halal, kosher. And uh

Speaker 6: anything I'm missing on that, Peter? Okay, thank you. Uh be able to feed the whole conference within about a 90-minute window, also serving breakfast, breaks, lunch, coffee, and drinks. All right, the local organizing crew. These are the people on the ground. Like for Durham, we had Peter and a few other and uh Tim Allen and a bunch of people in in Durham proper. that helped us out. We've got Kenya here locally in Chicago and her front people that have been excellent helping us find stuff in town. You need to find places not just at the venue itself, but nearby, like great restaurant recommendations. Especially like Chicago, there's a thousand places nearby that you can plant go get to. But like a Durham, a much smaller town, you know, it helps have that rec that crucial curation of these are good places you want to be if this is your want you know you have three days in the town. Go find this cool stuff.

Speaker 6: Find vendors for if we can get the uh like shirt t-shirts and swags, swag stuff printed locally, that saves us on shipping and also generally provides a better product. So we'd like to do that if we can. And uh previous organizing organizing experience is helpful but not required. You are not by submitting a process, by submitting a proposal, you're not committing to be the chair. You don't have to chair necessarily, but that would be nice. We're not gonna say no. All right, sprint venues. It can be the same as the hotel. Does not have to be, but ideally it needs to be within walking distance. You need capacity for 50 to 75 people, power, really good internet, and a place to eat. Because people those get polls use up a lot of bandwidth really quickly. Alright, so how do you develop a proposal? Talk to your local convention visitors bureau. They'll have great ideas for uh venues that you can use. They'll know better than anyone else.

Speaker 6: The venues themselves, talk to them. They have uh event coordinators that are happy to give you this information about um what kind of duck uh cost they have, how much these things run. And collect that stuff, add in your local flavor, explain why this city would be cool to host, that goes a long way, and then submit it to us. Do that. By assembling it and emailing it to hello at defnodot. org. And here's the QR code for that uh URL in case anyone wants it real quick And uh that is it. Thank you so much.

Speaker 7: Hello, uh I'm Marcelo. I'm going to talk about back channel logout. So uh well This is me. I work at Authentic. I'm a Django Software Foundation member, a PSF fellow, and I am the organizer of a Python Paraguay community. That's Paraguay. So for context. Uh well probably you are um familiar with this kind of st a screen. This is an all out uh authorization screen. So It's meant for an application to access the resources of another system. So uh for a little more of context, well uh O out it's More about authorization and OIDC is more about authentication.

Speaker 7: It's more about the user itself. So the back channel logout is an uh OEDC specification, so it extends the OU2 with proper session management. So this is there is a specification. And well, but there is a so what is a problem that this try to solve? It's like when you are logging in your company like single sign -on , but you log out that and you are still logging into Gmail, Grafana, Notion, you name the application, so that's a problem. The session persists across applications. And the traditional logout only affects one application. So even like if the administrate like the system administrator like uh offboard and user

Speaker 7: the session could be still uh active. So the idea is to so yeah and the user expects that a complete logout. So the solution is the back channel logout that is a server-to-server uh commun uh mechanism. It's sends a notification so you log out from your identity provider like authentic kickload. And the identity provider provides identifies all the applications and starts sending the logout notifications. And the on the other side, the apps terminate the sessions. The difference with the front and front channel logout is that that happened in the browser and it's for usually for one or a few applications. And the back channel one is from server to server.

Speaker 7: um communication. So it's more reliable. So we have that problem, we have a solution, and we have already again a problem. So the reality check is that this feature is amazing but nobody supports it. If I remember like when I was uh developing this feature, I had to I found like Nextcloud and Matrix Synapse chat app and that's almost all ev all that I can find that an app that supported. But yeah, even the identity providers, we have the the this issue like Shout out to Kicklock that they also support that, the back channel logout, authentic, and some others more popular identity providers don't support it. Like uh they support some other kind that is not standard compliant, but yeah, so

Speaker 7: that's the situation So a little the technical part, basically it's uh how it works. It's a logout token, it's a JSON web token It sends uh through uh through post to an endpoint, and the app needs to validate that and terminate the sessions. So why did it matter? Because it has security benefits, uh, it prevents session hijacking, it's to do it's a compliant requirement, and it improves the user trust in general. because you know uh you got logout from ever every place. So uh the authentic we fully support this with a simple configuration. You just need to add And URL and your configuration, this is an example, it's just one single uh text field that you need to file.

Speaker 7: And yeah, but so this is more like a call for actions for developers for this to try to support this amazing feature in in there in your app. So basically you need to just create an endpoint, validate the JSON web token, and clear the sessions. This is a minimal, minimal, minimal implementation. Don't quote me on this, but it should work. And yeah, we build it. Please come So

Speaker 8: this was originally a pretty long talk. Trying to trim this down a lot. But quick intro, my name's Connor. I work at Authentic. as well. I'm going to go over the history of some protocols in the military and some single sign-on protocols and how they made their way into Modern computers. So originally in World War II, we basically just had the A3 scrambler for phones. This wasn't really encryption, it was just obfuscation. You just took high signals and inverted them, vice versa. Um by like the 70s, high schoolers could crack this. It was really bad. So regularly being cracked all the time, we needed something better. Uh we started getting vocoders. We made uh Alan Turing helped create the Green Hornet at Bell Labs. This is the first actual voice encryption system to ever exist. We

Speaker 8: use massive uh turntables to add white noise to the signal and uh a turntable on the other side would remove that sound. So moving forward to the actual point of this though, uh Vietnam War. So at this time, Sig Sally was way too big. We needed something way more simple. So we made uh the Autobahn phone network, which just connected a bunch of phones throughout the military. Um and if you had encrypted devices connected over the same infrastructure, we called it the AutoSebocon. The main phone used on the Auto Sebocon was the KY3. So it weighed like 300 pounds. It was the size of a safe. Arguably as m as lethal as anything on the battlefield if it fell on you. Pretty rough. And they would try to hide it in rooms, like cover it in wallpaper as if you couldn't tell, you know, something's clearly there.

Speaker 8: But the encryption system was really interesting for the for the time. They basically had a single key encryption system. So if phone A wanted to call phone B , phone A Would encrypt a vocoded message with phone B's key, send it over to phone B. Phone B unencrypts it, right? Encrypts a phone A's key, sends it back. So it's like terrible, really slow. Um it uh They can only hold about 30 keys per phone. So you can only call about 30 people at a time. It's really bad. And the NSA is basically like, this is our biggest problem in the military right now, is figuring out how can we encrypt these calls. So a man named Howard Rosenblum makes what is called the Bellfield system. Uh if you are an authentication nerd, this may look really familiar to you, but the way that this system works is

Speaker 8: phone A instead of calling phone B. calls a central authentication server. This server, after authenticating phone A by its key, makes a session key. And then sends it back encrypted with phone A and phone B's key. And now they have a session key to use to communicate with each other. But with this system, there's not a 30-key limit anymore. I mean any key, sorry, any phone on the network can call any other phone. So arguably I would say that this is the first single sign-on system ever created. Right? It used the STU1 But still, if you think of single sign-on as authenticating in one location and you're authenticated anywhere else on the network, that is exactly what this is. It just uses phones.

Speaker 8: And I would argue that Jerome Saltzer, if you are familiar with him at all, um would agree. So at the same time in the 70s, he is working on Project Athena. Out of curiosity, does anyone know Project Athena, heard of Project Athena? Really? Awesome. You're awesome. So this was literally the largest network pre-internet to ever exist. So to to picture the craziness of this, like if you were on uh be pre-project Lithena, you would have to walk up to a mainframe, you'd use a dummy terminal. All your files are on there. There's not really like a client server system like we have now, right? But that's literally what Project Athena is in the 70s. Any student at MIT could sit at a computer.

Speaker 8: And looking at time, can log in and access like instant messaging. Uh the equivalent of like Google Docs and Cloud Storage can like visualize um graphs and things like that. Huge. Project Athena gave us um a really important Linux um uh I forgot I forgot what it is, but I'm gonna skip past that because we're running out of time. Anyways, point being they needed a single sign-on system. At the same time, Jerome Saltzer was actually doing consulting for the NSA. He saw the Bellfield. Um was like it'd be super legal if I just did this because it's classified. So waited for someone who worked at the NSA to give a talk at a conference. vaguely described the system, gave it to his colleagues, and gave us Kerberos, which was the single sign-on system for Project

Speaker 8: Athena. So that's how we got single sign on. Thank you.

Speaker 4: Alright. It took some time to set it up. But

Speaker 3: welcome. So today I'll be going to talking about Django phone verify. It's one of the projects I wrote like seven years ago. uh

Speaker 6: never mentioned it. Uh it

Speaker 3: just uh

Speaker 6: gained traction because I was facing an issue and the

Speaker 3: Uh but before that uh let me introduce myself.

Speaker 6: I'm one of you, a part of the community. I'm a force contributor, uh

Speaker 8: part of the Django website working group.

Speaker 3: Um I've been a longtime force contributor um and I work at Lincoln Loop Um I go by QDS learner all over the web.

Speaker 7: So on GitHub you can uh search me. And

Speaker 3: here's the problem.

Speaker 7: So most packages that Wanted to

Speaker 8: verify phone numbers, they were too coupled with the authentication flow. And they always mess up with your auth user model because everyone assumed

Speaker 7: that whenever I want to verify phone numbers, it's part of the authentication system. But it's just one chapter in the whole book of things. Right? So verification is altogether a different thing. And

Speaker 8: why I say so is because you could be verifying a customer's profile, you could be verifying a restaurant's profile There could be an org that you want to verify the phone numbers for.

Speaker 6: And auth is just one of the chapters in the whole phone verification story. If you can scan the skewer code, you'll probably head over to the repo. And so uh we realized phone verification should be a service, not an oddside effect. It needs to be pluggable.

Speaker 8: use

Speaker 6: in any model workflow or form.

Speaker 8: So the core capabilities were to generate, send and verify

Speaker 6: and expire the OTPs. That's it. So it basically follows Unix philosophy of do doing one thing and doing it well. So What's Django Phone Verify? It's a lightweight app. It's model agnostic. It comes with two built-in backends. One is Twilio and the other one is Nexmo. It also has uh capability that you can extend it to any provider, uh be it AWS SNS, message

Speaker 8: but whatever, right? But the Main idea is once you have Django phone verify integrated, you can just switch the back-end provider as You like. So the idea is to handle OTP lifecycles and not your auth logic. So here we go. 60 seconds is all you need to have Django phone verify installed. You just do pip install Django phone verify with whatever backend you need. So you could choose choose either of the tool

Speaker 6: or Nexmo. If you don't need any backend, just skip

Speaker 8: it. Just install bare

Speaker 6: metal phone verify and then you can switch your own backend. You add phone verify to your installed apps and then you can configure settings. So

Speaker 8: there are just two workflows In the whole system, which is one is send verification, which helps you send the verification, and the other one is validate security code, which is essentially to say if I am

Speaker 6: having a phone number and a code As well as session token. Session token is altogether a different story, which is basically to say: is it the same person who requested the OTP and is it the same person who is now trying to verify? for the same OTP. So it works in Django views, forms, API. Out of the box it also

Speaker 8: has uh Django REST

Speaker 6: framework views integrated so out of the box you also get two endpoints so you don't need anything you just need 60 seconds install it and you get the API out of the box. If you want, there is also documentation on uh um On extending the package. So it's usable anywhere, not tied to authentication. Um it's secure. Uh there are expiry, uh there is attempt Uh attempt limits, uh there's also one-time usage. Um it also supports I-18N and let

Speaker 7: me just Show you

Speaker 6: yeah, so these are like the two flows that you get out of the box You could also go with the Django views and forms and integrate it. There's documentation for all of it. So yeah, uh it can be used for multiple flows like sign-up, two-factor authentication, marketing opt-ins, and everything like that. I hope this helps. Uh if you If you want to discuss anything about open source, Linkin Loop, or otherwise, I'll be around. Happy to chat. Thank you.