 Hello, everybody. Great to see so many people here in the room. I'm really surprised how many people are interested in the whole topic about decentralizing the internet, and also how many people stay still in front of the door and want to come in. That's really amazing that so many people are interested in this whole topic and all the stuff with this Cassio the whole day. That's really amazing. My name is Bjorn. I work at OnCloud, and backslowed at the moment, but I started OnCloud already three years ago to think about how Cloud Federation could work how we could set up Clouds, which works together in a decentralized way. And then we developed this with OnCloud, and then I went over to NextCloud, and we developed this word, and I just want to present you how all this works, what we already have today, and especially also what's our plan for the future, what we want to move to. Did some already use OnCloud or NextCloud here in the room? And you already tried to use the federated sharing feature? Oh, OK, quite some people. That's really nice. So just some introduction. As you know, the internet, as it started at the beginning, it was all decentralized. Everybody could set up their own web server or its email server, and they could all communicate with each other. But then at some point in time, we entered the dark age of the internet, how I would call it, where we moved to more and more centralized servers. And if you look a few years back, honestly, even today, if you look at the mass market at 90% of the users, if they want to store their files and to sync them with their devices and share them, they normally go to two or three vendors which are out there, which is mainly Apple D-Stay, Google's, or Dropbox, where they put their files in there and then they can do all this stuff. And then they have, of course, all this in one centralized server, which on the one side is nice because they all, of course, know how to develop software. So there's a nice, shiny interface. This works all great, and all people are there so we can collaborate with all of them. So it looks quite nice, but of course, it raises a lot of questions about privacy and who controls the data and who has access to it. So a few years ago, some projects started to develop free software cloud solutions, which everybody can host by their own and install their own cloud server to do basically the same. And I think this was a great work from all the projects out there which did this because there appeared a lot of great software. And then people start to set up their own server, be it an own cloud server, next cloud server, and Pydio, and Z-File, whatever you name it. And people just start to upload their files, sync their contacts and calendar with their own devices. And everything works nice as long as they state on their own server or start to collaborate with the few people on the server. But especially if you think this as a few steps further, for example, like projects like the FreedomBox, where we think about maybe a point in time where everybody has a small box at home where he has all his cloud services, then the number of users on one of the service goes down to nearly one, maybe two or three, depending on how many people live in your building. And then, of course, it was really fast to get into the situation that you want to share with someone, a file, or want to collaborate with someone, but he's not on your server at home, but he has his own server. And so the question is, how can you collaborate with these people in a way that is as good integrated and as seamless as if the user would be on the same server? So that's the challenge. And that's where we came up with the idea of Cloud Federation, where he said, OK, we need a protocol a way to create a bridge between the server so that a user or a monitor server can share with a user on the other server and work with them together on some files or collaborate. And for the user, it should be completely transparent. For the user, it shouldn't matter if the other user is on the same server or different server. To achieve this, we have invented the idea of a federal Cloud ID, which looks quite similar to an email address, because we thought, OK, that's most people are familiar with. They know how to handle it, how it looks like. So it's basically the user on your Cloud Server and then add the URL of your next Cloud Server. And then we developed some REST API, which is quite small. It's just four to five calls, basically, where you can send and share invitation to a different Cloud Server. And then you can accept or decline it. And then you have requests to unshare it or to change permissions or send a notification. But this really small API is easy to implement. And once this invitation is accepted, once a user on the other server accepted your share, then we create a normal web dev mount. For us, it was really important at next cloud all the time that we don't want to reinvent the wheel. So whenever there is a standard already out there, which is also widely used, we try to use it. Because I think that's the best way to make it available to many people on different projects. So we choose that even if we know, especially for syncing and stuff like this, it has some limitations. But we saw that it's the widely used and standard and most easy to implement for most of the people. And as I said, we don't want to create the next island. If this would be only implemented with next cloud, then, of course, then all the next cloud could work with each other or all the own clouds. But we would still generate an island. The island would be just bigger. It was the island of all the next clouds or all the own clouds. And you could interpret across these different cloud solutions. So for us, it was always really important to also implement this in as many solutions as possible. So at the moment, as of today, no matter if you have installed a next cloud server or a Pydio server or an own cloud server, you can do this federated sharing across all the servers between the users. It doesn't make a difference. All these three solutions already implemented it. And I just talked last week with some C-File developers, which are also really interested in this. So the chance existed maybe in one year or something. This will also work together with C-File. So let me show some screenshots and explain how this works also a little bit historically because we moved from a simple implementation and then advanced it over time. This all started with the idea next cloud always had this public links. If you want to share with someone outside of your next cloud, you could create a public link and then put it in an email or something and send it to someone and then the person could open the link in the browser and access the file or the folder you shared with them. And then our first step was said, OK, if you send someone such a link, then add an add to your next cloud button at top of it. If the user also has a next cloud, he can click the add to your next cloud button, enter his cloud ID. And then in the first version, it was then just directly created in Webdavmount from this file to the other users' next cloud. So then it was seamlessly integrated in his next cloud file listing. His sync line started to sync it and it was already a great step forward to what we want to achieve. Then in the next iteration, we changed this a little bit to not create this Webdavmount directly. But nowadays, if you do this at least on next cloud, it's not implemented in own cloud in PyDio yet, but in next cloud. If you go on this open public link in Adio cloud ID, then we don't create this public Webdavmount directly, but then we ask the server from the file, please make a federated share with the other user on the other server. Besides many advantages, one is that the owner of the file can keep track who has mounted his public link to his next cloud because in his share list, he will then see all the people who click this add to my next cloud button and mounted. So then the owner of the file can control the permissions, for example, which permissions that the different people have on the file and can remove one of these mounts again. So this makes it already way nicer to integrate. And of course, the next step, we didn't want that people first have to send it out at this public link and then people can add to next cloud. So the next step was to integrate this in the share dialog we have in next cloud if you are logged in. You have a dialog where you can share with internal users and group where just type in the name and then you have also nice auto completion and then you share with the user on the same server. And there we allowed now to also type in the very cloud ID like you would type in a local user and then the file gets shared to the user on the other server. And again, you have then your listing with the people who have access to the file, all the people, also the internal people and the external people and can control all the permissions and revoke the access again and stuff like this. This works quite nicely except for one thing, group shares at the moment are not impossible. But we are also thinking about how we can solve this problem that you can also address a group on the other server so that if we want to share with a working group which is on a different server, you don't have to share it one by one by every person in the group, but you can also address the group directly on this other server and share with the group. Another problem then, okay, at this point it already worked quite nicely and was quite integrated but another big problem was always how to find people because to share with someone I need to know the very cloud ID. And there we thought about many different things, also partly some stuff which was just discussed before me in the matrix talk. I think we made a thing about quite similar problems and maybe it also makes sense to discuss this and see if we can maybe even have a common solution for this. One first step we did and which is already implemented for quite some time in next cloud and own cloud and Pydio now also implemented at the moment is the concept of trusted servers. So this was a request from mainly research institutes which has many next cloud installations on different institutes and if people want to work together they want to somehow have them in the shared dialogue, auto completion of all the people no matter on which cloud they are. So there the administrator of the next cloud server can add trusted servers which they know for example they are in the same research institute or in the same department or the same university. These are the servers I trust and if the other admins adds the same server then they start to exchange an authentication token and then use this to synchronize the user lists. So then all trusted servers know the users from the other trusted servers and then you can find them in your auto completion and share seamlessly with them. And if you want to go one step further you can also enable it that whenever you create and federated share successfully with a user on a different server then your server automatically adds the server to your list of trusted servers. That's basically the idea that as soon as you have created one valid share with a user on the other server then you can somehow assume that the other server is not a completely spam server or a completely stupid server but then there are users which are really valid users you want to work with. So if you want you can enable it and then your network of trusted server basically grows over time and you will know more and more people you can share with. Then we want to take this one step further that's what we implemented now just recently a few weeks ago with next cloud 11 and we want to move this forward with next cloud 12 in a few months and this is some kind of a global address book so we extended the profile page of the user you have in your next cloud where you can not only add your full name and your email address but you can also use all the other stuff you need you know from context like your phone number your address, your Twitter handle your website and stuff like this and then we allow you to define the visibility of all of this information. By default of course everything is private so nothing happens it's just there for you but you can decide to set it in able to context this means that it will sync with the trusted servers of your next cloud or you can set it to public and if you set it to public it will sync to a global address book server which is the same as at matrix at a moment centralized and we are looking in ways how to solve this problem but then your data are published the data you want to make public are published on the server together with your cloud ID and then people again can find you and share with you. And we want to use the Twitter handle and the website we want to use to do there some verification a little bit similar like Keybase that you can sign your presence there and then you can verify that the person is really the person you want to share with but of course we also need to think further like ideas like or also verify your email address your phone number as said in the talk before would be really interesting to verify but it's not that easy problems to solve as you may already guess when you heard the last talk so our next step is that we want to move from the central server over to a federated server so that you can like you can set up your own next cloud everybody can set up his own address book server and then configure in his next cloud to which server you want to contact which way you want to contact if you have a request and therefore basically we have two ideas once if you look at big customers at next cloud big companies or research institutes they may want to have just one lookup server or address book in their institute which all their next clouds connect to but which doesn't federate to the outside or it's completely valid that you just find the people in your own organization or you can decide that you are part of the global network and federate with all the other servers out there and exchange the data so how we sort in the first step somehow we solve the problem that we authenticate the user and make sure that you share with the right person at next cloud already every person every account has a private public key attached to it so our idea at the moment is that before we send the data to this address book we could sign with the private key and then a valid address book server would only accept updates from the user if it changes email address or if it changes something only an update would be accepted it's still signed again with the same public same private key and you could at the same time use the Twitter and homepage verification to also make sure that the data set is signed with the same key like the homepage and the Twitter account and stuff like this and to exchange these public keys we just sort about to do some kind of trust on first contact because we sort the time where you share the first time with a user on a different next cloud is quite a random timestamp right once we get into this communication it's really hard to guess when this happens this first share so we assume that this is a relatively secure time point in time where this happens and for your first share you also are sure that you know to whom you share your files basically and so at the first share when the share connection gets established you also get a public key from this user from the server back so then every time you share again with this user every time you get an update from the address book from some data of the user you can use the public key to verify a signature and as long as the signature is the same you assume okay it's still the same user you are in contact with and if it changed then you know that basically something happens the admin of the lookup server changed something in the data or maybe someone managed to upload some false data so that's an idea we want to try out if it works and just want to push this forward and see how this works at the end so why are we doing this with this global address book I think there are a few benefits one of course as I said at the beginning it makes it way easier to find people to share with and I think that's a big problem we all in the decentralized world have to solve somehow how do you find people if they are not on the same server and this is one approach we want to try to investigate if this is a feasible way to do it and one thing which is also especially important for us is if this works this would allow people to migrate from one server to another so if you if you have your own next cloud server and you just change your domain for example or if you choose a next cloud provider and at some point in time you want to go to a different provider you could just migrate all your data to the next provider including your keys and if you are on the next provider you push an update of your data set if you know new federal cloud ID and then all the existing shares could adjust to the new cloud ID and also the new shares you do after that could be directly end up at the right user account another problem we need to solve at the moment at next cloud is that especially in research institutes you often have an held up backend to authenticate the users and it's quite typical that users use their email address to authenticate at the next cloud server and then the cloud ID becomes quite ugly because then you have two ad signs in it because at the front you have the email address with the ad and then you have another ad which refers to the server so that's a pain we heard already for years from users that we solved somehow and we thought about it and we came up with two solution we want to implement now in next cloud 12 one is that we want to allow the administrator to define a pattern how the first part of the cloud I should look like so in this use case an admin should just define that for every user ID we strip the ad from the email address and the email server and just use the first user identifier and the cloud server or the next approach will be that we allow in his profile settings choose a complete random cloud ID however they wanted to look like as I said the admin approach would be for a whole server but he would define a pattern how to do this and then of course the admin would need to take care that he doesn't create any name collisions for the cloud IDs and the server could relatively easy resolve this for the user part we thought that it would be quite nice because many users already have the email address also for example XMPP address so it would be really nice if you could use again the same address to also use it to share with people so they have one unique address where you can email the people you can chat with them and you can share files with them so that was the motivation of this and there we thought okay if you put your own cloud ID into your profile settings then you could put on your server if you control the domain either a well-known file which starts redirect to the real cloud server or maybe even DNS entry which starts the redirection and then if you do a federated share with this email address basically we would just look there if there is the well-known file we then would make the share request to the real cloud server instead of to the local server and the cloud server would provide an API to then resolve just this user defined cloud IDs to the real cloud ID which matches also the server which is out there and of course now I talked a lot about federated sharing with files but I saw that many people already use next cloud and own cloud with next cloud and own cloud you can do much more than files you can also have your context there your calendar and next cloud we work really hard to bring web conferencing to next cloud so that you can call with conferences people and want one calls and stuff like this and we want to move federated sharing also in this area so our goal is that in the future you will also be able to share a calendar just to a different user on a different server or an event or you can share an address book to a different server and of course with the whole video conferencing at the moment if you try it out you can just call basically an user on the same server or group on the same server or you can create again some public links you know from webRTC which you send someone and then you go on the web page and then you are in the call but there we also want to develop something where you can just say ok I want to call this user at this server and then his mobile phone or his desktop client will use this automatically and he will get pulled into the call and you can have a call with him so this was my really fast overview over federated sharing and I am happy to take some questions is there some formal specification for the federation protocol or is it just de facto whatever next cloud on cloud the question was if there is a formal specification of the protocol for the federated sharing and yes we started out basically this was a trial and error approach right at the beginning where we just implemented an own cloud and see how it works and then it was automatically of course implemented next cloud because next cloud is derived from own cloud and the patio people contacted us and asked how to develop this stuff and then we helped them to implement this as I said it is just three of our rest course but we are also involved in an initiative which is called open cloud match initiative from all the universities really and with them we are at the moment working on a real form of specification of this protocol so because you really want that it becomes an open standard which everybody can easily implement and set it up so that is ongoing at the moment we just finished the first draft which we have now a discussion around on this draft and we are heading into this direction Is it possible to simultaneously edit What was that? Is it possible to edit simultaneously if you have to use support? At the moment it is not possible because it is just the question was if you share a file from one server to another server it is possible to simultaneously edit a document so basically work collaborate on this document at the same time at the moment this is not possible it is just a laptop mount so the file just mount over there and if people edit it at the same time then basically the person will save the latest which will store the main version and the other version will go in the versions of the file as all the versions but with the integration we also integrate collaborate online office for really collaborate on office documents and there we want to make it possible in the future that then you can which already works with collaborate office but there we want to make it possible of course that you then can really collaborate on the same documents Have you considered aliases for the user ID cloud addresses? Aliases? Yes Have you considered aliases for the cloud ID? Yes we considered it I also think it is not a bad idea I even implemented some kind of prototype of aliases for people in the next cloud and back then it was the own cloud community decided that they want to have it they thought it is too complicated too disturbing for the normal user whatever so it was the contents at the end that now keep it simple but I think now with the new approach that you can define your own federal cloud ID completely independent from the server we are heading again a little bit into this direction of course you still don't have multiple aliases but at least you can specify this one and address the way you want to have it Yeah? During your talk you spoke about C-file but they recently split up are you talking with the German or with the German? The question was I said that I talked to C-file about implementing this federal sharing and the question was if I talked to because they split up recently if I talked to the German entity or to the Chinese people I only followed this on the internet which was public like probably most of us but I have the feeling that the real development power and stuff like this is by the Chinese people I think that's the people who drive it forward and I talked with them about it Yeah? Talking about the police and the troops what about on cloud and the next cloud if you today have to give to make an argument about you should choose this solution or rather this one My argument I mean we are in foster we are all free and open source software developer and my main argument would be next cloud is completely free software Oh, sorry The question was if I would need to make an argument whether you should choose own cloud or next cloud because I mentioned both and I worked at both companies and so yes as I said because we are in foster we are all free and open source developers or interest in this topic my main argument to this group would be completely free software if you look at own cloud this has some kind of open core business model there is this community version which is open source and free software but there is also then the enterprise version which is no longer free software which has a commercial license attached which also has functionality which is not available in the community version so to this group this would be my main argument this is the complete free software solution driven by the community and with the community together Thank you