tait.tech/_drafts/2022-06-21-livreshare.md

layout	draft	title
post	true	A Libre Solution to Live Sharing

Nothing irritates me more than when a relatively simple thing is not possible with free (libre) software. Such is the case with sharing code with others, live.

The Problem

Here is what I want: I'd like to open a share session in a directory on my machine, have others be able to join it from their editor (via a plugin). When you are logged in and connected to a session a user may be put in RO or RW mode to allow them permission to read and write. Finally, a .live file should be produced using a similar format to asciinema, except slightly simplified. This file will show the progression of the file or directory over time. It shows everything from every character typed, deleted, retyped, files created, removed, all with timestamps as to when each action occurred.

Why?

Everyone has different preferences and needs, including but not limited to: editor complexity (and ability), color scheme, internet speed caps, accessibility needs, etc. While everyone can generally accommodate themselves on their own project, or when collaborating with others over a longer period of time (see: git), these preferences and needs are not met when it comes to live sharing code.

Existing Options

There are many existing programs, plugins and websites dedicated to sharing code on the fly. Most of these offer a similar level of functionality whereby one person can share their code, and others can see what they're working on as the presenter changes the code. However, if you've ever tried to use these systems, you may have noticed something: They don't work cross-editor, nearly every single code-sharing platform I can find only allows you to share code if everyone is using the same editor. "But Tait! What about CodeTogether? That's cross-editor!" you might say. Unfortunately, it only supports cross-IDE development: Eclipse, VS Code, and IntelliJ; it does not support basic editors like Pluma, vim and emacs. "But Tait! What about Floobits? It's cross-editor, supports Emacs and Neovim, and it's open-source!" Sadly, no. It does support the various editors, and that is by far and away it's most exciting feature! But it still isn't fully open-source. Only the plugins are open; the server and deployment techniques are hidden from view.

Technically speaking, this is a simple problem to solve: Create and share an open-source, self-hostable, simple implementation of live text-sharing code, and let the community take over as the needs of certain users get increasingly complex. Of course, nobody will do this for some of the reasons I will explain down below.

Making Money In Open-Source Development

Although most developers would have a fairly easy time creating a project like this over the course of six months to a year, there is an obvious problem that comes up almost immediately when it comes to creating a set of open tools like this: making money with open-source cat be quite the challenge.

It is certainly not impossible, look at the success of SourceHut, a self-hostable git server with an extensive plugin network. The service isn't free, but you can self-host for free. They also work on creating other open-source projects for consulting fees, trying to grow the ecosystem of FOSS tools.

With that said, the return on investment in terms of developer hours worked is often very slim when creating products on this model. Let's take a theoretical example:

Support one were to pour their free-time efforts for six to twelve months into a project like what I mentioned earlier. Imagine they were able to establish a corporation, figure out financials, and create a viable product for the end-user. The developer has, by now, used: let's say on average ten hours a week on this project. Let's multiply that by 52, since that's the number of weeks in a year: that's 520 hours of work, or about 13 weeks of full-time work---completely unpaid.

This is a huge risk for a developer to take. They must sacrifice their free time with family, friends, and hobbies to dedicate their time to a cause they care about, but no no (guarentees TODO) as to how much they will make in the future.

If given the option between the scenario above, and working a full-time development job o pay the bills, which would you rather choose?

I know my decision wouldn't take long.

So who would be wild enough to work on such a difficult project for (potentially) such a small amount of money?

1. Those who are attempting to start their career in tech and want examples of professional work experience.
2. People who are passionate about their project.
3. People with extra time on their hands.

I fall into the first and second categories, personally. Do you fall into any of these?

Some of the most difficult times in one's career (so I'm told) are those times where you decide that something is worth the risk. And for those with a passion or career drive, why not accept some risk for the possibility of significant reward.

"No risk, no reward" ---A Guy At The Gym

The Solution

With that large aside over, let's take a look at what I'm envisioning this system to look like as a user and as a developer. I'll split this into two section for each respective type of user.

End User

For the end user, you can use the following features:

1. Record and broadcast your file edits live by plain text.
2. You may (optionally) join this with an audio stream to supplement your viewers' experience.
3. You may use any editor, IDE, or even notepad++.
4. These recordings and live-streams can record and stream entire directories of information.
5. There are some minor restrictions:

• Binary files will not be transmittable for multiple security reasons. This includes .zip files, .jar, and .exe files.
• The "free" hosting solution will only be able to handle ~10 viewers per stream, and can only live-share code under 1MB in size, since otherwise it will require too much RAM.

6. A self-hosted server may be spun up the user's machine at any time if they have the know-how to get others connected directly to their computer.

If you want more: pay-up or self-host. This seems pretty reasonable to me.

Developers

Developers will be ecstatic to hear that this will use a very simple method of holding all this data.

Here's an example of the format; note that the "file" key is relative to the root directory being shared:

{
  "files": [
    {"file":"/accounts/models.py","id":1},
    {"file":"/accounts/views.py","id":2},
    ...
  ],
  "version": "1.0",
  "starting_content": [
    {
      "id": 1,
      "content": "..."
    },
    ...
  ],
}
// this begins the live-streaming, whereby users may view the steeam on a line-by-line basis, or skip to a specific point in time to view details about the file at a certain timestamp. Think of it like video timestamps.
{"id":2,"action":"del","line":10,"char":22,"len":5}
{"id":1,"action":"ins","line:23,"char":4,"text":"# quality"}
// Each line represents an action done to one of the files at some point in time.
// In theoy, you could even have edtiors use this information to update their files on the fly if two people have the file open at the same time.
// the OS should probably stop you from doing this, but at least you could get the editors to communicate if you wanted.

In serde terms, this would be an untagged enum of possible actions as well as their arguments.

This is a prototype idea that I have created a repo for called livetext, which is a silly name; I'll rename this when I come up with something better.

Check out the repo here. Send some PRs, and let's see if we can create the next generation of code-sharing technology.

So long and thanks for all the fish! Happy live-hacking!