Hey folks, we are going to get this party started here.
My name is Kaitlin Bowden, or Metis4.
My co-presenter is Christian Ryu, aka Dildog, and we're here to talk about Valid.
So Valid is a privacy-oriented application development framework.
You might have heard of it.
If you haven't yet, we're going to tell you all about it and give you some ideas about how you can help and what's been done over the last few years since we released the framework at DEF CON.
Meanwhile, we actually have a third co-presenter.
This is Elit.
This is the mascot of Valid.
They are a brick.
Their pronouns are he, them.
Now, we chose a brick as the mascot simply because bricks, when working together, can build amazing things.
But also, one brick, if thrown properly, can change the world.
Sometimes I get a bunch of little bricks and throw them out to the audience, but I didn't do that this time, so I'm sorry.
Yeah, you missed the foam brick thing where you usually throw them.
Anyway, let Elit be for himself for a second here.
Give you an idea of what this is all about.
Hi there, I'm Elit.
I'm a brick, and I'm the mascot for a cool new privacy project called Valid.
At this point, you're probably asking yourself, what is Valid?
But to answer that, we have to go all the way back in time.
Back to 1984 in Lubbock, Texas, when the world's longest running hacktivist group, Cult of the Dead Cow, was born.
For 40 years, CDC has been changing the world with hacking tools, text files, and hacktivism.
In fact, they even coined the phrase.
Fast forward to the summer of 2023 at DEF CON, when two members of the CDC, Dildog and Menace4, released a brand new privacy project called Valid.
And now you're all caught up.
But wait, no, seriously, what the heck is Valid?
Short story, Valid is an open source peer-to-peer app framework to build privacy for all.
But like, what does that even mean?
How does it work?
What?
What the heck is this?
Well, to explain that, we've got to break down some myths about how online communication works.
So let's break this down.
You have you, your device, your phone, you want to message your bae.
So you just shoot them a text, right?
They shoot a text back, that's how it works.
Ehhh, wrong!
That's not how it works.
This is what actually happens.
Alright, so you have your device, you have your bae, you want to text them, but in between there's Apple, there's a cloud, there's some servers storing everything.
There could be a social media overlord reading every single one of your messages, or even the government.
Either way, there's always somebody in the middle, listening to your conversations, storing them, possibly selling all your data.
And if they're storing it, that means that hackers have the possibility of getting into it.
And then who knows where it goes.
And what Valid does is take out that middleman, so it's just you and someone else chatting, privately.
But wait, Elliot, if there's no servers, how does that even work?
So let's break this down.
You little pink dot, over here we have bae, and you little green dot.
In between the two of you, rather than servers or some social media overlord, you have purple dots, nodes, that are helping to transfer your messages.
A node is just like you, except they can't read anything that you're writing, because it is all encrypted.
Which keeps your data safe from prying eyes.
And Valid is a network made up of all of these nodes.
Lots of them.
Each node is a different app, and can be a different , completely different thing, but they all support each other.
It doesn't matter if one app is bigger than the other, they're all equal.
So every bit supports the network itself.
You're a part of the network, bae's a part of the network, we all are.
So rather than the internet being, you know, Jeff Bezos' cloud, the internet belongs to all of us, with communication between us, how it's supposed to be.
Nerd alert!
And then encrypted, which is upgradable, it's written in Rust, with Flutter, binding similar to Tor and IPFS, but faster, and it's completely distributed.
It's a brand new way of privately communicating with your friends, with no social media oligarchs, no government, and no servers storing your data, keeping it safe from prying eyes.
Because Valid is an open-sourced app development framework, anyone can build any kind of communication app on top of it, with privacy and security built in.
We've built a great community of people working together to build apps that are secure and usable.
All we need is you to bring your ideas and your talents to the project.
So come check us out on Valid.com, and on Twitter, at Valid Network, at least until we've built something better.
I hope you learned something from this video, and come join us on Valid.
Meanwhile, Elit out.
Thanks, Elit.
I'm not very good at animation, but I did my best there.
Thank you, thank you.
I used procreate and screenshots.
There you go.
Either way, that was a nice little visual representation of how Valid works.
But there's so much more to it, and we're going to get into that.
So Valid, first of anything else, is a framework for building applications.
It is not a standalone thing on its own that you run.
You, as a programmer, write your app on top of Valid's core.
Or you, as a user, use an app written by a programmer.
Right.
You might be using a Valid app without even realizing it's Valid-powered on the back end.
The whole point is that Valid applications look and feel like every other app out there.
They'll feel like your social media app, your messaging app, your patient portal app.
All the apps that you're used to getting from the app store are generally using some kind of centralized communications model, with servers on the back end.
Our goal is to make apps that have a peer-to-peer communication paradigm, but not require that the consumer of the app is some kind of privacy expert or some kind of networking genius.
So we made this framework to make and lower the bar for development of peer-to-peer applications.
It's an open-sourced Mozilla Public License 2.0 framework that is primarily written in Rust.
So we built on top of a memory-safe, highly cross-platform environment to begin with.
Conceptually, you can think of it as sort of the offspring of IPFS and Tor.
So if you had, like, the distributed storage of an interplanetary file system, but built for highly high-churn, low-reliability networks, like, say, your cell phone, people are using apps that have to work offline.
You can't require a peer-to-peer networking stack that won't work when you drive through the tunnel.
If the network drops, you switch cell towers, your IP address changes, that adds all kinds of interesting complexity to the low level of a framework like this.
It has to just work, despite environmental challenges.
So one of the hard parts of dealing with peer-to-peer is the cryptography is daunting.
If you're going to have a very different non-centralised trust model, you need to have cryptographic support for that.
Valid has a strong crypto background and a core that is built in.
It's opinionated.
We've done our research, so other people don't have to, and we're trying to make it very hard to use the tools we build incorrectly.
It's very easy to throw the crypto stick at things and just get it wrong.
We want to build fully distributed apps.
Unfortunately, Web 3.0 came along and decided for us that the blockchain was the future of the internet or whatever.
Yeah, there's some interesting privacy implications alone for the distributed ledger that can't ever be erased.
I'm not going to go there, but there's also this notion of transactions that people have kind of bought into, and we're trying to reduce the need for a transactional system where you have to buy in to some coin in order to participate in what would otherwise be the future of the internet.
We want people to be able to make user-facing apps.
You can participate and just help the network by running one of our apps, which is a headless node that just runs Valid.
But what you're running is a tiny Rust core that takes maybe 1-2% CPU on average, and at last check, I think it requires 30 megabytes of memory to run and provide the support to the network at large.
So it's extremely thoroughly optimized and the kind of thing that could run on embedded systems someday and designed to be a very tight, not bloated core.
We have bindings for Flutter, Dart, Python, and browser JavaScript.
It runs on Windows, Mac, and Linux, and iOS and Android, and WebAssembly inside a browser.
So all of these different environments are capable of hosting Valid applications.
We first came up with this idea in 2020 and noodled on all kinds of interesting use cases, and we're going to get into that.
It sounds a lot like Pied Piper, right?
Has anyone seen that?
Yeah.
It sounds a lot like Pied Piper, but we're actually going to be doing this in a way that doesn't involve the corporations, because really that, you know, need for money is the downfall in the show.
So yeah.
We'll get into that more.
Yeah.
So we did start a nonprofit to help us, you know, get donations and whatever to help with community and all that.
We presented the idea at DEF CON 31.
We had a nice big crazy party about it.
There were hot dogs thrown into the audience.
Yeah, sorry about the hot dogs.
We didn't open the packages of the hot dogs, we just threw out the whole package.
Anyway, yeah.
So we also started a community on Discord.
Until we can build something better than Discord on Valid, of course, but we amassed a community of, was it, almost 3,000 people and people from all kinds of walks of life, you know, people who have just a passing interest in privacy through to career developers who want a new way to write applications and privacy advocates.
So yeah, this is how it's going.
You got my 10x engineer slide here, right?
Come on, I have little blinky dots.
But we've been working on things like documentation, making this consumable to developers.
We have a book.
It's a wiki-style MD book that you can compile and it's like the Rust documentation.
We have actual published Rust doc for the crates and various other guides on how to set things up on our GitLab.
And to ask people that have built something like this that is huge, highly recommend you document as you go along, because trying to go backwards and document afterwards is the worst.
It, you know, some of the best contributors in our, in our ecosystem and our Discord are the people who are willing to transcribe my rants and just make sure that everything gets captured somewhere.
I can't, I can't thank the community enough for people willing to do that.
Exactly.
And when we talk about the Discord community having diverse members, that's what we mean.
It's not all high-end 10x engineer, you know, developers there.
In fact, we are actually encouraging people that are outside of tech to join in.
Legal, people that know marketing, people that can do animations, because as you saw, mine is not that great.
But all of these things come together.
And if you want to build an app, come join in, and we will help provide the other parts that you might need.
If you're a technical person, we help provide that human element.
If you need help with like legal, we have people that will help you and advise you from there.
And that's what it takes.
It takes a village to build something that is worthwhile.
So Valid is a framework, but it's also a set of core beliefs.
And the biggest one is that everybody deserves privacy.
And when I say everybody deserves privacy, I mean everybody from the, you know, most elite tech people to your grandmother, to sex workers, to people in countries that have, you know, very few privacy laws.
Everyone deserves privacy.
And they deserve it in a way that is accessible to them.
We're going to get more into what we mean by accessible, but essentially, we want to make it so that privacy is as easy for people to use as Google, as Facebook, as all of these companies that have already come in and collected people's data because they made them feel comfortable.
And we firmly believe that the only way to do that is to take capitalism out of the equation, period.
He has his day job.
I have my day job.
None of us are making money from this.
There is no financial incentive for us to build this.
We're building it solely because it needs to be done.
It's open sourced so that it is out there.
We, you know, anyone who wants to can build with it.
We are doing our best to encourage a community of good people to build good things.
But it is a tool.
It's a hammer.
Most people use hammers to build houses.
But every tool is a weapon if you hold it right, according to Anita Franco.
So it is true.
But we are doing our best to build great things.
And we believe in the, you know, the reasoning of it's worthwhile to just build things, period.
If it gets privacy into the hands of everybody, that's worth it.
And if Mark Zuckerberg curses my name at night, I'm happy.
We all have our motivations.
So designing this thing had to be, you know, we had to consider a lot of different risks.
You know, risks to privacy.
We are going to get into all of the challenges of, you know, the environment around a project like this.
Not everyone has a vested interest in making sure that everybody's private data stays private.
So there's a lot of people who, you know, through their own, like, business and through their influence, would oppose a project like this.
So there are risks.
And we have to consider, you know, how to mitigate those through design.
We have to make it very, very hard for people to do the wrong thing, either with the platform or externally against the platform.
So designing for resilience, designing for security first, you know, it's no, you know, we have to assume that people are going to attack the infrastructure as it comes together.
We have to assume that someone's going to profit from it going down one day or having a bad day or having some app expose things that we said, you know, if done right, wouldn't happen.
You know, so we want everyone to be able to use it.
You know, we want to make it accessible.
But we also have to make sure that people can trust it.
And that they can trust their data to it.
So you can see here on this slide here that we did think through, you know, things like memory and type safety and the cryptography.
And that we are designing for resiliency first.
We have some interesting philosophies about security.
You're familiar with full disclosure.
We've gone a step beyond full disclosure.
You know, there's this whole like, you know, responsible versus full disclosure debate that, you know, has churned for the last 20 years in this industry.
We are actually publishing exploits against our own network in our code base.
If you report something to us, we will not just give you credit, we'll help you build the exploit, fix it, and commit your exploit to our repo so that everybody can see your research and to show and to prove that we fixed the issue.
So, yeah, I don't know of any other organizations that distribute the exploit code that's used against them.
So, you know, we're taking things extremely seriously and just have a very different track on this.
We don't have any, you know, we're not going to lose any money because of exploits and things.
We're not making any, so better to show people what we've done through, you know, directly promoting the work that hackers have done to help us get more secure.
So, you know, we're taking things extremely seriously and just have a very different track on this.
So , yeah , I don't know of any other organizations that distribute the exploit code that's used against them.
We're not making any, so better to show people what we've done through, you know, directly promoting the work that hackers have done to help us get more secure.
We need people that are in the room to tell us, okay, hey, this color is probably a better background color because we might be able to see it a little easier.
You know, we talk about accessibility.
We also want to make sure that this isn't slow.
I mean, I love Tor.
I love the concept of Tor.
As you see, we did some, you know, onion routing when I showed that video earlier.
We don't call it onion routing.
We call it ogre routing.
Just because ogres are just like onions.
They have layers.
But we are trying to take the best parts of these things that have already been built, put them together in a way that is usable, fast, and accessible.
Meaning you can use it.
You can use it the same way that you would use any form of Internet.
You can use it on your phone because that's how most people are accessing the Internet these days.
Originally, we had just envisioned things like, you know, secure private messaging.
Which we do have an app in beta for that.
We have discussed future social media projects or a way to store content privately.
These are the things that we thought of, you know, just as a very small group of people when we first, you know, approached this idea.
Since then, the community has brought us some use cases we never even imagined.
They've talked about a decentralized wiki.
You know, a Slack alternative or a Discord alternative.
So that people could have discussions in organized ways.
You know, patient portals.
That's a huge one.
They are something that everybody needs access to, whether or not they are technologically capable.
And they are something that needs to be secured correctly.
We are seeing way too many things, you know, get leaked out into the world about us that don't need to be.
As well as a privileged chat between lawyers and their clients.
Something that has the attorney-client privilege written into the privacy policy or the terms of service.
These are things that people have brought to us along with so many others.
And the things that people have done with Valid are really, really cool.
And we didn't see any of that coming.
I'm going to give you a little tour of some of the apps that other people, besides our core team, have written using Valid as a platform since we got started.
These are all things that others have come to our Discord, brought their own ideas, put a little bit of code in and made something cool with.
Four projects I'm just going to highlight right now.
One is called The Intersect.
It is effectively a decentralized paste bin where you can take messages, post them into the Valid network, and it stores them.
And then you can retrieve them.
There's an app called Vdrop, which stores slightly larger files for retrieval.
An app called Stigmerge, which can be used sort of like a live BitTorrent seed for transferring much larger things and streaming across Valid.
And then there's a game engine that is written, a Rust game engine called Bevy, that has a Valid plugin now that lets you connect gamers across the Valid network.
So yeah, Intersect looks like this.
This is actually a WebAssembly app that runs completely inside your browser.
So if you go to the website, http://intersect.blog, and you'll have to do that without the HTTPS, don't worry, it's still all encrypted.
Valid does its own.
As you go there and you download the app into your browser, it'll run as a WebAssembly blob in the browser itself and create a full Valid node connecting to all of the other Valid nodes over WebSockets.
So it doesn't actually talk back to the server.
You'll note that it's actually hosted on an S3 bucket.
There's no server that it connects to.
It just connects to other Valid nodes in an encrypted fashion.
So you go to the site, you put in the things you'd like to save the world, you hit save, it produces a link, and you can share that link to your friends.
And when they visit that link, it'll show you the Pastebin-style post.
It works with Markdown and renders everything completely in-browser.
There's another app called StickMerge.
This one is actually a native application that compiles to a command-line app.
And you can say things like StickMerge seed and then a file.
It could be a large file of massive size, like a movie or whatever you'd like.
And that running StickMerge on it will produce a key.
And it says there at the bottom, connecting to Valid networks, seeding, blah, blah, blah, blah, blah, to VLD0 colon some Base64 stuff.
If you take that link, it says anyone may download with Distrans is the old name of it, but if you go to StickMerge fetch VLD0 colon that link, it will immediately swarm out, find a bunch of other places that are seeding and it will pull that file over the Valid network in a completely anonymous fashion.
So it's sort of a bit torrent over Valid.
And I think the first file that anyone ever publicly shared across this thing was the movie Chud, cannibalistic humanoid underground dwellers.
That's probably irrelevant to all of you guys, but I thought it was funny.
I think it gives a good idea of how our community is.
We approach these things because it's fun.
This is supposed to be fun.
Another app is called VDrop.
VDrop is similar conceptually to StickMerge, but VDrop actually stores the entire contents of the file on the Valid network through distributed hash table keys.
So instead of just seeding and transferring in real time, you can pop a file up onto VDrop and then weeks later somebody can use that same link to download the contents from Valid.
So it's encrypted.
It's going to get stored on a bunch of different nodes out there.
You don't really get to pick which ones.
They don't know that they're doing it.
Everybody's double blind and you're just storing chunks of files all over the place.
And the file ends up getting broken up into possibly thousands of little pieces, all encrypted, and then reassembled.
And again, this is another WebAssembly-based application.
The way that I always explain how that works, at least to people that don't understand encryption or decentralized versus centralized, so on and so forth, is if you've seen the movie Willy Wonka, at the very end there's this little boy named Mike TV who wants to be on TV.
And he goes in front of that special camera and then he breaks up into tiny, tiny little pieces that fly across the room.
And then it's reassembled over there.
Well, each of our nodes are those tiny little pieces.
So nobody has the full context of anything.
It's all encrypted.
But at the same time, when put back together, it creates a tiny little Mike TV.
And then just really quickly, the Bevy game engine can run over Valid.
So if you have a Bevy app, this guy, Sergey, wrote a checkers app that lets you play with other people across the Valid network.
So in lieu of an Xbox Live or a Steam, you know, multiplayer Battle.net-type configuration that is all centralized, I imagine being able to just connect to other players of your game without having to have some central game network connecting all of your app's users.
So decentralizing for open source gaming is a really cool use case, I think.
So I'd just like to highlight and say thanks to the contributors.
These are people who have done a whole lot for us.
Absolutely.
And there's people that have done... there's so many more that we can list out.
There are people that have helped out with little things, big things.
But the point is that it's a community, everybody's voice is heard.
And the theme of our community, if you'll pardon my language, is fuck around and find out.
If you come in, literally, that's a scientific process.
Try something new and find out how it works.
And if you screw up, you don't have, you know, your CEO breathing down your neck.
You don't have anyone mad at you.
You have not cost your company thousands of dollars.
If you want to try something new, this is the place to go do it.
You know, if it works out, great.
We will add you to this list.
If it doesn't work out, we'll try again.
Talk to other people that know what they're talking about and, you know, collaborate and try again.
Practice makes perfect.
And we encourage everybody that has an interest in something that can build to this to join us.
You're going to find a lot of people with like minds that want to help you, too.
So, yeah.
So, Valid is resilient privacy.
Now, when I mean resilient, you know, he went into the actual resilience when it comes to, you know, a cell phone, changing towers, going through tunnels, so on and so forth.
The network itself is resilient.
But the point is that this is also resilient in a way that could last years and years and years.
One of the main, you know, concepts of Valid was that it doesn't cost money.
It's free.
It doesn't cost us money, either.
Like, it costs us, you know, a couple hundred dollars to, you know, run our personal, you know, nodes.
But that's about it.
Run our website.
You know, that is it.
And the point is that people can develop things on this framework, and they can do that without any cost to them.
The storage.
You don't have to pay for huge amounts of cloud storage.
You don't have to pay for, you know, all the other costs that go into building something.
We're breaking down that barrier so that everybody can build something that is useful, worthwhile, that matters to them without having to take away that, you know, that sacrifice that they would have to make to pay to do that.
And I know there's a ton of, you know, privacy-focused things out there.
A lot of people are probably looking at our messaging program and saying, well, we have Signal for that.
Signal is great.
We love Signal.
Signal also has a six-figure overhead and no income.
So someday, Signal's going to have to make a really tough choice on how that's going to happen.
We just want to be there, you know.
I love, you know, the team over there, and I like, you know, the technology.
We are rooting for Signal Hardcore.
Let us get that straight.
A win for them is a win for us.
But it's also highlighting some risks, you know, when you put, you know, there should be a thousand Signal foundations and Signal apps out there.
But it's all being shouldered by this one company right now.
That's a damn shame, you know.
But in lieu of a bunch of people stepping up and helping and making more, you know, more of that cost become distributed and decentralized, you can't just donate your way out of it, you know.
You couldn't give them enough money to help the growth, you know.
There needs to be technological and, you know, business risk mitigations going on that, you know, are just going to be challenging for any kind of centralized system.
So we're trying to help.
And we hope that, you know, they survive and that we all survive some of the challenges in the environment around us right now.
Absolutely.
We need as much approachable privacy as we can possibly have.
But that is a fair point when it comes to, you know, where is this going to be in a few years.
That's why I say when we built resilient privacy, we built something that's going to outlast us.
We don't need to, you know, we don't need to count on any funding from any one place to make sure that this continues growing, that this continues building, this continues happening.
At no point does anybody have to make the choice.
Am I going to, you know, sell data in order to cover the costs?
Am I going to have to start charging customers in order to cover the costs?
You put advertisement in your app because you need to pay that cloud bill.
Sorry, but, you know, what are you doing, you know?
So, yeah, it's... the point is we're not anti-capitalism.
Do you want to build something with Valid, like a patient portal, and then go sell it to hospitals and make yourself a millionaire?
Cool, do it.
I hope you do.
You know?
Still better than a centralized thing that someone's just going to get owned and all that stuff's going to be out there getting sucked up by insurance companies so they can charge your grandkids because grandma had cancer or something.
You know, it's all garbage.
Yeah, you know, we are looking at a future where someday our grandchildren may be denied health care coverage because you joined a Facebook group to, you know, deal with, you know, do peer support for other cancer survivors or depression or whatever.
Getting hacked should not be a pre-existing condition for denial.
Sorry.
But our entire, you know, online footprint and all these companies that have collected and sold our data, you know, have consequences beyond our own specific lifetimes.
So we want to build something that's going to outlast us, that is going to be, you know, the future.
And we mentioned Web 3.0 before, but really we need to take it back to Web 1.5 where things started going wrong.
So, yeah, what are the risks to actual privacy?
We've covered some of these.
You have personal risk.
I have to make choices personally that, you know, take me, take the risk out of my own personal life so that, you know, as I'm working on something like Baylid, I can't become the, if I were to get, like, removed from the project for some reason, get hit by a bus,
whatever, the system has to be able to continue without me, right?
Physical risks, you know, if you lose your phone, you know, what are the, you know, how are we designing Baylid so that the apps and the data that are on the physical device are resistant to tampering and backup attacks and iCloud, you know, keychain download problems.
I mean, there's all kinds of, you know, risks associated with the, you know, the physical devices that you use.
And so , you know , I think that Baylid should and does have designs in place to do things like, you know, encrypting all of your data using a key that is stored in hardware-backed storage and that that key is encrypted with possibly an offline, never-serialized key so that if you want,
you could lock your copy of your messages with a password that is never actually serialized to disk.
That way if, you know, someone does obtain your phone, if they don't have the ability to rubber hose the password out of you, they won't be able to decrypt the contents.
And the, you know, contents of the network are not even visible to us.
I think that's important to mention too, like we can't see it.
We're not hosting anything, you know, we don't have a, you know, everybody shares this data around, you know, it's, you know, we don't run servers, you know.
So we don't want to be in the position of having someone come to us and say, hand us over all of your servers so we can sift through them.
We don't want to have that risk at all.
So we just designed it so we never needed to have that.
As well as the financial risk.
Everyone involved with the core team of our project has probably, I know at least a few of us have given up, you know, projects that would be financially...
Job opportunities.
Opportunities that would be financially cool, but they wanted, you know, IP for anything that we created during that time.
And we're not going to do that.
We've got to design this in such a way that, you know, it can balance our personal lives and our requirements to life, you know, along with developing something that a lot of people might not want to see developed.
One thing we can't, you know, necessarily guard against is adding a reporter to your war plans group chat.
Yeah.
So I mean, again, you know, we provide the tools.
People can use them the wrong way.
We can't really control that.
But we can also just try to make it harder to do the wrong thing.
So I'm going to just talk a little bit about some of the things that Valid provides to applications.
Secure storage.
We were talking about device level secret storage APIs.
An encrypted table store.
Basically everything, there's a database that is, you know, basically fully row-level encrypted inside of Valid using keys that are only present in the hardware-backed protected store.
That device key can be protected so that backup attacks and dumping-type attacks on a device are much harder to perform or impossible in some cases.
There's a record store, which is our distributed hash table.
This allows mutable data to be synchronized and distributed across our network.
Mutable meaning that we keep track of changes and do automatic change reconciliation across multiple distributed nodes.
It's a challenging problem.
But we have a lot of interesting innovation in the distributed hash table that we've built.
It's effectively search, if you really think about it.
It's like, how do you find all of the bytes and changes to a bunch of bytes across the internet in a performant fashion?
How do you search across a network and collect all of the parts of a thing and update it in a secure, signed fashion so that people can't put up malicious nodes that, say, host old copies of data or data that has been modified in some way?
How do you sign things so that multiple people can write to a co-located record and get a single, consistent view of that data across the internet?
It's a distributed engineering problem that is hard to solve, but we have made some interesting choices in that department and it works pretty well.
You have this multi-write schema-based DHT.
And we're also working on a block store, which is effectively the IPFS-like component, where we're taking large chunks of content-addressable storage and distributing it across nodes that have shown an interest in that data.
So if you download, you know, a couple megabytes of something, you may be responsible for also sharing out chunks of that to others that are interested in it, since you'll have it cached.
The Mike TV.
Right.
Yeah.
So, yeah, the other thing to note is that, in terms of resilience, is that you have to plan for things to become obsolete.
This means cryptography suites, which are notorious for going out of fashion as computing power becomes more strong and, you know, it becomes trendy to switch to cryptography suites for quantum computers or whatever else is coming down the line.
There's a lot of research going into how to break the cryptography that we consider secure today.
This has been, you know, 30, 40 years of research backing up the idea that you shouldn't bake in a single cryptography suite, you should plan on its obsolescence.
So we built into this network multiple routing tables, multiple kinds of cryptographic keys and support for migrating your data from one type of encryption to another and using simultaneous cryptosystems to maintain the availability of your application as we are switching.
So if you have a cryptosystem that we have built today and everyone just uses it, that tomorrow we can introduce a new one and slowly migrate the apps and their data over to the new cryptosystem before we deprecate the old one.
Usually you have at least a little bit of time before you have to just pull the plug on old crypto.
You get a little bit of a warning, you know, you get a couple of years to move everything over before it becomes, you know, the next, you know, don't use SHA-256 anymore or whatever it is.
So, yeah, on the wire, all of the protocols that we do have the same encryption.
We have a suite that, you know, we handpicked and vetted with a bunch of cryptographers that we know, make sure we weren't doing anything stupid.
Everything is time stamped, everything is encrypted and signed.
All of our node information is signed.
This is not the case with a surprising number of peer-to-peer networks out there.
So you can just kind of make up your node identification and somebody else out there could change things about how to reach your node.
So , yeah , that's pretty much it .
We have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is X25519, we have an encryption, symmetric encryption, which is XCHACHA20POLY1305, we have Blake3 as a message digest and we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have
a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have
a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have
a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
So we have a lot of things that we do that does not bode well for long-term resilience.
As of right now, our authentication is based on ED25519, our key exchange is XCHACHA20POLY1305, we have a key derivation hash, which is Argon2.
And you can see here it supports emojis and tacos or whatever, but it does not do media today.
Again, right now we are working primarily on stability and accessibility and we're going to get to eventually things like media and group chats and things like that.
Those are in the design already, they're just going to take some time getting it right.
Like I said, everyone involved has their day jobs.
This is a labor of love.
It's slow-moving because we are doing this in our spare time.
We probably have, what, four active developers on Galachat right now in total.
So it's coming along.
This is as much of a plea for help as it is us talking about what we, you know, being proud of what we built here.
Yeah, not only are we saying, like, this is so great, check it out, but also, like, please help us.
So, yeah, there are in-progress features.
You know, pretty soon you'll be able to share your account between all of the desktop and mobile platforms.
We have localization support as well.
We have people ready to translate the stuff once we are pretty confident that all of the strings are in.
We have lockable and deniable accounts as well.
A deniable account is interesting.
The idea that you could have a password that you know that unlocks a different view of your same account.
So you make an account, and then you make a deniable version of that account that has different contacts and different messages in it.
That way, when you unlock Valid, if it's being done under duress, you can put in the duress password, and it will show a completely different account internally.
And you won't be able to tell the difference that, you know, whether there's one account or if there's multiple accounts.
This way, if someone does decide to rubber hose your phone, or they say you must unlock your phone and show us all your texts, you can type in the duress password and show them something that isn't their actual personal account.
And they wouldn't be able to tell the difference.
And the use case that we had for that originally was, you know, women or people leaving domestic violence situations where somebody is going to their phone.
Unlock your phone.
Just saying.
That is the main use case for that sort of thing.
So, yeah.
All that's missing is you.
Can help us today.
So, yeah.
Like I said, come help us.
Come build.
Come with us.
We'll help you learn something new.
You can try something different.
If you are actively contributing, we would be more than happy to, you know, if you want to go look for a job in that field, like, you want to try...
You can say that you worked for Veiled Foundation.
Yeah, we'll totally do that.
I'll be your alibi.
We'll give you all kinds of job recommendations and shit.
Come help us out.
We'll help you out, too.
Because that's how this works.
We're taking a lot of ideas, like, you know, that come from building community.
Anti-LinkedIn mafia over here.
So, anyway.
If you do want to help but can't code, don't feel like coding, don't have any interest in coding, you can always throw a little cash our way.
We have a 501c3 charitable nonprofit that is there to help develop and distribute this framework and to do things like outreach to help us get to do these kinds of talks and to raise awareness of the problems and how we're trying to help solve those problems.
As well as making Veiled and the network available in places that may not normally have this sort of privacy thing.
So, that involves people, you know, translating and things like that.
And us going to places that we normally wouldn't go.
We've got a pretty low overhead, but every little bit helps.
So , if anyone wants to help, that's one way you can do it.
So, yeah.
You can find us online at all the usual places.
Veiled.com is our website.
We have a Blue Sky account.
We're on Mastodon.
We're still on Twitter.
We're not calling it X.
X, whatever.
Twitter's dead.
It's just dead.
Anyway.
In fact, that was one of the reasons why we started thinking about Veiled.
It was one next bot.
We're kind of like, things are going south.
We need to do something.
And, you know, we're not going to be building a replacement for that.
But maybe we build something.
Maybe someday.
That could help someone do that.
Yeah.
So, we're on Discord.
Our big community is there if you want to meet others that have similar interests.
And the code, as always, is on GitLab.
Feel free to browse through that.
We take merge requests from the community.
And we have all kinds of people willing to help, you know, with the code there.
So, that's where we're at.
That's all.
And that's it.
If you have any questions, you can find us.
Something easy to spot.
Yeah, yeah.
Just come find us after if you want to talk.
Yeah.
A little easy to, you know, just look for the big disco ball.
And thank you for checking us out.
Thank you for not pointing any laser pointers at Caitlin during the talk.
We appreciate it.
Thank you.
It's a safety issue.
All right.
Thanks, everyone.