So, I will talk to you about a problem that probably most of you already familiar with.
If you want to be in control of your data, then you will probably need to use self-hosted
solutions, but then you lose something of the connecting possibilities.
And if you need connectivity, then you should go with some cloud platforms or federated
services.
So, before we dive in, you can scan this QR code, and you can join the presentation
live.
I hope it will work because we haven't tested with too much people yet.
But I'd like to test it if you would like to participate.
There will be some interactivity at the end.
So when you open it, there will be a name dialogue, but you can simply tap on join.
And then you need to click on the live button at the bottom right corner, and after that
follow, or we have one, only one, two, but if anybody is viewing this online, they can
also do it.
I will wait a few moments, and then I start.
Okay.
So the main problem is what was told about before that if we need control, then we probably
serve host, but then we lose something about the connecting possibilities, and so about
the connectivity, you need to use some cloud or federated platforms.
And the question is, why can't we have both, and some who bridge it to together, so
you don't have to choose.
So the federated platforms seems to be a good middle-grant solution.
You have a bit more control, but there is a serious problem about the identity management
of most of these platforms, because the user identities are usually tied to the
instance, the profile runs on.
So if you want to move to another instance, then your identity changes, and when your identity
changes, it usually means that your connection is lost.
So we were thinking about a platform, and what we are coming up with is that basically
connections shouldn't be between instances, it should be between users.
So what we saw is what if we change the usual identity notation, this user at provider.net,
and move the app symbol to the front, which seems like a typography change, but you probably
know that it's more than that, because it means that we move the identity to the domain
M system, and exactly this is what we have done.
So we create a platform where anybody can create their own self-hosted tiny server.
They can invite their friends, family, basically anybody, and they can create profiles on
this servers, and use it stored their data there.
But if they later decide to move to another provider, or they want to create their own server
at home, then they can move their profiles to their own server or the other provider, and
they don't just migrate their data, but they can migrate order connections, and they
can also migrate order post-rites, basically everything that's on the platform.
So let's talk a little bit about implementation.
Cloudy allows backend is a rest application, not because it's trendy, but because memory
safety matters, performance matters, security matters, and we want it to create a really tiny
and efficient solution, so it basically can run everywhere on a Raspberry Pi or
Nest device or even on your router.
Well, another option is to run it on a GPS, it runs on the GPS one, I think.
CloudyLow is an application platform, and applications on CloudyLow are very strictly
sandboxed.
There is the CloudyLow shell, it's the main application that they use as log into, and
it contains the basic functionality, the file manager, communication feeds, the sort of
things, and it opens other applications, these other applications run in sandboxed
eye frames, and very restricted, for example, a document editor can only access that one document
it is working with.
So it doesn't even see the file system or any other thing that it doesn't need to.
It's really important, especially nowadays, when even ordinary people can create wide-coded
applications, and these wide-coded applications can be secure on CloudyLow, and users
can use that without high risks.
So this is our architecture in a glance, there are the CloudyLow nodes, these nodes can talk
to each other, and these connections are based on the user identities.
So these nodes find each other through the user where they want to connect to, and the
CloudyLow client can connect to multiple nodes, and access documents or any information
on any node.
Okay, so where we are, and what we already have.
Our backend is basically a general operating system.
So it doesn't really involve itself with specific documents, structures or these sort
of things.
It basically provides a file system API, CRDT API for collaborative documents, real-time
database, and a lot of other stuff.
On the front end, we have the shell application with all the functionality that's included
in there, and we have a few client libraries to communicate with the CloudyLow APIs,
and there are some UI libraries, especially for canvas applications, and we have some apps.
I mentioned the four most important ones.
We have a world processor, spreadsheet, this presentation application that we are using,
and we also have a wide board application for drawing.
Okay, now we can try a live pool, I see we have lost some users, but there is the QR code
again, so if anybody wants to join again, you can, and it's not really about the question,
it's a demonstration of what we are experimenting with.
So it can manage at least 10 users, it's not so bad, and it haven't frozen yet, okay,
so I think I have quite a many time, so I can show you some of the platform just to look
at it and how it looks and get the feeling of it, and we can also have some questions
after that, okay, I see something is wrong with the numbers, somebody is already hacking,
but that's okay, okay, so we are CloudyLow, we are open source, we have no funding yet,
so if anybody can help with us, help with that, that would be appreciated, and also our main
problem is to make the architecture design more mature, so we are looking for software architects
who can help us to stabilize and review and plan the future of CloudyLow's architecture,
and we are also interested in people who are just one to try out the platform and give us some feedback,
okay, so you can go to CloudyLow.org, if you are interested, you can access everything from there,
or GitHub, or Docker images on Docker, we don't have a really large community, but you can join
us on this code and we can communicate there, and I think I show you a few things, I don't want
to go too deep to anything, so this is the main screen, so this is the shell, when you log
into CloudyLow, you get that, and you can see that CloudyLow uses for every user on domain name,
and I can open any document properly, hopefully, what they used to say, it worked on.
Okay, passively, we will have more time for questions, yeah, I have increased the rate
limiting in case there will be any problems, but I try a few more, okay, so I can show
something in the shell itself, so that is the file manager, and you can see most of the files
are mine, but I can also have files from other users, this file is some proof about the presentation
from my UX designer, and possibly I could open it with one click, it doesn't really matter
where that file is, and we have a simple social feed, communities, we have messages, direct
messages, groups, and we have some people, so I think that's all for now, I have a few
words, six minutes for questions, okay, this is why we are using, yeah, sorry, so this is
about how they are connecting to each other and how they find each other, so this is the most
important part about the identity, oh, it worked, so we are using the domain name system as
user identity, because it not only helps us to identify users, but it also can have to find the
nodes of the users, so every user identity points to the node where the user lives, and if
they use their moves, then their identity follows their profile, so the nodes don't connect
to other nodes, they are connected to other users, and that's the main point, okay, any other
questions, yes?
We would like to migrate, so how would that work to export to the data or, it doesn't really
exist yet, we are working, sorry, so how the migration works and how we migrate the data
exactly, we are still working on the protocol, but we are creating a protocol for that,
so you can create your new instance and basically link the two instances together, and
they can do it themselves, so on Cloud Zero, everything is automatic, no manual thing, we even
have an identity provider system, so users can create their identity inside the platform, if
they provide the DNS provider support it, okay, other questions, oh, it's great, everybody
understands everything, okay, possibly I can try to show a few some, some more apps, okay,
so I'm very much interested in everything, it's federated also with the users and the apps,
currently there are different things, I mean there's the home, first of all, there's the yours
and others, how do you see the future of like having this different identity, so if you
merchant them together on, no, currently it's getting very splintered, and I think it's great
to have ideas with your better than anybody else's, you also, how do you put this together,
how do you make it federated, that word, sorry, yeah, so the question is about who to integrate
all these different platforms together, and it's a really hard one, because there are quite
a lot of good platforms, I really like the idea of local first platforms, for example, and
also there are the federated ones, and the most important thing I think is trust, so the
different systems need to be able to trust each other, so CloudiLo currently can trust
its own identity system, because that way, so everything is signed if two users are connected
and interact with each other, and this way we can fully eliminate spam and advertising
and basic re-uniting, so the only thing an unknown user can do with me is to send me a
connection request, and it's really hard to do that with other platforms, because I have
to trust those other platforms, so this is the main program, technically it's easier, I think.
Okay, next question, first question?
Just connect to a question, because I think it's really essential, one would not be
possible to make more sense, following your model or the actual show we like, and solving
in the domain name, to send lots of trust, other platforms, but other new things, so yeah,
and instead of trusting other platforms and all the platforms, it would not be possible to trust
the users, like we've talked before, can we pass it over to you?
Yeah, it can be possible, so we were thinking about integrating with other identity systems,
so for example, the IDs are mostly key-based, so everything can be signed and we can't trust
those, but we can't connect.