About me: My name is Solène Rapenne, pronouns she/her. I like learning and sharing knowledge. Hobbies: '(BSD OpenBSD Qubes OS Lisp cmdline gaming security QubesOS internet-stuff). I love percent and lambda characters. OpenBSD developer solene@. No AI is involved in this blog.

Contact me: solene at dataswamp dot org or @solene@bsd.network (mastodon).

I'm a freelance OpenBSD, FreeBSD, Linux and Qubes OS consultant, this includes DevOps, DevSecOps, technical writing or documentation work. If you enjoy this blog, you can sponsor my open source work financially so I can write this blog and contribute to Free Software as my daily job.

Storing information on paper using the Pen To Paper protocol

Written by Solène, on 15 July 2022.
Tags: #life #fun #nocloud

Comments on Fediverse/Mastodon

1. Introduction §

Here is a draft for a protocol named PTPDT, an acronym standing for Pen To Paper Data Transfer. It comes with its companion specification Paper To Brain.

The protocol describes how a pen can be used to write data on a sheet of paper. Maybe it would be better named as Brain To Paper Protocol.

2. Terminology §

Some words refer to specific concepts:

  • pen: a pen or pencil
  • paper: material on which pen can be used
  • writer: the author when using the pen
  • reader: the author when reading the paper
  • anoreader: anonymous reader reading the paper

3. Model §

The writer uses a pen on a paper in order to duplicate information from his memories into the paper.

We won't go into technical implementation details about how the pen does transmit information into the paper, we will admit some ink or equivalent is used in the process without altering data.

4. Nomenclature §

When storing data with this protocol, paper should be incrementally numbered for ordered information that wouldn't fit on a single storage paper unit. The reader could then read the papers in the correct order by following the numbering.

It is advised to add markers before and after the data to delimit its boundaries. Such mechanism can increase reliability of extracting data from paper, or help to recover from mixed up papers.

5. Encoding §

It is recommended to use a single encoding, often known as language, for a single piece of paper. Abstract art is considered a blob, and hence doesn't have any encoding.

6. Extracting data §

There are three ways to extract data from paper:

  1. lossless: all the information is extracted and can be used and replicated by the reader
  2. lossy: all the information is extracted and could be used by the reader
  3. partial: some pieces of information are extracted with no guarantee it can be replicated or used

In order to retrieve data from paper, reader and anoreader must use their eyesight to pass the paper data to their brain which will decode the information and store it internally. If reader's brain doesn't know the encoding, the data could be lossy or partially extracted.

It's often required to make multiple read passes to achieve a lossless extraction.

7. Compression §

There are different compression algorithms to increase the pen output bandwidth, the reader and anoreader must be aware of the compression algorithm used.

8. Encryption §

The protocol doesn't enforce encryption. The writer can encrypt data on paper so anoreader won't be able to read this, however this will increase the mental charge for both the writer and the reader.

9. Accessibility §

This protocol requires the writer to be able to use a pen.

This protocol requires the reader and anoreader to be able to see. We need to publish Braille To Paper Data Transfer for an accessible alternative.