All right, so we're still all learning.
One thing we learned is how to make the microphone louder.
I think that's great.
So we made progress.
We're still in the same session, basically.
So we really didn't really have a break now.
And we're continuing with, in this area of self-hosted,
like, or hosting stuff with the project Eileen,
which is about self-hosted digital islands.
And Ryan Gibb is going to present about this.
So round of applause for Ryan, please, and enjoy the talk.
Thank you.
Is it night working?
Yeah, that seems to be working.
All right, I'm going to give you a talk on this project called
Eileen, which means island in Scottish gay.
The reason for that is, it's, it's, but your digital islands.
So basically, the problem I see is our digital lives are increasingly
fragmented across many centralized online services.
This model concentrates power, leaving us with minimal technical control
over our personal data and online identities.
The long-term permanence of these platforms is uncertain.
And the commercial incentives are often misaligned with their users,
which this RFC from marketing and kind of goes into a little bit more.
And a solution that I propose for this is,
inverting this model.
Instead of centralizing our data in these proprietary silos,
let centralize our presence under our own control
using open federates and services.
We describe digital islands, or islands, which are self-hosted hubs
for an individual or communities online presence.
By hosting these services ourselves,
we regain our autonomy and control in the internet.
So, I lean as a project designed to simplify the creation
and management of these digital islands.
The core idea is to parameterize a complete operating system deployment
by a domain name and a set of services that we want to run.
This allows us to easily deploy our own instance of such services.
For example, matrix, massodone, email,
called out for calendaring a VPN.
Things I'm sure you're all familiar with.
How many people are self-hosting any of these services?
Can we get you a chance?
Okay, that's a good amount, but it can be better.
So, I took a look around the state of the world.
And I thought about how can we make it easier to use these services.
I had to look at some things like Ansible and other things,
but Nick sauce seemed like the best solution to enable the
reproducible deployment of these services.
They still require a lot of setup in addition to what the Nick sauce
module system provides, though.
You needed to go into some external system to create domain names,
other DNS records, sometimes you need to configure
user accounts manually, databases, HTP Proxies,
sometimes the elastic of kits.
So, I lean is essentially a set of opinionated Nick sauce modules
to enable the simple deployment of these services.
A lot of it, I have hopes to eventually upstream to Nick sauce,
but a lot of it is a little too opinionated to do so.
So, one big thing in deploying any services,
you need a domain name for it.
So, the Nick sauce module system cannot do this for you
if you are not hosting your own domain name.
For example, you need to go to your DNS provider and
do some sort of dance between your email setup and your
registrar and fit in various decim,
the smart SPS records as well as the domain names, obviously.
So, what Eileen does is self host the author of DNS for your domain.
So, I don't know how familiar the room is with DNS,
but who is hosting their own authority in a server?
Good reaction of fans.
Less than the last time, who is using DNS?
Who has a DNS record set up?
Okay, 50, 50, maybe.
So, basically, Google.com, whatever.
This is the main name and it is a global decentralized system
that we use to configure these key value stores, essentially.
So, what we can do with Eileen is for a service such as the mail server,
when the service is enabled.
So, make if you configure mail server to enable,
we can automatically create all the DNS records that we might need for that service
in the next office module itself.
So, it is declarative DNS through Nick sauce module essentially.
There is more experimental integration with a name server that can
also provision the TLS certificates via Captain ProtoRPC.
This is useful when you might be behind a VPN or not running a publicly accessible
web server.
So, some examples of how you might use this is using a matrix server
and deploying a bunch of bridges.
And we aim to be as simple as that.
So, we aim for a score of 100% on the internet.nl security testing.
Very much useful.
And I think that my time is up, so thank you.
Thank you.