WEBVTT 00:00.000 --> 00:12.960 Hey everyone, I'm Benui and I'm really excited to share this project with you all as to see 00:12.960 --> 00:15.600 such a tech room. 00:15.600 --> 00:23.760 The inspiration for the project is tools like ether pads or hedge doc or crypt pads, which 00:23.760 --> 00:31.440 I really love to use for taking notes during a meeting or to write a draft of a blog post 00:31.440 --> 00:37.720 with another person together, but one thing that back me about this is that you cannot write 00:37.720 --> 00:39.360 code with it together, right? 00:39.360 --> 00:44.960 It's only for text and also if you need an internet connection, so once you're offline 00:44.960 --> 00:48.560 you cannot access this information anymore. 00:48.560 --> 00:54.560 There are tools to record one like that, for example several text editors have plugins. 00:54.560 --> 01:00.560 This is a plugin called Life Share for VS Code, which allow you to collaboratively edit 01:00.560 --> 01:06.800 code together, like files that are on your local machine, but this is a proprietary plugin, 01:06.800 --> 01:11.440 and like the protocol is not open, so your friends who use new them as something 01:11.440 --> 01:13.520 cannot really join, which sucks. 01:13.520 --> 01:20.160 So obviously we need something to add to them, and that's why I started the ether sync project, 01:20.160 --> 01:26.960 which is an editor-economic, open source tool and protocol for editing local text files together. 01:28.640 --> 01:36.800 I'm not doing this alone, but I did it with a friend, so on and on, we like most of the 01:36.880 --> 01:44.160 stuff we will show you last year together, with funding from an internet, and yeah, I only have 01:44.160 --> 01:49.520 10 minutes, but I will try to show you as much as possible about it, and here's what we have 01:49.520 --> 01:51.680 and how it works. 01:51.680 --> 01:58.160 The idea is based around like connecting their directory is project directory, so to make 01:58.160 --> 02:04.400 a connection with another person, you would like go in your directory of code or something, 02:04.400 --> 02:10.720 and I say ether sync demon, which starts a demon and then shows to the connecting command, 02:10.720 --> 02:16.240 others can use to connect with you, so the other person would want ether sync demon and provide 02:16.240 --> 02:21.520 a peer, like in their project directory, and after that these two directories are now 02:21.520 --> 02:26.960 magically synchronized and like files that appear in one directory also appear in the other one, 02:27.680 --> 02:34.240 and if you start opening a text file, you can start real-time collaboration in it. 02:35.200 --> 02:41.600 I have a little video that you see at this work, so you can see on the left side there is 02:41.600 --> 02:49.040 a new instance running and editing a text file, and on the right you have a VS code, and yeah, 02:49.040 --> 02:57.280 you can edit this content together over the network, and also you can see other people's 02:57.360 --> 03:05.520 characters in this text, right, and this works like both with VS codes, multi-curse feature, 03:05.520 --> 03:14.400 for example, and also with newvins, block-curse, this will be transmitted to the other connected people. 03:17.040 --> 03:23.040 Right now we have plugins for newvins and VS code, this is what the VS code plugin looks like in 03:23.040 --> 03:30.880 this extension store, for example, and more plugins are coming up, I will show you later. 03:33.680 --> 03:39.440 The demon synchronizes entire project, so it's not only for a single file, but it's for like 03:39.440 --> 03:43.600 the entire directory and it's up the directory, which makes a lot of sense if you're editing code. 03:45.680 --> 03:50.480 You can not only use like text editor first, but you can also use external tools. 03:50.480 --> 03:55.600 Sometimes you have cases where like it's part of your workflow to, I don't know, use the 03:55.600 --> 04:00.800 cargo command to change your cargo terminal file or something, and then it would be inconvenient 04:00.800 --> 04:07.280 if you had to do this in your editor without this external tool, so here's a demo of someone 04:07.280 --> 04:13.920 having a file open in newvim at the left side, and at the right, and you have like this terminal session 04:14.480 --> 04:17.200 where the person starts like editing this file. 04:18.160 --> 04:20.160 Let's see. 04:21.520 --> 04:26.800 Yeah, so here we are appending something from the command line to the file, and over the network, 04:26.800 --> 04:31.280 this content changes also picked up and edited into enter-near them. 04:31.280 --> 04:36.960 Also, if you saw the content for some reason, yeah, it's considered over, which is like 04:36.960 --> 04:45.680 very convenient for for ourselves developing this, and the tool now I dropped this keyword is 04:45.680 --> 04:51.440 local first, so you always have full access to the content even if you go offline, right? 04:52.480 --> 04:58.240 This is like important if you drive through a terminal and a train or something, and then you want 04:58.240 --> 05:03.360 to keep coding on it, and then we synchronize later once you can reconnect to your peer. 05:04.240 --> 05:10.880 So now you might be wondering are there using CRDTs? Yes, we are, of course, this is like 05:10.880 --> 05:15.120 if you have never heard of it, I don't have time to like go into how it works. 05:15.120 --> 05:21.840 It's like an algorithm called conflict-free replicated data types, which is very convenient for like 05:21.840 --> 05:28.160 making like having a situation where both parties can edit, and then once they connect it, 05:29.040 --> 05:34.240 it kind of automatically fits together again, but check out other talks if you are curious 05:34.240 --> 05:39.840 how that works exactly. And yeah, we're doing peer-to-peer connections, so you don't have to trust 05:39.920 --> 05:45.760 the sentable server. How does it work? Let's look a little bit into that. 05:46.880 --> 05:51.200 We wrote the demon in Rust, and the plugins in their respective scriptmen languages, 05:51.200 --> 06:00.000 like Lua and Tab script, and the components fit together like this. So each peer has a running 06:00.000 --> 06:06.240 demon, which are connected by the internet, and then like make this synchronization of the content, 06:06.720 --> 06:10.640 and you are editors connect to the demon on your local machine using a plugin. 06:12.400 --> 06:16.640 Let's look at what those arrows mean in more detail. So demon to demon, 06:17.360 --> 06:22.640 we're using a library called LipPear to peer right now, which is like custom build for a 06:22.640 --> 06:28.320 situated like this, very flexible, and we're using their private network feature to encrypt 06:28.320 --> 06:33.840 the content that's going through it. And inside of this connection, we are speaking there 06:33.840 --> 06:38.640 are automatic, automatic sync protocol, automatic as the CDT library we're using. 06:40.240 --> 06:46.800 And demon to editor, we have this design goal to make it as easy as we can to write new editing 06:46.800 --> 06:52.800 plugins. So we kept the protocol really small. Basically, the editors have to spawn an 06:52.800 --> 07:01.360 interesting client subcommend, and then talk Jason RPC to it. And yeah, we have a small syncing protocol 07:01.440 --> 07:06.160 that's kind of inspired by LSP, the language server protocol, because we thought editors 07:06.160 --> 07:13.440 support that most of the time anyway. So offering our protocol in Jason RPC format might be 07:14.000 --> 07:20.880 like practical to implement. And for this protocol, because the editor is a separate process, 07:20.880 --> 07:25.360 we also have to do something clever, and we're using operational transform for that, which is 07:25.360 --> 07:30.800 like another approach to make real-time collaboration. And we're doing it in a one-sided way, 07:31.360 --> 07:35.040 where the editor doesn't really have to do much, it can just reject the changes 07:35.040 --> 07:39.920 is getting, which it doesn't apply to its own content right now, and the demon will do most of 07:39.920 --> 07:47.520 the work and send the content data. Our demon editor protocol is so tiny that we want to 07:47.600 --> 07:54.320 fit it into a two-t, so here it is, and like, well, not 250 characters or something. And 07:54.320 --> 08:00.160 this is like the core of how the content synchronization works, the experiment, how we can 08:00.160 --> 08:07.600 express that. But we also have documentation, which goes into more detail. It's not really a 08:07.600 --> 08:12.400 replacement for Git, I would say, it's more like a tool that works together with it. 08:12.480 --> 08:19.520 It's not really a system for which text editing right now, it's most independent. And also, 08:19.520 --> 08:25.520 it's not production, where the software I would say it has some rough edges, for example, 08:26.720 --> 08:31.920 one of our open questions is, which makes it a bit inconvenient to use, how to make connections 08:31.920 --> 08:37.760 between two local networks. Right now, what we do is, one person opens a part in their router, 08:37.760 --> 08:45.600 which is not very convenient. But yeah, we would like the better solution for that. And if you 08:45.600 --> 08:52.080 have suggestions on how to do it, let us know. Lipit repair has this private network feature for 08:52.080 --> 08:57.280 encryption, and Lipit repair also has relays, but I don't think the two fit together in a good way, 08:57.280 --> 09:02.720 it's not really intended for that. And yeah, our green would be, like, to have a magic rumhol 09:02.800 --> 09:07.840 style connection making, where one person gets three English words, and then tells that to the other 09:07.840 --> 09:15.520 party, and then the other person can connect. And three ways to get involved. You could write your own 09:15.520 --> 09:22.560 editor plugin. And I certainly have two official plugins for new them as VS Code. And some other 09:22.560 --> 09:28.320 contributors are working on once for IntelliJ that one is quite far and also for E-mix. I think the 09:28.400 --> 09:33.840 PRs here, but you could write other ones for a clip, for example, if you're using that. 09:35.040 --> 09:40.560 Some kind of web-based editor would be really nice to have. And if you were like, really having 09:40.560 --> 09:45.920 want a good time, you could, I don't know, fork nanos, something, and then like heck, 09:45.920 --> 09:52.160 it's a thing supported into it if you wanted. And second thing is to help us improve the syncing protocol. 09:52.880 --> 09:58.640 Maybe if someone has like a lot of experience with LSP for example, you might have suggestions on 09:58.640 --> 10:04.880 how to make it more general to be able to use it with other synchronization tools, maybe. 10:05.760 --> 10:11.600 And yeah, what we would really like to do is to have maybe a small group of people who work on 10:11.600 --> 10:17.440 refining and sanitizing it. And yeah, in the end, it would be nice to have this protocol be 10:17.440 --> 10:23.280 able to like use it with other software as well. For example, we heard about the API for crypto pad 10:23.280 --> 10:30.080 and being able to use it with crypto pad would be quite nice. And yeah, the third thing is just to 10:30.080 --> 10:37.200 use it in crypto feedback. If you find something that's annoying or broken, let us know anything 10:37.200 --> 10:44.400 you're missing. And yeah, as the very last thing, what I would really like you to take away from 10:44.400 --> 10:49.040 this talk is not that you necessarily have to use our tool or something, but I want you to be 10:49.040 --> 10:54.800 unsatisfied with like the status quo. And I, like the next time you have to pair program using a 10:54.800 --> 11:00.960 screen share or something, maybe you are a bit annoyed and have like desire for a solution like this. 11:02.160 --> 11:05.600 And that's all I got for you. Here are some links for all of the documentation. 11:05.600 --> 11:17.840 Thank you very much. And fortunately, we don't have time for questions. So don't hesitate to 11:17.840 --> 11:21.920 talk about it in the whole way. And we'll prepare for the next talk.