WEBVTT 00:00.000 --> 00:13.960 So, I will talk to you about a problem that probably most of you already familiar with. 00:13.960 --> 00:21.800 If you want to be in control of your data, then you will probably need to use self-hosted 00:21.800 --> 00:28.600 solutions, but then you lose something of the connecting possibilities. 00:28.600 --> 00:36.600 And if you need connectivity, then you should go with some cloud platforms or federated 00:36.600 --> 00:46.000 services. 00:46.000 --> 00:51.600 So, before we dive in, you can scan this QR code, and you can join the presentation 00:51.600 --> 00:52.600 live. 00:52.600 --> 00:58.320 I hope it will work because we haven't tested with too much people yet. 00:58.320 --> 01:04.720 But I'd like to test it if you would like to participate. 01:04.720 --> 01:12.640 There will be some interactivity at the end. 01:12.640 --> 01:18.840 So when you open it, there will be a name dialogue, but you can simply tap on join. 01:18.840 --> 01:25.640 And then you need to click on the live button at the bottom right corner, and after that 01:25.640 --> 01:38.280 follow, or we have one, only one, two, but if anybody is viewing this online, they can 01:38.280 --> 01:40.280 also do it. 01:40.280 --> 01:55.680 I will wait a few moments, and then I start. 01:55.680 --> 01:59.280 Okay. 01:59.280 --> 02:08.200 So the main problem is what was told about before that if we need control, then we probably 02:08.200 --> 02:17.880 serve host, but then we lose something about the connecting possibilities, and so about 02:17.880 --> 02:22.120 the connectivity, you need to use some cloud or federated platforms. 02:22.120 --> 02:30.440 And the question is, why can't we have both, and some who bridge it to together, so 02:30.440 --> 02:35.080 you don't have to choose. 02:35.080 --> 02:43.360 So the federated platforms seems to be a good middle-grant solution. 02:43.360 --> 02:52.160 You have a bit more control, but there is a serious problem about the identity management 02:52.160 --> 03:00.400 of most of these platforms, because the user identities are usually tied to the 03:00.400 --> 03:04.280 instance, the profile runs on. 03:04.280 --> 03:10.680 So if you want to move to another instance, then your identity changes, and when your identity 03:10.680 --> 03:18.560 changes, it usually means that your connection is lost. 03:18.560 --> 03:28.080 So we were thinking about a platform, and what we are coming up with is that basically 03:28.080 --> 03:36.360 connections shouldn't be between instances, it should be between users. 03:36.360 --> 03:47.640 So what we saw is what if we change the usual identity notation, this user at provider.net, 03:47.640 --> 03:57.920 and move the app symbol to the front, which seems like a typography change, but you probably 03:57.920 --> 04:04.680 know that it's more than that, because it means that we move the identity to the domain 04:04.680 --> 04:10.080 M system, and exactly this is what we have done. 04:10.080 --> 04:22.640 So we create a platform where anybody can create their own self-hosted tiny server. 04:22.640 --> 04:29.520 They can invite their friends, family, basically anybody, and they can create profiles on 04:29.520 --> 04:34.160 this servers, and use it stored their data there. 04:34.160 --> 04:40.400 But if they later decide to move to another provider, or they want to create their own server 04:40.400 --> 04:48.640 at home, then they can move their profiles to their own server or the other provider, and 04:48.640 --> 04:57.280 they don't just migrate their data, but they can migrate order connections, and they 04:57.280 --> 05:08.040 can also migrate order post-rites, basically everything that's on the platform. 05:08.040 --> 05:11.640 So let's talk a little bit about implementation. 05:11.640 --> 05:18.240 Cloudy allows backend is a rest application, not because it's trendy, but because memory 05:18.240 --> 05:28.720 safety matters, performance matters, security matters, and we want it to create a really tiny 05:28.720 --> 05:37.640 and efficient solution, so it basically can run everywhere on a Raspberry Pi or 05:37.640 --> 05:43.840 Nest device or even on your router. 05:43.840 --> 05:53.560 Well, another option is to run it on a GPS, it runs on the GPS one, I think. 05:53.560 --> 06:00.800 CloudyLow is an application platform, and applications on CloudyLow are very strictly 06:00.800 --> 06:03.680 sandboxed. 06:03.680 --> 06:11.440 There is the CloudyLow shell, it's the main application that they use as log into, and 06:11.440 --> 06:20.760 it contains the basic functionality, the file manager, communication feeds, the sort of 06:20.760 --> 06:28.440 things, and it opens other applications, these other applications run in sandboxed 06:28.440 --> 06:37.600 eye frames, and very restricted, for example, a document editor can only access that one document 06:37.600 --> 06:39.520 it is working with. 06:39.520 --> 06:47.200 So it doesn't even see the file system or any other thing that it doesn't need to. 06:47.200 --> 06:57.480 It's really important, especially nowadays, when even ordinary people can create wide-coded 06:57.480 --> 07:07.600 applications, and these wide-coded applications can be secure on CloudyLow, and users 07:07.600 --> 07:14.200 can use that without high risks. 07:14.200 --> 07:23.600 So this is our architecture in a glance, there are the CloudyLow nodes, these nodes can talk 07:23.600 --> 07:29.120 to each other, and these connections are based on the user identities. 07:29.120 --> 07:37.320 So these nodes find each other through the user where they want to connect to, and the 07:37.320 --> 07:44.040 CloudyLow client can connect to multiple nodes, and access documents or any information 07:44.040 --> 07:46.840 on any node. 07:46.840 --> 07:54.520 Okay, so where we are, and what we already have. 07:54.520 --> 08:01.520 Our backend is basically a general operating system. 08:01.520 --> 08:08.480 So it doesn't really involve itself with specific documents, structures or these sort 08:08.480 --> 08:09.480 of things. 08:09.480 --> 08:16.960 It basically provides a file system API, CRDT API for collaborative documents, real-time 08:16.960 --> 08:22.400 database, and a lot of other stuff. 08:22.400 --> 08:30.800 On the front end, we have the shell application with all the functionality that's included 08:30.800 --> 08:41.840 in there, and we have a few client libraries to communicate with the CloudyLow APIs, 08:41.840 --> 08:54.240 and there are some UI libraries, especially for canvas applications, and we have some apps. 08:54.240 --> 08:58.640 I mentioned the four most important ones. 08:58.640 --> 09:06.000 We have a world processor, spreadsheet, this presentation application that we are using, 09:06.000 --> 09:11.640 and we also have a wide board application for drawing. 09:11.640 --> 09:22.360 Okay, now we can try a live pool, I see we have lost some users, but there is the QR code 09:22.360 --> 09:31.560 again, so if anybody wants to join again, you can, and it's not really about the question, 09:31.560 --> 09:45.520 it's a demonstration of what we are experimenting with. 09:45.520 --> 10:01.120 So it can manage at least 10 users, it's not so bad, and it haven't frozen yet, okay, 10:01.120 --> 10:11.520 so I think I have quite a many time, so I can show you some of the platform just to look 10:11.520 --> 10:18.120 at it and how it looks and get the feeling of it, and we can also have some questions 10:18.120 --> 10:37.520 after that, okay, I see something is wrong with the numbers, somebody is already hacking, 10:37.520 --> 10:50.320 but that's okay, okay, so we are CloudyLow, we are open source, we have no funding yet, 10:50.320 --> 10:59.360 so if anybody can help with us, help with that, that would be appreciated, and also our main 10:59.360 --> 11:09.240 problem is to make the architecture design more mature, so we are looking for software architects 11:09.240 --> 11:23.120 who can help us to stabilize and review and plan the future of CloudyLow's architecture, 11:23.120 --> 11:35.880 and we are also interested in people who are just one to try out the platform and give us some feedback, 11:35.880 --> 11:41.840 okay, so you can go to CloudyLow.org, if you are interested, you can access everything from there, 11:41.840 --> 11:51.160 or GitHub, or Docker images on Docker, we don't have a really large community, but you can join 11:51.160 --> 12:05.400 us on this code and we can communicate there, and I think I show you a few things, I don't want 12:05.400 --> 12:18.360 to go too deep to anything, so this is the main screen, so this is the shell, when you log 12:18.360 --> 12:34.120 into CloudyLow, you get that, and you can see that CloudyLow uses for every user on domain name, 12:34.120 --> 12:51.520 and I can open any document properly, hopefully, what they used to say, it worked on. 13:04.120 --> 13:18.200 Okay, passively, we will have more time for questions, yeah, I have increased the rate 13:18.200 --> 13:34.080 limiting in case there will be any problems, but I try a few more, okay, so I can show 13:34.080 --> 13:40.560 something in the shell itself, so that is the file manager, and you can see most of the files 13:40.560 --> 13:50.720 are mine, but I can also have files from other users, this file is some proof about the presentation 13:50.720 --> 13:58.440 from my UX designer, and possibly I could open it with one click, it doesn't really matter 13:58.440 --> 14:15.120 where that file is, and we have a simple social feed, communities, we have messages, direct 14:15.120 --> 14:38.600 messages, groups, and we have some people, so I think that's all for now, I have a few 14:38.600 --> 14:57.360 words, six minutes for questions, okay, this is why we are using, yeah, sorry, so this is 14:57.360 --> 15:03.760 about how they are connecting to each other and how they find each other, so this is the most 15:03.760 --> 15:12.120 important part about the identity, oh, it worked, so we are using the domain name system as 15:12.120 --> 15:22.000 user identity, because it not only helps us to identify users, but it also can have to find the 15:22.000 --> 15:28.200 nodes of the users, so every user identity points to the node where the user lives, and if 15:28.200 --> 15:36.960 they use their moves, then their identity follows their profile, so the nodes don't connect 15:36.960 --> 15:47.000 to other nodes, they are connected to other users, and that's the main point, okay, any other 15:47.000 --> 15:49.000 questions, yes? 15:49.000 --> 15:58.200 We would like to migrate, so how would that work to export to the data or, it doesn't really 15:58.200 --> 16:08.480 exist yet, we are working, sorry, so how the migration works and how we migrate the data 16:08.480 --> 16:18.000 exactly, we are still working on the protocol, but we are creating a protocol for that, 16:18.000 --> 16:26.240 so you can create your new instance and basically link the two instances together, and 16:26.240 --> 16:35.560 they can do it themselves, so on Cloud Zero, everything is automatic, no manual thing, we even 16:35.560 --> 16:46.000 have an identity provider system, so users can create their identity inside the platform, if 16:46.000 --> 16:59.040 they provide the DNS provider support it, okay, other questions, oh, it's great, everybody 16:59.040 --> 17:14.000 understands everything, okay, possibly I can try to show a few some, some more apps, okay, 17:14.000 --> 17:20.440 so I'm very much interested in everything, it's federated also with the users and the apps, 17:20.440 --> 17:28.000 currently there are different things, I mean there's the home, first of all, there's the yours 17:28.000 --> 17:33.960 and others, how do you see the future of like having this different identity, so if you 17:33.960 --> 17:39.760 merchant them together on, no, currently it's getting very splintered, and I think it's great 17:39.760 --> 17:46.760 to have ideas with your better than anybody else's, you also, how do you put this together, 17:46.760 --> 17:54.400 how do you make it federated, that word, sorry, yeah, so the question is about who to integrate 17:54.400 --> 18:01.560 all these different platforms together, and it's a really hard one, because there are quite 18:01.560 --> 18:08.440 a lot of good platforms, I really like the idea of local first platforms, for example, and 18:08.520 --> 18:17.400 also there are the federated ones, and the most important thing I think is trust, so the 18:17.400 --> 18:24.840 different systems need to be able to trust each other, so CloudiLo currently can trust 18:24.840 --> 18:33.840 its own identity system, because that way, so everything is signed if two users are connected 18:33.840 --> 18:40.480 and interact with each other, and this way we can fully eliminate spam and advertising 18:40.480 --> 18:47.200 and basic re-uniting, so the only thing an unknown user can do with me is to send me a 18:47.200 --> 18:55.640 connection request, and it's really hard to do that with other platforms, because I have 18:55.760 --> 19:06.760 to trust those other platforms, so this is the main program, technically it's easier, I think. 19:06.760 --> 19:13.760 Okay, next question, first question? 19:13.760 --> 19:18.200 Just connect to a question, because I think it's really essential, one would not be 19:18.280 --> 19:23.880 possible to make more sense, following your model or the actual show we like, and solving 19:23.880 --> 19:31.160 in the domain name, to send lots of trust, other platforms, but other new things, so yeah, 19:31.160 --> 19:39.400 and instead of trusting other platforms and all the platforms, it would not be possible to trust 19:39.480 --> 19:45.080 the users, like we've talked before, can we pass it over to you? 19:45.080 --> 19:52.760 Yeah, it can be possible, so we were thinking about integrating with other identity systems, 19:52.760 --> 20:01.240 so for example, the IDs are mostly key-based, so everything can be signed and we can't trust 20:01.240 --> 20:05.080 those, but we can't connect.