Decent Sync @ infophysics.org: mechanical physics with information theory

Decent Sync is a shared clipboard service between your devices. Under the hood, it never uploads to a cloud. It's a frontend-based web application.

Notes:

A rendevouz server (first hosted at sync.decent.so) stores information used to QR-code match devices between them. Alternative text-based or emoji-based system is available.
- What if instead of QR codes you get a list of emojis?
  - Let's skip this -- could be complicated.
- What does this accept? Per IP; only ipv4; it will store one secret.
- Submitting a secret directs the connection to a room.
- A room is broadcast-only messaging, intended for direct peer-to-peer communication establishment.
- Debug logs stored until reliability is achieved
- Personal note: use Rust
A progressive webapp that stores a small "notes app" based on Decent Sync.
- Simple UI: "Join habitat" / "Create a new one"
- Status of sync, last seen other devices
- Folders and notes
Future: "Share notes to other persons in your abitat"

Prelude: JavaScript and Literate Programming

Because I believe people should turn off JavaScript by default, it was written in a Literate Programming style, and this is such explanation. Kind of like a quine.

If you have JavaScript (it makes me very unconfortable to see it written it that way) enabled, then some parts of this document will be hidden for you. See:

This is actually the code that is getting executed. You can verify that the source code of this page is exactly that, but just in case, I'll be showing all the code as this:

This HTML weights in at just under a dozen kilobytes, and it was all manually crafted, without preprocessors.

Use Case 1: As a user of DS, I want to store information locally

The first subject we'll tackle is that of storing key → value assignments, such as "Idea" → "Build a simple front-end application". While probably not astonishing at the beginning, we could build layers on top of that simple storage later.

A functional requirement for this is that users can come back and they will see the same list of stored information as they used to in the past. Other usecases that we'll tackle later will take care of syncing that information across devices trusted to be used by the same person

A very naive approach can be simply to store such information in the localstorage API, and load everything at the beginning. We'll display that in a table (but that will be UC2).

That previous listing is the internal structure, but let's create a form to submit information to it.

In order for that to not be that ugly, this style is used:

And this is the code that makes it work:

Use Case 2: As a user of DS, I want to see all the information stored locally

And now we should build a table with this, to test if it actually works and do something useful. We'll start with some style.

Key	Value

And now, populate the table with code:

Use Case 3: As a writer of this blogpost, I want to focus on interactive elements and not the literate programming part

I have now a bunch of ideas on how to iterate this and make it a lot easier to use for actual humans. First, even though this whole explanation is quite useful to understand the system, it might not be that useful for someone who's using the app every day. So, one thing that I want to experiment with is making each of these sections collapsable, making sure that adding, removing, editing items is easy (for which we could use the "editable" property of HTML elements, combined with change events). Let's start with collapsing sections, and using DS to keep the status of each section to survive reloads.

For starters, let's hide sections when the title is clicked.

Which actually needs this extra set of CSS to avoid showing the code blocks for scripts and style.

But let's go a step further and just leave some basic UI to see what's stored

Next steps

This is yet a work-in-progress and not ready or useful.

Cheers,
Claude