So, let me welcome the next speakers. We have Blinri and Moritz and they are going to talk
about Tim Type, really play your mode for your text editor to watch a collaborative editing
protocol. Let's welcome them with a round of applause.
Hi, thanks for the introduction. We kind of split this talk into two parts.
The first part is about showing you a tool that we built over the past two years.
And the other part is about like we want to pitch you an idea that allows you to add your own tools to the mix.
But we're going to start with our tool.
Hi, I'm Moritz, and Tim Type has been inspired by things like ESA PET, where you can type text together.
But we also wanted to co-together, and there's some solution that is a co-life share where you are bound to a specific editor.
So what we want to have instead is something that's interoperable between editors. We like NeoVem, so we are kind of biased.
But we also want to have an e-mix implementation, and we do have the VS Codeum implementation to edit local text files together.
So, especially paper programming and no taking.
I'm open source project that is also funded by an Lnet and a prototype fund, and I think it's a perfect job by Nico in the schedule, because it fits very well with what we've seen before in the talk.
And we used to be called ESA think.
And I think the best is just to show you.
So, this is another demo, and this is quite light, but I hope I cannot change the color, but I will make it bigger.
And to use it, there's a demon that has started with team type share.
And I have to confirm that I want to do this in this empty directory.
And then there's a team type join six conformist facial.
And Blinry is joining, so we will hopefully soon.
So, Blinry joined.
I think I did.
And you didn't?
No.
Okay, someone else did.
So, five to back on off, please let us demo this, and then we can test it together later.
We discussed, can we trust the room to mess with us or not?
So, all we have problems with the internet, that's your other option.
No, I think it's mine.
So, connected, connected, connected, and still no files here.
But now, Blinry opened the file on that system.
So, I see a file I can open it with my new event.
I'm connected, and I can type while Blinry is typing.
So, this is, and we can also have selections.
And we also can have VS Codeium.
So, I can open the file here, and also see the other two cursors.
And we type it at the same time.
Yeah.
So, second file.
Yeah, so we can also have more files.
And there's something like a team type follow if you want to, like,
a paragraph and just watch, or I can jump to the cursor, and no range.
Okay, there's some mysterious error.
So, I want to jump to Blinry, and then I'm in the second file in the event.
Okay.
So, there's a demo part.
Thank you.
And up to Blinry.
All right.
If you're curious how this works, by the way, you can check out the talk from last year.
And where we talked about, like, our basis, we're using AutoMurge, Iro,
and Magic Remholes, so we kind of standing on the shoulders of clients.
And we want to hone in on this very specific part in this talk,
which is about the connection between the editor and the rest of the system.
And currently, what we did is, like, to build individual editor plug-ins, right?
We have one for any of them, for VS Code.
We're starting on the work for a plug-in and e-mix, and to make the others.
And they're talking to a team-type demon.
And the demon then communicates to other demons and other computers.
But now, imagine that he would like to have some other collaborative applications, maybe,
from your text editor.
For example, you want to talk to a hedgehog server, or maybe you want to talk to a peer-to-pender.
You would need currently to have, like, individual plug-ins for all of these arrows, right?
You would need a new plug-in that talks to hedgehog, for example.
And that's kind of inconvenient, and that's a lot of arrows.
And if you think about it, like, in other areas where, like, you want to give capabilities to text editors,
this has been solved already.
For example, if you want to have code computations or diagnostics in editors,
before you had the situation on the left where you need one plug-in per language
on the left and per editor on the right.
But it was solved by the language server protocol, where, like, the editors only need to implement this protocol.
And then, like, the tooling support also need to implement it, and all combinations can talk to each other.
And that seems really convenient for this purpose.
Other areas where similar situations exist are the debug adapter protocol that gives, like,
debugging capabilities to editors.
And more recently, the model context protocol allows adding LLN capabilities to editors.
So we see a gap here where it would be really nice to have something like a collaborative editing protocol for text editors,
that you can implement in one editor once, and, like, maybe once for collaborative application,
and all of those combinations can talk to each other.
So if you take one thing away from this talk, maybe it would be that,
having this would be really cool.
And now the question is, like, how to build that?
So we already have something, obviously, working for team type, and the ideas to abstract the way from it,
and also similar to Andreas said in the previous talk,
that we kind of have some interoperability even between, like, the different solutions that we see here.
What we have so far is, Carlson, Jason, or PC protocol.
So we are based on Jason, or PC.
We are inspired by LLSP.
So there's the question, can it work with LLSP as well?
And there's also a solution grade, which would be based on HTTP.
If you have other ideas, how just could work, please reach out to us.
The contact will be in the end.
Currently it works.
We try to start with a very minimalistic solution.
We have open closed edit and cursor, message type,
and it kind of fits in a Macedon post.
And the open closing is just to, say, from the editor to the demon.
Yeah, I want to know about this file, and I'm currently typing into it.
I need your updates kind of following and then un-following.
So the edit is then you send out the specific range.
There are different ways to approach this.
This is the way what was most convenient for the editor plugins that we currently have.
And you need to have some sort of synchronization between the demon and the editor,
which is what the revision is for.
And the revision is based on some kind of dumb-down OT,
that's operational transformation, where the editor has to do as little as possible,
and the demon does most of the jobs, most of the work.
cursor is pretty straightforward as well.
You just have the position or the range, and when it's coming from the demon you have a name.
And we currently have the implementations, as I said, for new of them, and VS Code, and Test Studio.
But other solutions are floating around, and once we found an agreement,
or once it's working, we will definitely advertise them on our page.
So we'd be happy if you are interested in these other editors for contributions.
So that could be you.
Just a short expectation management would be great because of time.
We are planning to answer every questions offline, so we are planning to fill the whole slot.
So sorry, we currently not planning to take, maybe we see if you are managed to take in question the end,
but we are not planning to.
And now for the collaboration server, the bling we said with this end-by-end,
we also have a prototype here.
Maybe some of you will know Headstock, which is online text editing.
You know what I just show you.
So the Headstock looks like this here on the right side.
You have a running browser, so web application.
And it's possible entirely, like, without the demons,
or I'm just killing this one to make sure, but I don't have any demon running here.
But the editor, like my new of him, is configured in such a way that it's using our Headstock prototype,
which is from the ESA sink time, so he hadn't greened it yet.
But it's still working, and then I can connect to the test site,
and it's loading the content of the site, and also I should be able to type here.
And on the right side, oh, I need to go to edit mode, of course, and editing.
Yeah, so Headstock.
The protocol currently has this problem, that we don't have undo.
For example, we cannot initiate a connection from the site in a different way,
because the editor plugins opening, but we need this team type share that we currently have,
and the team type showing that we showed you.
And we also have some usability UI issues in a way, like,
that if you have an editor open, if file open in your editor,
and it's deleted on the other side, what do you do?
So the editors need to be told about that, and need to have an interface for that.
And what we showed you, like, was our current prototype protocol using JSON RPC.
And now the question is, maybe, like, another way would be possible,
where you're just using the language server protocol directly, to allow collaborative editing,
because it already supports, like, events like opening of text documents,
changes of documents, because the language servers do need to know about the content of your buffer in your editor.
And also, the editors that you signed around already have, like, version identifiers.
So, in theory, it would be possible to just use LSP, which would have the advantage that,
like, any editor that already has LSP support, could be attached to the system,
and then you would already have this collaboration.
Maybe, yeah, the last point is about, like, how would you show remote browsers?
Maybe you could, like, use a text annotation of that character as a, as a cursor,
or something, it would be, like, a record one.
And, on the practical side, it seems like there are several, like, challenges to this idea,
which are, like, how would you implement this?
Jump to cursor that mode, show it to you.
LSP also has a bit of a different model for how to communicate the changes.
And one would need to, like, cleverly think about how to, how to do that bidirectionally,
and it's definitely not intended for that use case, like, because it's used for, like,
code computations and stuff, so it feels a bit like a hacky solution.
Nevertheless, one person in the community has already built a bridge,
so you can start a little program that speaks LSP to the editor,
and speaks the team type protocol to the other side, basically,
so you can kind of try that already, and it's working progress.
And the third option that we see for a protocol between editors and collaborative applications
would be using something called wait.
It's currently been worked on in a working group to be a standard and an extension of HTTP,
which allows, like, stage synchronization via HTTP.
For example, here's a message that changes the text offer blockpost,
and you can see that it has a content range there, and it says,
please replace this range with this new text.
And the advantage here is that it's already kind of becoming a standard anyway,
and the disadvantage that it's maybe a bit more of a complex thing that the editors would have to implement.
And again, here, one person from the background here has written a team type bridge,
which means that you can use our team type protocols to talk to great resources already.
So kind of all of these three roles already talk to each other, which is cool.
And now the question is how to proceed with, like, going towards this collaborative editing protocol.
We see two kind of directions that are in a bit of a trade-off against each other.
One is what we're currently doing, which we call, like, project stewardship for this protocol,
which is, like, we as the team type project just, like, find out what we need this protocol to do in practice kind of,
and that makes it, like, proven by practice, basically, and driven by the needs we have in the project.
And we are kind of fast to move if we need to make any adaptations, we can, like, do it like that,
and we have been doing that over the past few years, I guess.
On the other side, it would be possible to, like, drive this standardization with a consortium,
where, like, you would have shared ownership over it, it would be more independent,
and maybe it would be a general, a better, a general solution, and have better compatibility.
So, here's our invitation to all of you.
If you're curious to help shape this collaborative editing protocol, if you project somehow, maybe touch us, text editors,
and you can, you can do it with us.
We just made a Zulip chat platform, but you can join, and we have an editor protocol channel in there.
And also, this talk is intended to be, like, to open the discussion on this, and we will do a follow-up at the end of February.
You can find the date there, and the link to it did see.
And we would love to talk with all of you who are interested in, like, how to make that specification.
And finally, a few curious about the Tim Black project, we have, like, some links here to our source code on to our Amazon account,
and it already works, take it out.
Yeah, all right, thanks for listening.
Thank you.