these are the feature set i want to replicate with the Arcology Project. i've clobbered these things together over a decade in elisp and python but want a steady mobile system that i could take the International Trip with.

org-mode features

org-mode is a text editor plugin with features:

• file-level key value metadata

• heading-level key value metadata

• headings have tags

• links to files or ids

  • or other extensible targets

• headings can have todo state, priority, schedule, deadline dates

  • query and generate agendas

  • calendar view

  • repeating tasks and habits

  • time tracking and pomodoro timing

• text markup ... bold italic code verbatim _underline_, links

• quickly capture notes with templates

  • capture by sharing url to emacsclient

  • capture by sharing a file to emacsclient

  • capture with form-filling

• tables with formulas

• source code snippets with

  • metadata attached to the source like language, target file, literate programming variables (built from tables or text references)

various extensions we might implement

• org-fc flashcard/spaced repetition with multiple card types, cloze doubble side single side

• org-transclusion include file/heading/text content from other files with #+INCLUDE syntax

GOAL: a shared document parsing library which can implement the features below

implementation decision: parser architecture

• *language: kotlin multiplatform for native android performance and cross-platform capability - approach: pure kotlin implementation avoiding rust ffi complexity for ast manipulation - priority features*: core org-mode syntax, tables (for existing flashcard data), arcology keywords, org-fc cloze

org-roam features

an extension org-mode where every heading with an ID property in every file in the org-roam directory will be treated as a node, a small piece of data. org-roam focuses on granular nodes, and the zettelkasten slipbox method of creating fleeting notes in the journal and slowly accreting those in to evergreen notes using interstitial journaling, perhaps resurfacing stub or incomplete nodes automatically

• take a directory of org-mode files and see which have not been index or have been modified.

• extract metadata from them to sqlite:

CREATE TABLE files (file UNIQUE PRIMARY KEY, title , hash NOT NULL, atime NOT NULL, mtime NOT NULL);
CREATE TABLE nodes (id NOT NULL PRIMARY KEY, file NOT NULL, level NOT NULL, pos NOT NULL, todo , priority , scheduled text, deadline text, title , properties , olp , FOREIGN KEY (file) REFERENCES files (file) ON DELETE CASCADE);
CREATE TABLE aliases (node_id NOT NULL, alias , FOREIGN KEY (node_id) REFERENCES nodes (id) ON DELETE CASCADE);
CREATE TABLE citations (node_id NOT NULL, cite_key NOT NULL, pos NOT NULL, properties , FOREIGN KEY (node_id) REFERENCES nodes (id) ON DELETE CASCADE);
CREATE TABLE refs (node_id NOT NULL, ref NOT NULL, type NOT NULL, FOREIGN KEY (node_id) REFERENCES nodes (id) ON DELETE CASCADE);
CREATE TABLE tags (node_id NOT NULL, tag , FOREIGN KEY (node_id) REFERENCES nodes (id) ON DELETE CASCADE);
CREATE TABLE links (pos NOT NULL, source NOT NULL, dest NOT NULL, type NOT NULL, properties NOT NULL, FOREIGN KEY (source) REFERENCES nodes (id) ON DELETE CASCADE);

provide UI for:

• quickly capture notes and URLs to my daily journal

• quickly search for node by title, alias or URL

• show references with backlinks or unlinked bm25 keyword search

• graph view to visualize node relationships

• nodes can have aliases and URLs

• move nodes around, extract heading to separate file and refile in to another file under a different node

GOAL: an android app that serves this UI comfortably with up to 5000 files and 50000 headings, a database abstraction that can be used by the server and CLI

implementation decisions: mobile and sync

• *sync protocol: syncthing api integration - conflict resolution: leverage syncthing's built-in conflict files, build resolution ui later or use emacs ediff - performance target: 500ms search response time (faster than existing android apps) - offline capability: full offline operation with eventual sync - data model: sqlite with org-roam schema plus arcology extensions (heading_properties, file_properties) - id generation*: timestamp-based ids (20251212T231404.213411) for compatibility

arcology features

arcology publishes any org-roam heading and its subchildren to a URL, the URLs can be on a few domains

adds a few tables to the org-roam schema:

CREATE TABLE heading_properties (node_id NOT NULL, key text, value text)
CREATE TABLE file_properties (file NOT NULL, key text, value text)

these are used to derive further schema allowing one to:

• publish a page/heading and its subheadings to a URL

  • add a property to a heading to expose that heading and its children at a good URL

  • multi-domain support, the same org roam repository can publish to multiple sites, and pages can link to pages on other sites

  • id link rewriting, id links ought point the cross-domain url

  • drawer hiding so that property drawers and org-fc state tracking drawers are not visible on the web

  • rss feed publishing

  • org-fc cloze rewriting so that the text is legible on the web

• navigation:

  • backlink and reference navigation

    • rendered inline with the heading the backlinks link to, rather than on a sidebar or at the bottom of the page

  • sitemap graph navigation

    • by published URL, not necessarily by heading like the org-roam one

  • tag map

  • keyword/value/file search features

• heading properties

• attachment crunching

New ideas

• expiring links, publish a journal page for 1 hour or 1 day or 1 month system using webmention/bridgy/etc

• use org-transclusion syntax to prepare an Atom feed/page with headings transcluded from other parts of the graph

• crossposting daemon

  • post links to pages sometimes

  • email pages to certain groups when new pages are detected

  • webmention support

  • Publish headings to long-term fediverse threads

  • record replies and interactions to org-mode file to be processed as tasks

keywords:

GOAL: a web publishing binary that can be pointed at an org-roam directory and serve those pages on all their relevant domains

implementation decisions: web publishing

• *architecture: lazy rendering with hash-based cache invalidation - routing: ARCOLOGY_KEY property format "SITE/path/in/url" maps to domain routing - rendering strategy: render on-demand when content hash changes, cache rendered output - multi-domain*: single org-roam repo serves multiple sites via SITE mapping

arroyo features

arroyos are seasonal waterways in the southwest of America. They are like wadi or washes. They flow seasonally.

Arroyo systems are like that. Most arroyos are ecosystems, this one is a technical system. An ecosystem flows seasonally and goes in to hibernation when waiting for time or need, conserving energy. I used to live backed up to one. Usually they were highways for small animals and birds, coyotes and young boys.

Arroyo systems have flash floods, bursts of focus or inspiration, an infusion of resources and attention that slips away quickly. My computers work the same way they always do, until they need to change and have the resources to do so.

Then I have to remember what I was doing and how to do that. That's what the concept operating system aims to fix.

Arroyo systems are literate programming projects built on top of org-babel that force you to read and keep good documentation to work with the code and allow you to spread those docs across files and organize them as you please. It's a slow ecology of software that accretes over seasons. During the spring and summer we manage orchards, in the fall we harvest and process, in the winter we hack.

They are alluvial, ideas spread downstream and are carried back up.

• "tangle" all the org-mode files that this literate programming project use

• generate Nix system module import lists from key/value metadata in org-roam headings

  • home-manager too

  • "this nix system should only have nix modules tagged for running on my wobserver"

  • "this nix system should exclude anything related to programming and only include my task management systems"

• generate emacs lisp init files similarly

  • "this heading has an emacs lisp init block that is saved to <arroyo/files/init/org-roam.el>"

  • "this file has to be loaded after org-mode.el"

• generate python or toml or whatever other configuration syntax using human-legible tables

  • edit a table and recompile the page to change your system keybindings

  • edit a table and recompile the page to add new features to your website

keywords:

*GOAL: a command-line tool which can be run from within Emacs to query the database

implementation decisions: development process

• *repository structure: single monorepo with modules (not maintaining apis for external users) - testing strategy: comprehensive core library testing (parser, database), selective integration testing - ai-assisted development: extensive unit tests and property-based testing - release management: single version number across all components - focus areas*: parser edge cases, database layer, web publishing routing, key workflows

arcology2go user stories

imagine a self-contained, miniaturized multidimensional tree of your digitized thoughts and feelings and actions. the tree grows chronologically but also orthogonally off of other roots in to other directions of light and attention. tools to work with your thoughts, mix and match them, distill and share them broadly. synced between your devices, available offline, seamless sync to your server node and publishing environment.

In nature, as an organism evolves it increases in complexity and it also becomes a more compact or miniaturized system. Similarly a city should function as a living system.... Arcology recognizes the necessity of the radical reorganization of the sprawling urban landscape into dense, integrated, three-dimensional cities in order to support the complex activities that sustain human culture. The city is the necessary instrument for the evolution of humankind.

: Paolo Soleri, introduction to Arcology

these are aspirations, not launch requirements!

use case: the international trip

The International Trip is some microficton I wrote a decade ago. hypertextual object store w/ geospatial capabilities and offline queued publishing.

use case: modern input methods for capture and recall

an android app with a speech input; a tablet app with a pen input & handwriting recognition; something i could give my loved ones without inflicting them with Nix and Emacs. I want to complete The International Trip...

use case: space repetition study

not just for code monkey.... take notes and remember them. write anki files or at least have spaced repition of headings:

• question

  • a side

  • b side

or

• question

  • answer

where a and b can still be anywhere else in the graph, part of notes on an essay you read on the web... the question heading carries metadata about the anki stage, due date, etc... the UIs i build need to have this sort of "card-like" view of a heading graph, it's not only "document with subheadings", but it's things like cards or slide decks with embedded metadata.

use case: replacing org-babel and org-export

code is data, some data is knowledge

~ from logseq for code management

this object graph needs to be able to contain its own source code as well as my "concept operating system" the complete computing environment document publishing system, my other projects as well.

the code in the documents will be extracted to disk to a Nix monorepo and to project git repositories; maybe it's packaged up and ready to be deployed; perhaps it's even one programming language executed in a sandbox with the results embedded in the code of a different programming language. literate programming ... document metaprogramming ... i want to query the document tree for all the nix files tagged to run on my laptop and put them in my laptop's flake.nix nixosModules section. I want to generate configuration files for my computers using spreadsheet-style tables.

use case: Concept Operating System

Remember your code, remember your todo list, tie in your references and documentation.

A meta-programmable lab notebook or journal

use case: publishing

this whole arcology project started because i wanted to be able to take one of those objects i mentioned at the top and make a URL on the web for it. publishing is important to me even if no one reads my work and it's not compelling to most folks.

an important part of the arcology user experience is that it is a "sync to publish" system, not a web composer, not a git checkin system, certainly not a local static site generator. you save a lightly marked up text file to local disk with some metadata (such as url, theme, federated crossposting details, rss metadata etc) and it appears on the web. syncthing and its api are rad. i would build on top of it again.

the site likely has some dynamic system pages, interactives, comment boxes, page load counters, etc., but data that will be written to. but much of it can either be pre-rendered or rendered on first load and cached... hmm. (in the CAS???) no i want some sort of sqlite sidecar database thingy based on the markdown ... some day sqlite table <-> markdown table sync... i want to capture comments and page counters and provide little interactives...

idealistic bullshit: how could parts of the raw graph and node history be synced between family members or friends? could i just share part of my graph with you and have those appear under your "new stuff from friends" heading? could rss or email be also ingested in this way? oh no what have i done? could i synthesize filtered graphs and export those for sync or public consumption/import in to their graph?

how does activitypub or atproto fit in to this thing?

is it a bonfire server or a bluesky pds or a mastodon API client?

use case: langle manglers and agentic clankers

i was careful i didnt say anything about agentic generative conversational etc etc chatbot interfaces ... right now markdown is surging as a sort of lingua franca of the web alongside html so that clankers can burn less electricity reading your stuff. those guys love spitting out markdown.

this document tree could be used to generate branching chat conversations if you really wanted it to... ask your langlemangle to summarize a list of documents you transclude in to a context window and use that as a summary at the top of it or in your social media marketing or spam operation. ask it to text your mom every time you post a pic of your kid, i dont care. have it read your journal and ask it to dissect your follies and initiate ideal parent protocols. doesnt really excite me right now.

the text embedding stuff, semantic vector search and n-nearest-neighbors searches, generating patterned documents like those anki cards based on others youve made. probably useful, lightweight, attainable. useful to let the bicycle of the mind freewheel sometimes, but it's important to understand the limits of generative interfaces and their uses, and to look past generative systems toward other uses for all the GPUs lying around.