trivnote

Welcome to the homepage of whatever this is.

“trivnote” is the (provisional?) name I gave it. I named it after the trivlist environment in LaTeX, which is short for “trivial list” I believe? Anyways, “trivnote” is trivial in the sense that it is (what I believe to be) the most basic form of notes: text and drawings.

In case you somehow have the forbidden knowledge of my last personal, sustained big project, trivnote is the continuation of Project Perspective. (That is, it will simultaneously double as a diary/journal notepad, with doodles/comics in the middle if you do that too. :)

But first, the boring information stuff….

At present, two components have been registered:

• pub/project/trivnote.git (GitLab): the project as an Android application (primarily targeting Samsung tablets like mine)
• Trivnote-rescues components have been renamed to archive-bridge.

They can be cloned with https://git.rapidcow.org/⟨component⟩, or you can find the GitLab clone URL from hyperlinks above.

If you want to contribute, I would like to know your preferred patch/pull request collaboration workflow. Email me: foss@rapidcow.org so I can save myself writing 10+ alternative methods when realistically people will only use a few…. (If you know my name, you can replace “foss” with it; but I am not giving that out since scrapers find it easily :x)

The plan is to also support Samsung notes, since there have been a handful of reverse engineering attempts, and I myself got a Samsung tablet after seeking an iPad alternative. That said, I have substantially more Apple notes than I have Samsung notes, so I am modeling it after PKDrawings. (Samsung Notes are also paginated, which while good for PDF, is not good for me because I write/draw in a long strip and my stuff would absolutely be severed midway if I adopted pagination :x)

On the topic of AI, I am not exactly against it, but I am not exactly 100% permissive about it either. I clarify them here. In a nutshell, AI contributions are ok, provided that it is not hard to review and you promise to be held responsible for anything copyright-related (Developer Certificate of Origin).

While I’m not too ambitious about where this goes, I have a few principles in mind:

• Faithful/neutral data representation format: Bottom line, trivnote should function as an archive viewer. Be liberal in what we accept, use exact math, and be extensible. (The primary purpose of trivnote is to import data previously generated my Apple Notes, so that’s why the rule is here.)
• Self-describing data representation format: Although suboptimal, reading the raw data without the schema should make some semblance of sense. In our s-expression's case, this means prefer labeling the adjacent numbers with a textual symbol to a fixed layout that relies on externally-defined parser logic to jump to specific byte positions.
• Native export/import: Partial and full in the absence of a network connection should be supported.
• Explicit mutation stages: Like Git, saving (caching a state) and committing (permanently registering a state) should be explicitly authorized by the user. These stages may be collapsed if the user finds it convenient, but must be de-couple-able. (I should remind you that this is primarily for archival, so my need with an explicit commit stage is prioritized. ;P)
• Network independence: Or local-first, offline-first, whatever you call it. The offline app is the full app. In addition, retrieving content from a network should be sufficient for populating a full copy that is functional offline (with the exception of possibly large binary blobs stored as soft links). The big word for this idea is called optimistic replication, contrasted with the (boring) pessimistic replication.
• Explicit conflict resolution: Only verifiably orthogonal components may be merged automatically (and for text where there is no z-order, orthogonality is not necessary, but the changes should commute); the rest should be explicitly resolved. This is contrasted with conflict-free resolution type (CRDT) systems, which, while I deeply respect, leave out the decision-making step that I greatly value for archival purposes.
• Network agnosticism: Personally, I think TCP/IP is pretty dope, but the nature of 802.11 WLAN technology still requiring a central access point makes Bluetooth Low Energy (BLE) appealing. It is therefore necessary that the protocols we employ be as agnostic about the specific transport. (And definitely not limit ourselves to HTTP REST.)
• Peer-to-peer based synchronization: When network is enabled by user, prefer direct connection with peers to connection with a cloud server (unless explicitly chosen by the user). Peers should be symmetrically equipped with client/server software. Network can be disabled and/or enabled at will. Each peer will be independently capable of reconciling histories.

And a select few Unix philosophy principles from ESR’s TAOUP:

• Rule of Simplicity: I want to be upfront about this: I personally suck at writing small programs, and I’m not gonna pretend that I will ship the smallest binary that runs on a toaster. (This page itself is not the smallest page necessary.) However, I cite this rule specifically with respect to (a) code at a module level, which I think should be independently readable/comprehensible (see compactness and orthogonality, some things I can see myself agreeing with), and (b) data format, which should be simple and interpretable outside of any specific software. The most lamentable example is Open Office XML (OOXML for short); it is technically open standard (and XML is, technically, plain text too), but that doesn’t it any more pleasing for programmers outside of Microsoft to implement it. (It is arguable that the complexity is due to years of accumulated technical debt, and files open just fine in Office Applications, but note my (implied) objection to it as an interchangeable, implementation-neutral format for documents under practical constraints.) A (IMO) good example in contrast is OpenDocument Format (ODF), which I personally haven’t tried parsing, but have heard good things about it. There is a tendency for *nix users (like myself) to prefer text to binary formats, but judging by that criterion can be a tad bit limited when there are architectural decisions that lock in the format, more than the specific schemas employed.
• Rule of Transparency: Inspection of the running system should be easy, not just to the so-called “developers”. It is my belief that everyone can be a developer; and the process to becoming one should be made as frictionless and as unceremonious as possible.
• Rule of Composition: Work with other applications. Expect the output to be input to another program, preferably without dependency besides established standard libraries.
• Rule of Separation: In ESR’s own words: “Separate policy from mechanism; separate interfaces from engines.” Specifically in the case of Android development: the library should utilize OpenJDK and other pure-Java components, and should be independently runnable and testable, independent of Google's Android SDK.

Concretely, I plan to implement these “features” like this:

• Git for object storage, file history, and delta transfer protocol. (This means yes, for those of you who prefer not to invest in hardware for self-host, you can use a free GitHub as synchronization target; and of course, your data won’t be held hostage by GitHub, or whoever you choose. ;)
• Data is represented as R7RS-compatible s-expressions. The rationale is two-fold: (a) I am obsessed with Lisp, for meta-programming, and as a language whose AST is not just similar, but identical to the syntax; it’s also insanely easy to parse (easier than JSON!) And (b) Because I am hand-rolling the parser, I get to decide other nice properties, such as round-tripping numbers (since I never trust floating-point) and exact math (for rendering/graphics).