rename articles to research

119 files changed, 0 insertions, 2964 deletions

diff --git a/root/articles/$order b/root/articles/$order
deleted file mode 100644
index 97f81e8..0000000
--- a/root/articles/$order
+++ /dev/null
@@ -1,2 +0,0 @@
-mmmfs
-realities
diff --git a/root/articles/mmmfs/$order b/root/articles/mmmfs/$order
deleted file mode 100644
index d58d878..0000000
--- a/root/articles/mmmfs/$order
+++ /dev/null
@@ -1,14 +0,0 @@
-title
-abstract
-table-of-contents
-introduction
-motivation
-historical-approaches
-framework
-mmmfs
-examples
-evaluation
-conclusion
-references
-ba_log
-statement-of-originality
diff --git a/root/articles/mmmfs/abstract/text$markdown+sidenotes.md b/root/articles/mmmfs/abstract/text$markdown+sidenotes.md
deleted file mode 100644
index c7d6c9c..0000000
--- a/root/articles/mmmfs/abstract/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,14 +0,0 @@
-abstract
-========
-
-Current end-user operating systems are based on a set of design principles and computing paradigms that make them
-simple to use in some circumstances but are very inflexible for user customization and adaptation. In this thesis, these
-limitations and design principles will be discussed and contrasted by an analysis of historic systems that solved these
-issues by following different design goals. Based on this analysis, as well as further literature, an evaluation
-framework for end-user computing systems is established.  
-The design and implementation of a new end-user computing system, which focuses on a file system with rich file types
-and a type coercion system as its central paradigm, is discussed. Following this, the capabilities of the system are
-demonstrated using multiple example use-cases. An evaluation of these examples as well as the system itself according
-to the framework established earlier shows that the proposed system is indeed very flexible and useful for a wide
-variety of uses involving multimedia content from various sources, although the system has many flaws that would hinder
-widespread adoption.
diff --git a/root/articles/mmmfs/ba_log/$order b/root/articles/mmmfs/ba_log/$order
deleted file mode 100644
index a77277a..0000000
--- a/root/articles/mmmfs/ba_log/$order
+++ /dev/null
@@ -1,15 +0,0 @@
-start
-2019-10-07
-2019-10-08
-2019-10-09
-2019-10-10
-2019-10-11
-2019-10-14
-2019-10-15
-2019-10-24
-2019-10-26
-2019-10-27
-2019-10-29
-2019-11-01
-2019-11-25
-2019-12-20
diff --git a/root/articles/mmmfs/ba_log/2019-10-07/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-07/text$markdown.md
deleted file mode 100644
index 46c6892..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-07/text$markdown.md
+++ /dev/null
@@ -1,40 +0,0 @@
-Today I started working on the HTTP server that finds, converts and serves content stored in the (SQL) backend just-in-time (later the server could also cache content).
-
-The server can handle these types of requests:
-
-## Fileder Index Requests
-A request like `GET /path/to/fileder/` (note the trailing slash) is used to query the contents of a fileder.
-It solicits a JSON-encoded response that contains the full paths to all children of this fileder, as well as all facets currently stored, e.g:
-
-    {
-      "children": [
-        "/projects/vcv_mods",
-        "/projects/HowDoIOS",
-        "/projects/iii-telefoni",
-        "/projects/btrktrl",
-        "/projects/demoloops",
-        "/projects/VJmidiKit",
-        "/projects/gayngine",
-        "/projects/themer",
-        "/projects/chimpanzee_bukkaque"
-      ],
-      "facets": [
-        ["", "text/moonscript -> fn -> mmm/dom"],
-        ["name", "alpha"],
-        ["title", "text/plain"]
-      ]
-    }
-
-## Facet Requests
-A request like `GET /path/to/fileder/facet_name` is used to query a facet.
-To differentiate a request for the 'unnamed' facet from an index request, unnamed facets are represented as a `:` character instead.
-The type to ask for can be specified in a `MMM-Accept` header separately, it defaults to `text/html`.
-
-The server either sends back the (possibly converted) facet with a `200 OK` status,
-or a `406 Not Acceptable` error if no conversion was possible.
-
-I also restructured the code a bit and moved some of the HTML-rendering code into the main mmmfs code.
-Then I renamed the `text/html` type to `text/html+frag`, since it refers to only a fragment of HTML code, not a whole document,
-and added a new *convert* from `text/html+frag` to `text/html` that wraps the fragment in the HTML template and style.
-
-the full code change is in commits [81e143f](https://git.s-ol.nu/mmm/commit/81e143fa8181a6adb58d7fba632bd31a13164410/) and [ad26c7c](https://git.s-ol.nu/mmm/commit/ad26c7c4e374f66a978f9946bbb083377f2224a6/)
diff --git a/root/articles/mmmfs/ba_log/2019-10-08/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-08/text$markdown.md
deleted file mode 100644
index c10b75f..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-08/text$markdown.md
+++ /dev/null
@@ -1,58 +0,0 @@
-Today I mostly fixed the output/rendering of the 'live' server I implemented yesterday.
-
-I changed the URL scheme, it no longer uses headers, which made it hard to link to resources through `<link>` and `<script>` tags.
-Instead the path, facet-name and type are now all part of the URI:
-
-| URI                                            | fileder path       | facet name      | type                           |
-| ---------------------------------------------- | ------------------ | --------------- | ------------------------------ |
-| `/fileder/facet: type/subtype -> wrapped/type` | `/path/to/fileder` | `facet`         | `type/subtype -> wrapped/type` |
-| `/fileder/: some/type`                         | `/fileder`         | (default facet) | `some/type`                    |
-| `/fileder/alternate:`                          | `/fileder`         | `alternate`     | `text/html` (default type)     |
-| `/path`                                        | `/path`            | (default facet) | `text/html` (default type)     |
-| `/`                                            | `/`                | (default facet) | `text/html` (default type)     |
-
-The fileder-index metadata was moved to a `?index` 'pseudofacet' (e.g. `/fileder/?index`).
-
-**EDIT 2019-10-09:**
-> I will take this chance to show and hopefully explain the point of this all again:
-> With the system running it is now possible to demonstrate the type-coercion that powers the system.
->
-> In the system, every piece of data (the *facet*s) is stored together with it's *type*.
-> When requesting data, it can of course be loaded with that *type*, yielding the data unmodified,
-> but it is also possible to demand a different *type* that may be more useful to the receiving application.
->
-> as an example we can take for example this article about one of the internal libraries for writing HTML documents:
-> [`/meta/mmm.dom/`](/meta/mmm.dom/).
->
-> The path `/meta/mmm.dom/` corresponds, according to the table above, to the default facet of the `/meta/mmm.dom` fileder,
-> and since no type was specified, it is assumed that the browser wants a `text/html` document.
-> The follwing path gives the same result, but makes this explicit:  
-> [`/meta/mmm.dom/:text/html`](/meta/mmm.dom/:text/html)
->
-> now, instead of asking for the rendered HTML document, we can also ask for the source, which is of the type
-> `text/moonscript -> mmm/dom` (a Moonscript file that evaluates to a website-fragment):  
-> [`meta/mmm.dom/:text/moonscript -> mmm/dom`](/meta/mmm.dom/:text/moonscript%20-%3E%20mmm/dom)
->
-> the source code was written in MoonScript, which compiles to Lua before it is executed.
-> We can also ask the server to do that for us:
-> `text/lua -> mmm/dom` (a Lua file that evaluates to a website-fragment):  
-> [`meta/mmm.dom/:text/lua -> mmm/dom`](/meta/mmm.dom/:text/lua%20-%3E%20mmm/dom)
->
-> or, we could ask for the generated html fragment, but without the full HTML layout around it -
-> that would be the type `text/html+frag`, as mentioned in the last post:  
-> [`meta/mmm.dom/:text/html+frag`](/meta/mmm.dom/:text/html+frag)
->
-> lastly, we could also ask the system to generate a link to this content, in the `text/html` format (`URL -> text/html`):  
-> [`meta/mmm.dom/:URL -> text/html`](/meta/mmm.dom/:URL%20-%3E%20text/html)  
-> this might seem somewhat redundant, since we need a link to access this link,
-> but it can be useful when a component cannot work with binary data directly, e.g. when mentioning or embedding an image
-> or a video file.
-
-I also added support to the server for serving static assets (e.g. the CSS stylesheet) from the `static` directory.
-These files are accessible through the `/.static/` route (e.g. `/.static/main.css`), where they shouldn't interfere
-with the mmmfs contents.
-With the layout adjsuted to use these new paths, the live server now looks properly styled again too!
-
-Finally I worked on the Dockerfile and my deployment a bit,
-so that my updates to the code will now be automatically applied to my test site,
-which is available at [ba.s-ol.nu](//ba.s-ol.nu) (which might be where you are reading this right now!).
diff --git a/root/articles/mmmfs/ba_log/2019-10-09/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-09/text$markdown.md
deleted file mode 100644
index 702620d..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-09/text$markdown.md
+++ /dev/null
@@ -1,9 +0,0 @@
-I added another driver/store that loads files straight from disk \[[`86bbe80`][86bbe80]\],
-and made the server load the fileder tree when it receives a request for content, rather than loading the whole tree up front.
-This means that I can work on the content again and see changes in the browser without restarting the server every time  \[[`97bc4a0`][97bc4a0]\],
-This feature should be made unnecessary by the in-page editing feature, but until then it's important for my workflow.
-
-I also started cleaning up the mmmfs article a bit, and integrating this project log in a way that will make it available online soon.
-
-[86bbe80]: https://git.s-ol.nu/mmm/commit/86bbe805a7ec49a8b891412713ea43d6e46d0d73/
-[97bc4a0]: https://git.s-ol.nu/mmm/commit/97bc4a0d8d866026905eac6f0ba08b75f166219a/
diff --git a/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md
deleted file mode 100644
index 010f861..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md
+++ /dev/null
@@ -1,46 +0,0 @@
-Today I moved the static resources needed by the web-frontend into the content of the mmmfs itself:
-The server doesn't make an exception for static files anymore (as described in [a previous update][2019-10-08]),
-but rather the files are just in a fileder called `static` now, and properly typed, here:
-
-- [/static/style/](/static/style/:%20text/html+interactive)
-- [/static/mmm/](/static/mmm/:%20text/html+interactive)
-
-This removed a big exception and left the server implementation much cleaner and shorter, as can be seen in the corresponding commit [`005cc9b`][005cc9b].
-
-I also changed the route syntax introduced in [`2019-10-08`][2019-10-08] for getting the fileder index,
-now instead of being hard-coded to return a JSON value at `?index` \[[`b36a1a6`][b36a1a6]\].
-`?index` is treated as a pseudo-facet that can be requested in different types, just like real facets.
-I also added a second pseudo-facet `?tree`, which works like `?index`, except that it recurses and includes
-all content below the current fileder, rather than just including the child-fileders.
-
-Here are some example links for viewing these:
-
-- [`/?index: text/html`](/?index:%20text/html)
-- [`/articles/mmmfs/ba_log/?index: text/html`](/articles/mmmfs/ba_log/?index:%20text/html)
-
-Finally I added a third pseudo-facet called `?interactive` that renders the Inspector that the old page ran on,
-allowing to inspect raw facets, and bringing back the navbar \[[`9ab2f0f`][9ab2f0f]\].
-
-Now that there was a way to serve the Browser to the client again, I got to work on fixing it there.
-This involved a bigger changes in the shared mmm internals:
-
-Up to this point, for each request to render a fileder, the server would load that fileder,
-with all its facets and their values, as well as all children and their facets and children recursively.
-That means that when the root fileder is rendered, currently 120MB of data have to be loaded from disk (or a database).
-Now that the client can render content within the web browser again, that would be even worse due to the network delay.
-
-To solve this, the Fileder implementation now lazy-loads \[[`9632233`][9632233]\].
-When a Fileder is created, it initially knows only its path, but doesn't know which facets or children it contains.
-As soon as that data is attempted to be accessed, the fileder loads in the list of its children and facets from the datastore.
-The facet contents are loaded only when they are actually needed to fulfill a data request or conversion.
-
-With this need for optimization taken care of, I added a new datastore (`web`) \[[`91546d1`][91546d1]\], that can run on the client.
-Instead of directly accessing a database or physical file system, like the `sql` and `fs` stores, the `web` store delegates all
-requests to the server APIs I have been building, such as the new `?index` pseudo-facet.
-
-[2019-10-08]: /articles/mmmfs/ba_log/2019-10-08/
-[005cc9b]: https://git.s-ol.nu/mmm/commit/005cc9b3914128267017620984aee921999e173f/
-[b36a1a6]: https://git.s-ol.nu/mmm/commit/b36a1a6c61a6e8bff156ce4e2dc66fe8ed8cd95e/
-[9ab2f0f]: https://git.s-ol.nu/mmm/commit/9ab2f0fe3a1a043300536a057bafe5058d987d7f/
-[9632233]: https://git.s-ol.nu/mmm/commit/9632233c16a26f017c648faf36a6b26833e62f2e/
-[91546d1]: https://git.s-ol.nu/mmm/commit/91546d12919736b08567d7174bf1063cab0838f0/
diff --git a/root/articles/mmmfs/ba_log/2019-10-11/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-11/text$markdown.md
deleted file mode 100644
index 0b58c75..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-11/text$markdown.md
+++ /dev/null
@@ -1,30 +0,0 @@
-Yesterday I got client-side access to the whole mmmfs tree to work via the new `web` datastore,
-but the requests were still extremely inefficient.
-This was because the organisation of the interface between the `Fileder` implementation and the datastore,
-which required the Fileder to make two separate requests to `?index` to fetch its children and facets,
-and also couldn't take advantage of the `?tree` pseudo-facet to bundle together multiple indexes in a single request.
-
-To fix this I added a new datastore method called `get_index` that returns both facet and child information \[[`e2a4257`][e2a4257]\]
-The Fileder implementation now uses this method instead of asking individually for the two pieces of information
-when lazy-loading fileder contents.
-The `get_index` method can also be instructed to recursively load to a fixed depth.
-A Fileder can also be instantiated using such a nested index,
-which causes it to immediately preload up to the same depth without the need for fetching more data.
-This allows some more optimizations, like having the client preload 3-levels deep when it launches,
-which seems like a decent heuristic of the data actually required for most pages and minimizes load time.
-
-I also added some tests for the `Key` class that I use in many different places to represent facet names and types \[[`782d072`][782d072]\]].
-
-The `?interactive` pseudo-facet from yesterday was changed to the `text/html+interactive` type instead \[[`8cdf5d4`][8cdf5d4]\].
-This was a bit of a tough decision, because it is a bit un-idiomatic: rendering the browser page still requires an exception in the browser.
-In the end the motivation for the change was that it should be possible,
-for user ergonomics, to link to the interactive view of a given facet of a given fileder.
-With `?interactive` being a facet, it wasn't possible to specify the facet without jumping out of the adressing system.
-With these updates on the other hand it is possible to link fo example:
-
-- to the main content of the root fileder, as an interactive view: [`/: text/html+interactive`](/:%20text/html+interactive)
-- to the page title of the root fileder, as an interactive view: [`/title: text/html+interactive`](/title:%20text/html+interactive)
-
-[e2a4257]: https://git.s-ol.nu/mmm/commit/e2a4257fc05d37822df2b7bbe0f587645375edf2/
-[782d072]: https://git.s-ol.nu/mmm/commit/782d0725f3f29eaa7d4a12213fb00c6643795348/
-[8cdf5d4]: https://git.s-ol.nu/mmm/commit/8cdf5d4a363ba99a6356e7e1dfe0dfb39e6fb13e/
diff --git a/root/articles/mmmfs/ba_log/2019-10-14/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-14/text$markdown.md
deleted file mode 100644
index e42f8be..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-14/text$markdown.md
+++ /dev/null
@@ -1,101 +0,0 @@
-I finally added a better type-conversion-path-finding algorithm \[[`deb21aa`][deb21aa]\].
-The old algorithm only took into consideration how many steps it took to get from type A (stored on disk) to type B (requested).
-This could lead to problems, for example in this situation:
-
-On Disk: `text/moonscript -> fn -> mmm/dom` (a moonscript file that contains a function that returns a bit of UI)  
-Requested: `mmm/dom`  
-Known Conversions:
-1. `text/moonscript` to `mmm/dom` (displays the source code with highlighting)
-2. `text/moonscript -> ???` to `???` (evaluates the moonscript file)
-3. `fn -> ???` to `???` (calls the function, providing access to children and other facets)
-
-Since conversion 1 only takes a single step, it would have been preferred by the old algorithm (although there were workarounds for this).
-The new algorithm adds the concept of conversion-cost, that has to be specified for each conversion.
-The conversions 2 and 3 now have a cost of `1`, while conversion 1 has a cost of `5`.
-The conversions are simply added up and the path with the lowest cost is chosen.
-Like in other pathfinding applications like digital games, the cost metric is also used by the algorithm to enhance the search itself,
-it prioritises searching further on the path with the least current cost.
-
-To implement this optimization I implemented a priority queue:
-
-    -- a priority queue with an index
-    -- only one element with a given key may exist at a time
-    -- when an element with an existing key is added,
-    -- the element with lower priority survives.
-    class Queue
-      new: =>
-        @values = {}
-        @index = {}
-
-      -- add a value with a given priority to the queue
-      -- if no key is specified, assume the element is uniq
-      add: (value, priority, key) =>
-        entry = { :value, :key, :priority }
-
-        if key
-          if old_entry = @index[key]
-            -- already have an entry for this key
-            -- if it is lower priority, we leave it there and do nothing
-            if old_entry.priority < priority
-              return
-
-            -- otherwise we remove the old one and continue as normal
-            -- find the index of the old entry
-            local i
-            for ii, entry in ipairs @values
-              if entry == old_entry
-                i = ii
-                break
-
-            -- remove it
-            table.remove @values, i
-
-          -- store this entry in the index
-          @index[key] = entry
-
-        -- store lowest priority last
-        for i, v in ipairs @values
-          if v.priority < priority
-            -- i is the first key that is lower,
-            -- we want to insert right before it
-            table.insert @values, i, entry
-            return
-
-        -- couldn't find a key with a lower priority,
-        -- so insert at the end
-        table.insert @values, entry
-
-      peek: =>
-        entry = @values[#@values]
-        if entry
-          { :value, :priority, :key } = entry
-          @index[key] = nil if key
-          value, priority
-
-      pop: =>
-        entry = table.remove @values
-        if entry
-          { :value, :priority, :key } = entry
-          @index[key] = nil if key
-          value, priority
-
-      -- iterator, yields (value, priority), low priority first
-      poll: => @.pop, @
-      
-    {
-      :Queue
-    }
-
-This priority queue behaves mostly as expected, but I added an extra feature to make sure that only the
-best conversion path to a specific type is considered for further searching:
-When adding a new element to the Queue, an extra `key` can be passed.
-If a key is passed, the Queue makes sure that there is only ever one element with that key in the queue.
-When a second element would be introduced, the queue discards whichever element has a higher priority value.
-
-This way I can use the type that a conversion path leads to as the key,
-and the queue will automatically discard a worse solution if a better one is found that leads to the same type result.
-
-To make sure the Queue implementation was solid, I also added unit tests for it: [`spec/queue_spec.moon`][spec]
-
-[deb21aa]: https://git.s-ol.nu/mmm/commit/deb21aa43fe8bf11eb276803973b272913b7e716/
-[spec]: https://git.s-ol.nu/mmm/blob/deb21aa43fe8bf11eb276803973b272913b7e716/spec/queue_spec.moon
diff --git a/root/articles/mmmfs/ba_log/2019-10-15/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-15/text$markdown.md
deleted file mode 100644
index d4e4121..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-15/text$markdown.md
+++ /dev/null
@@ -1,70 +0,0 @@
-I'm giving a workshop next weekend, and I had to create the slides for that.
-Since one of the aspirations of `mmmfs` is to be easily adaptable to any kind of data organization and -presentation task,
-that was a good opportunity to try and implement a simple slideshow system.
-
-I started by creating a new fileder to hold the slideshow, [`/articles/xy-workshop`](/articles/xy-workshop/).
-In the main facet, I created a MoonScript file.
-Since the facet needs to access its children (the individual slides), I also used the `fn ->` type,
-that injects the current fileder into the script.
-
-`text/moonscript -> fn -> mmm/dom`
-
-    import ReactiveVar, tohtml, fromhtml, text, elements from require 'mmm.component'
-    import article, button, div, span from elements
-
-    =>
-      index = ReactiveVar 1
-      slide = index\map (index) -> @children[index]
-
-      local view
-      view = div {
-        style: ... -- styling ommited here
-
-        div {
-          style: ... -- styling omitted here
-
-          slide\map => @get 'mmm/dom'
-        }
-      }
-      
-      local left, right
-      if MODE == 'CLIENT'
-        left = (_, e) ->
-          e\preventDefault!
-          index\transform (a) -> math.max 1, a - 1
-
-        right = (_, e) ->
-          e\preventDefault!
-          index\transform (a) -> math.min #@children, a + 1
-
-      tohtml with article!
-        \append div {
-          button '<', onclick: left
-          ' '
-          span index\map (t) -> text t
-          ' '
-          button '>', onclick: right
-        }
-        \append view
-
-I used the `mmm.component` library that lets me create reactive UIs.
-First I declare the reactive variable `index`, the current slide number.
-Then I derive the `slide` reactive variable, that is defined to be the child with index `index` -
-since these are `ReactiveVar`s, whenever `index` changes, `slide` will automatically load the current slide fileder.
-
-Then I create the main slide view, which consists mainly of two containers and some styling.
-Inside, I derive another reactivevar from `slide`: whenever a new `slide` is selected,
-this piece of code will request the main content in `mmm/dom` format and replace the current view content with that.
-
-Lastly I construct a little navigation UI, consisting of the left and right buttons.
-When one of them is clicked, it modifies the `index` variable, making sure to stay in the range of existing slides.
-The rest of the UI then reactively updates accordingly.
-
-Lastly I added keyboard controls for cycling through the slides, as well as a button to enter fullscreen mode.
-You can find the extended code for that in the commit [`ca24ef1`][ca24ef1],
-but it is not a lot either: with the additions the file is 70 lines long.
-
-With this done, it is just a matter of creating children-fileders and placing whichever content I want in them,
-they behave just like any other page of the system now.
-
-[ca24ef1]: https://git.s-ol.nu/mmm/blob/ca24ef108dbb11860e719711e4e7fbd6323aee0e/root/articles/xy-workshop/text%24moonscript%20-%3E%20fn%20-%3E%20mmm%24dom.moon
diff --git a/root/articles/mmmfs/ba_log/2019-10-24/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-24/text$markdown.md
deleted file mode 100644
index dbb838a..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-24/text$markdown.md
+++ /dev/null
@@ -1,32 +0,0 @@
-While writing some of the main section of the thesis today,
-I felt the need to illustrate some subject matter with a diagram depicting a folder structure.
-Knowing of some similar tools that generate SVG diagrams from textual descriptions,
-some quick research turned up [mermaid JS][mermaid].
-
-I tried it in their online live editor first to verify that it would indeed do what I needed it to,
-and then added it to the set of supported types in mmm (on the clientside only) \[[`2ff6f90`][2ff6f90]\].
-This was pretty easy in the end, all it took was adding mermaid.js to the interactive version's resources (in `build/server.moon`)
-and then definig the `convert` (and thereby implicitly defining the corresponding type, `text/mermaid-graph`):
-
-    {
-      inp: 'text/mermaid-graph'
-      out: 'mmm/dom'
-      cost: 1
-      transform: (source) =>
-        with container = document\createElement 'div'
-          cb = (svg, two) =>
-            .innerHTML = svg
-          window.mermaid\render "mermaid-#{id_counter}", source, cb
-    }
-    
-The code is quite short, since all it needs to do is create a container element,
-then tell mermaid.js to render the textual definition.
-Once mermaid.js is done, the rendered content is added in the container element.
-
-Here is one of the two diagrams that I implemented the feature for,
-you can also follow the link through to the source and view the textual representation using the 'inspect' button.
-
-<mmm-embed path="/articles/mmmfs/mmmfs/tree_mainstream"></mmm-embed>
-
-[mermaid]: https://mermaidjs.github.io/mermaid-live-editor/
-[2ff6f90]: https://git.s-ol.nu/mmm/commit/2ff6f906c498c1b742dd8437a09c97ebe29a652a/
diff --git a/root/articles/mmmfs/ba_log/2019-10-26/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-26/text$markdown.md
deleted file mode 100644
index d5cd9bd..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-26/text$markdown.md
+++ /dev/null
@@ -1,62 +0,0 @@
-Besides some smaller fixes with the styling of the page, and in particular the diagrams introduced in [`2019-10-24`][2019-10-24],
-I finally (re-)implemented children-ordering in the `fs`-store of mmmmfs
-(the `sql` store is still missing it, but I am not currently using it either) \[[`a62f63b`][a62f63b]\]:
-Files on the regular filesystem don't have a particular order, but in mmmfs the order of children is is guaranteed,
-so that arranging children in a particular order becomes a meaningful tool.
-
-To store the ordering data, a 'magic' file called `$order` is (optionally) stored in each directory in the filesystem.
-The file lists all child fileders by name in the given order.
-When the children of a fileder are requested (in `list_fileders_in` or `get_index`, which relies on the former),
-all children that are mentioned in `$order` are returned in that order,
-while all remaining children are sorted alphabetically and appended at the end of the list.
-This way the order is guaranteed to be stable even if no `$order` file is specified,
-or when the `$order` file has not been updated after adding new children.
-
-Here is the commented implementation in MoonScript:
-
-      list_fileders_in: (path='') =>
-        -- create a mapping of all child-fileders
-        -- in 'entries' (name -> path)
-        entries = {}
-        for entry_name in lfs.dir @root .. path
-          continue if '.' == entry_name\sub 1, 1
-          entry_path = @root .. "#{path}/#{entry_name}"
-          if 'directory' ~= lfs.attributes entry_path, 'mode'
-            continue
-
-          entries[entry_name] = "#{path}/#{entry_name}"
-
-        -- where we will store our sorted list of children
-        sorted = {}
-
-        -- check for existance of the order file
-        order_file = @root .. "#{path}/$order"
-        if 'file' == lfs.attributes order_file, 'mode'
-          for line in io.lines order_file
-            path = assert entries[line], "entry in $order but not on disk: #{line}"
-            
-            -- add all $order-entries to the sorted output in the same order they appear.
-            -- also flag these entries as already added
-            table.insert sorted, path
-            sorted[line] = true
-
-        -- find the he remaining (non-flagged) entries, sort them alphabetically
-        -- and then append them to the sorted output list
-        entries = [path for entry, path in pairs entries when not sorted[entry]]
-        table.sort entries
-        for path in *entries
-          table.insert sorted, path
-
-        -- return an iterator over the sorted output
-        coroutine.wrap ->
-          for path in *sorted
-            coroutine.yield path
-
-The interface for reordering fileders is still missing in the code,
-and just while writing this I realized that the current implementation is in fact buggy:
-when a fileder that is mentioned in `$order` is deleted via the `stores.fs` API,
-it is not removed from `$order`, causing an error the next time the fileder is listed.
-I will probably get around to fixing both of these problems when I build the corresponding UI.
-
-[2019-10-24]: /articles/mmmfs/ba_log/2019-10-24/
-[a62f63b]: https://git.s-ol.nu/mmm/commit/a62f63bc00cd63a98b349a2574e3e9e14c95a441/
diff --git a/root/articles/mmmfs/ba_log/2019-10-27/$order b/root/articles/mmmfs/ba_log/2019-10-27/$order
deleted file mode 100644
index 2b68b52..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-27/$order
+++ /dev/null
@@ -1 +0,0 @@
-video
diff --git a/root/articles/mmmfs/ba_log/2019-10-27/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-27/text$markdown.md
deleted file mode 100644
index 3e9f886..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-27/text$markdown.md
+++ /dev/null
@@ -1,77 +0,0 @@
-Today I finally reached the ability of editing content inside of mmmfs directly!
-
-<mmm-embed path="video" nolink></mmm-embed>
-
-Content is currently not saved anywhere, but the basis of the feature is there.
-For the moment this is implemented as yeat another *convert* that simply converts
-from `text/.*` (any textual code) to `mmm/dom` (web UI) \[[`28653c9`][28653c9]\].
-However this *convert* is only applied in the inspector view (more on that below).
-First, here is the convert itself:
-
-    {
-      inp: 'text/([^ ]*).*'
-      out: 'mmm/dom'
-      cost: 0
-      transform: (value, fileder, key) =>
-        mode = @from\match @convert.inp
-        Editor value, mode, fileder, key
-    }
-
-and the main part of the code, the `Editor` widget:
-
-```moonscript
-class Editor
-  new: (value, mode, @fileder, @key) =>
-    @node = div class: 'editor'
-    -- 'o' is a little helper for converting a Lua table to a JS object
-    @cm = window\CodeMirror @node, o {
-      :value
-      :mode
-      lineNumber: true
-      lineWrapping: true
-      autoRefresh: true
-      theme: 'hybrid'
-    }
-
-    @cm\on 'changes', (_, mirr) ->
-      window\clearTimeout @timeout if @timeout
-      @timeout = window\setTimeout (-> @change!), 300
-
-  change: =>
-    @timeout = nil
-    doc = @cm\getDoc!
-    if @lastState and doc\isClean @lastState
-      -- no changes since last event
-      return
-    
-    @lastState = doc\changeGeneration true
-    value = doc\getValue!
-
-    @fileder.facets[@key] = value
-    BROWSER\refresh!
-```
-
-I chose the [CodeMirror][codemirror] library as the basis for the editor,
-because it seemed like one of the leanest ones I could find
-(and yet it is quite heavy at 100kb plus styling and language support addons).
-The code for the editor is also quite minimale it really just creates a wrapper for the editor
-and tells CodeMirror to set itself up inside.
-Whenever changes are detected, a timeout of 300ms is started,
-after which the preview is refreshed to preview the changes.
-If more changes are made within the 300ms, the timer is reset to 300ms,
-so that the preview update doesn't interrupt the typing flow.
-
-I also spent some time refactoring the global list of converts out into multiple smaller plugins
-(although a lot of global converts remain at the moment) \[[`abefbf8`][abefbf8]\].
-A plugin can export a list of converts as well as a list of 'editors', which are essentially no different,
-except that they are taken into consideration only when converting content for the inspector. 
-
-Breaking the converts up into little packages like that makes it a lot easier to edit,
-and allows enabling and disabling individual features very easily.
-I am also considering moving the converts into the mmmfs data itself,
-to make extending the system and working inside the system more congruent,
-and this is a good way of testing my idea of how the modularization of the system should work.
-
-[codemirror]: https://codemirror.net/
-[28653c9]: https://git.s-ol.nu/mmm/commit/28653c9ae46b2b3e42c2c75879589138c731f37b/
-[abefbf8]: https://git.s-ol.nu/mmm/commit/abefbf82531021f5ca4149675932a7fe2ff37dde/
diff --git a/root/articles/mmmfs/ba_log/2019-10-27/video/video$webm.webm b/root/articles/mmmfs/ba_log/2019-10-27/video/video$webm.webm
deleted file mode 100644
index 020e352..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-27/video/video$webm.webm
+++ /dev/null
diff --git a/root/articles/mmmfs/ba_log/2019-10-29/$order b/root/articles/mmmfs/ba_log/2019-10-29/$order
deleted file mode 100644
index 2b68b52..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-29/$order
+++ /dev/null
@@ -1 +0,0 @@
-video
diff --git a/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md
deleted file mode 100644
index 4119d21..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md
+++ /dev/null
@@ -1,38 +0,0 @@
-Today I implemented updating/saving content in the server, and bridged the feature to the client.
-In the inspector there is now a `save changes` button that (attempts to) save the content on
-the server's filesystem \[[`4b8d9be`][4b8d9be]\].
-
-<mmm-embed path="video" nolink>demonstration of editing and persistantly saving facet</mmm-embed>
-
-Originally I wanted to create a `sandbox` fileder that was to be edited by any one online \[[`d9eafa2`][d9eafa2]\].
-I restricted editing to only fileders underneath `/sandbox`, but then upon publishing quickly realized
-that this left open a major security vulnerability, since content can be evaluated on server or client:
-if a client were to create a facet `exploit: text/lua -> text/plain` with the following content in the root:
-
-```lua
-pass = io.open('/etc/passwd', 'r')
-return pass:read("*all")
-```
-
-...and then request that facet as converted to `text/plain` (`GET /exploit: text/plain`),
-then that Lua code would be executed on the server, and return the confidential `passwd` file on the server.
-This basically meant handing anyone online full unconditionaly access to my server
-(or at least the VM running the website, and potentially options to escalate from there).
-
-As a result I had to choose to either disable public editing, or disable server-side code execution.
-Because server-side execution is a major feature of mmmfs, I settled for the following compromise \[[`1e3b0a1`][1e3b0a1]\]: 
-
-- when developing and running locally, editing and code execution are both enabled in 'unsafe mode'
-- on https://ba.s-ol.nu, editing is disabled but code execution is possible
-- on https://sandbox.s-ol.nu, editing is enabled but code server-side code execution is disabled
-
-The Sandbox can now be found at the following address, at least until the thesis project is concluded:
-
-# [`sandbox.s-ol.nu`](https://sandbox.s-ol.nu)
-
-Currently it is only possible to edit existing facets,
-but creation and deletion of facets and fileders should be implemented soon.
-
-[4b8d9be]: https://git.s-ol.nu/mmm/commit/4b8d9be10e4517114c0c216fa24aaaa310503d4a/
-[d9eafa2]: https://git.s-ol.nu/mmm/commit/d9eafa21ad1d6ad340b5744d69e9fc68ce2083cb/
-[1e3b0a1]: https://git.s-ol.nu/mmm/commit/1e3b0a12060dce916b686921c94520202c4cb130/
diff --git a/root/articles/mmmfs/ba_log/2019-10-29/video/video$mp4.mp4 b/root/articles/mmmfs/ba_log/2019-10-29/video/video$mp4.mp4
deleted file mode 100644
index 162d0fc..0000000
--- a/root/articles/mmmfs/ba_log/2019-10-29/video/video$mp4.mp4
+++ /dev/null
diff --git a/root/articles/mmmfs/ba_log/2019-11-01/$order b/root/articles/mmmfs/ba_log/2019-11-01/$order
deleted file mode 100644
index 1549b67..0000000
--- a/root/articles/mmmfs/ba_log/2019-11-01/$order
+++ /dev/null
@@ -1 +0,0 @@
-demo
diff --git a/root/articles/mmmfs/ba_log/2019-11-01/demo/video$webm.webm b/root/articles/mmmfs/ba_log/2019-11-01/demo/video$webm.webm
deleted file mode 100644
index 1463897..0000000
--- a/root/articles/mmmfs/ba_log/2019-11-01/demo/video$webm.webm
+++ /dev/null
diff --git a/root/articles/mmmfs/ba_log/2019-11-01/text$markdown.md b/root/articles/mmmfs/ba_log/2019-11-01/text$markdown.md
deleted file mode 100644
index afcaf0a..0000000
--- a/root/articles/mmmfs/ba_log/2019-11-01/text$markdown.md
+++ /dev/null
@@ -1,18 +0,0 @@
-In the last two days I implemented the remaining features for full editing support in the browser:
-
-- support for adding, removing facets in the inspector \[[`dc08e26`][dc08e26]\]
-- support for adding, removing fileders in the inspector \[[`ff9ee8e`][ff9ee8e]\]
-- implemented the API for reordering fileders as mentioned in [`2019-10-26`][2019-10-26] \[[`053e607`][053e607]\]
-- support for reordering fileders in the inspector \[[`16232a2`][16232a2]\]
-
-Here is a short demo video of these features:
-
-<mmm-embed nolink path="demo"></mmm-embed>
-
-As usual, this can be tried out immediately at [`sandbox.s-ol.nu`](//sandbox.s-ol.nu)
-
-[2019-10-26]: /articles/mmmfs/ba_log/2019-10-26/
-[dc08e26]: https://git.s-ol.nu/mmm/commit/dc08e262cd53a48480a88235aa58500f0638ad79/
-[ff9ee8e]: https://git.s-ol.nu/mmm/commit/ff9ee8e99cd5f5c420ba0501c335ac18f1b10769/
-[053e607]: https://git.s-ol.nu/mmm/commit/053e607a49989b2d4491c20ff14c839b7161d713/
-[16232a2]: https://git.s-ol.nu/mmm/commit/16232a2509a87a900b69b2d0f826a2e3edec3f96/
diff --git a/root/articles/mmmfs/ba_log/2019-11-25/$order b/root/articles/mmmfs/ba_log/2019-11-25/$order
deleted file mode 100644
index 1549b67..0000000
--- a/root/articles/mmmfs/ba_log/2019-11-25/$order
+++ /dev/null
@@ -1 +0,0 @@
-demo
diff --git a/root/articles/mmmfs/ba_log/2019-11-25/demo/video$webm.webm b/root/articles/mmmfs/ba_log/2019-11-25/demo/video$webm.webm
deleted file mode 100644
index bdf9d9c..0000000
--- a/root/articles/mmmfs/ba_log/2019-11-25/demo/video$webm.webm
+++ /dev/null
diff --git a/root/articles/mmmfs/ba_log/2019-11-25/text$markdown.md b/root/articles/mmmfs/ba_log/2019-11-25/text$markdown.md
deleted file mode 100644
index 48a0bb4..0000000
--- a/root/articles/mmmfs/ba_log/2019-11-25/text$markdown.md
+++ /dev/null
@@ -1,89 +0,0 @@
-There was a longer break in development of the projects as I have been focusing on the thesis,
-where progress is not represented accurately in the repository.
-
-There was also some progress on featurse that haven't been tidied up and committed yet,
-such as drag'n'drop / direct file upload. Those features will probably get their own post sometime soon.
-
-Today I spent some time to implement one of the example use-cases that will be part of the theoretical text as well,
-[the 'pinwall' demo][pinwall] \[[`5ec1fe2`][5ec1fe2]\].
-
-The Pinwall example renders all its children as resizeable and movable boxes that can be freely positioned on a canvas:
-
-<mmm-embed nolink path="demo"></mmm-embed>
-
-Any changes to the box positions and sizes are saved persistently as a `pinwall_info` facet on each child.
-For example the size and coordinates of the image can be found at [`image/pinwall_info: text/json`][info].
-
-Rendering the children themselves is pretty easy:
-
-```moon
-import article, div from require 'mmm.dom'
-import convert from require 'mmm.mmmfs.conversion'
-
-update_info = (fileder, x, y, w, h) ->
-  info = (fileder\get 'pinwall_info: table') or x: 100, y: 100, w: 300, h: 300
-  info.x = x if x
-  info.y = y if y
-  info.w = w if w
-  info.h = h if h
-
-  json = convert 'table', 'text/json', info, fileder, 'pinwall_info'
-  fileder\set 'pinwall_info: text/json', json
-  
-=>
-  observe = ... -- (ommited - calls `update_info` when child is resized)
-
-  children = for child in *@children
-      info = (child\get 'pinwall_info: table') or x: 100, y: 100, w: 300, h: 300
-      wrapper = div {
-        style:
-          position: 'absolute'
-          -- (more styling omitted here)
-
-          left: "#{info.x}px"
-          top: "#{info.y}px"
-          width: "#{info.w}px"
-          height: "#{info.h}px"
-
-        -- handle for moving the child
-        div {
-          style:
-            -- (styling omitted here)
-
-          onmousedown: ... -- (omitted)
-        }
-
-        -- child content
-        div {
-          style:
-            width: '100%'
-            height: '100%'
-            background: 'var(--white)'
-
-          (child\gett 'mmm/dom')
-        }
-      }
-      
-      observe wrapper, child
-
-      wrapper
-
-  children.style = {
-    width: '1000px'
-    height: '500px'
-  }
-  
-  children.onmouseup = ... -- (omitted)
-  children.onmousemove = ... -- (omitted)
-  children.onmouseleave = ... -- (omitted)
-  
-  article children
-```
-
-[The rest of the code][source] is just about catching the events when the mouse is clicked/release/moved and when a child is resized,
-and then calling `update_info` as appropriate.
-
-[info]: /articles/mmmfs/examples/pinwall/image/pinwall_info:%20text/html+interactive
-[pinwall]: /articles/mmmfs/examples/pinwall/
-[source]: https://git.s-ol.nu/mmm/blob/5ec1fe2fc943ad4123fac138de70d4152e8b341d/root/articles/mmmfs/examples/pinwall/text%24moonscript%20-%3E%20fn%20-%3E%20mmm%24dom.moon
-[5ec1fe2]: https://git.s-ol.nu/mmm/blob/5ec1fe2fc943ad4123fac138de70d4152e8b341d/
diff --git a/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md b/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md
deleted file mode 100644
index 3de1a9c..0000000
--- a/root/articles/mmmfs/ba_log/2019-12-20/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,39 +0,0 @@
-In the last three days I have been working extensively on support for sidenotes and academic referencing,
-inspired by Edward Tufte's style of publishing (as seen in *Beatiful Evidence* and documented in [tufte-css][tufte-css].
-
-To this end margin-notes have been implemented in the CSS styling of the page using two classes, `sidenote` and
-`sidenote-container`, which are to be applied to individual sidenotes and the containing document respectively.
-Sidenotes are then pulled out of their surrounding context using `position: absolute` and placed in a margin that is
-left free by `sidenote-container`.
-
-Inside of markdown files, sidenotes can then be added simply using basic HTML, like so:
-
-```md
-<div class="sidenote">additional information to be found on the margin</div>
-An example paragraph of text, describing something.
-```
-
-Which will render like this:
-
-> <div class="sidenote">additional information to be found on the margin</div>
-> An example paragraph of text, describing something.
-
-Additionally, conversions from `text/bibtex`, a reference specification format, to `mmm/dom` have been added, that
-create citations using the metadata available in the BibTeX file.
-
-For example the following BibTeX is rendered like this:
-
-<mmm-embed nolink path="../../references/inkandswitch" facet="markdown"></mmm-embed>
-
-> <mmm-embed wrap="raw" path="../../references/inkandswitch"></mmm-embed>
-
-I also added a special override that links to 
-BibTeX files by placing the citation in a sidenote, and adding a footnote indicator in-text.
-
-There is also a handy convert that turns ACM Digital Library links into URLs that directly return the BibTeX file,
-which allows me to cite the links directly without manually adding the BibTeX information to my document.
-
-All of this is implemented in the `cites` plug-in: [`cites.moon`][cites.moon].
-
-[cites.moon]: https://git.s-ol.nu/mmm/blob/ba/mmm/mmmfs/plugins/cites.moon
-[tufte-css]: https://edwardtufte.github.io/tufte-css/
diff --git a/root/articles/mmmfs/ba_log/intro: text$markdown.md b/root/articles/mmmfs/ba_log/intro: text$markdown.md
deleted file mode 100644
index 37366cf..0000000
--- a/root/articles/mmmfs/ba_log/intro: text$markdown.md
+++ /dev/null
@@ -1,4 +0,0 @@
-The following pages document the development of the `mmmfs` system described above in the form of a project log.
-Please note that the log has been written primarily for viewing using a web browser, and as such makes extensive use of
-hyperlinking, and also includes some videos that cannot be reproduced in print. It is therefore recommended to view the
-live version of the log online at the following address: [s-ol.nu/ba/log](https://s-ol.nu/ba/log).
diff --git a/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 97ebd4c..0000000
--- a/root/articles/mmmfs/ba_log/print: text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,19 +0,0 @@
-import div, section, h1, h2, hr from require 'mmm.dom'
-import link_to from (require 'mmm.mmmfs.util') require 'mmm.dom'
-import ropairs from require 'mmm.ordered'
-
-=>
-  div {
-    class: 'print-ownpage'
-
-    h1 (link_to @, "appendix: project log"), id: 'ba-log'
-    @gett 'intro: mmm/dom'
-    table.unpack for post in *@children
-      continue if post\get 'hidden: bool'
-
-      section {
-        hr!
-        h2 link_to post, post\gett 'name: mmm/dom'
-        (post\gett 'mmm/dom')
-      }
- }
diff --git a/root/articles/mmmfs/ba_log/start/text$markdown.md b/root/articles/mmmfs/ba_log/start/text$markdown.md
deleted file mode 100644
index d56130b..0000000
--- a/root/articles/mmmfs/ba_log/start/text$markdown.md
+++ /dev/null
@@ -1,25 +0,0 @@
-The system described in the thesis and subject to the following blog posts was partially pre-existing to the work
-done as part of the thesis and thesis project. The `mmmfs` system was originally developed as the software for my
-personal website, with development beginning around May 2018. In this phase of development the website and system
-changed shape drastically multiple times.  In the following paragraphs I will describe the state of the project at
-the last revision prior to the beginning of the thesis project, as it existed before the 7th of October 2019.
-All developments since this revision have been tracked in the following project log entries, and are to be considered
-the practical contributions to the thesis project.
-
-In this revision, the system existed as a tool to produce a static website representing the contents of the `mmmfs`
-system in browsable HTML format. The tool had to be run manually after changes, or using a build tool like [`tup`][tup].
-A primitive *Inspector* tab was present in the HTML output and allowed viewing the raw `mmmfs` contents, but all editing
-of content had to be done with external tools and in the external file-system. To see changes in the browser, a
-compilation phase had to be triggered and completed, and consecutively the page reloaded in the browser. There was no
-server-side component that could convert content or store changes for clients. The tool could only accept content from
-the filesystem, not from zip archives or SQLite databases. The conversion algorithm used was more naive and was not
-able to track cost values, which meant that some more advanced conversions couldn't be implemented.
-
-There was already an example implementation of a simple slideshow present, but due to the lack of editing capabilities
-there was no pinwall examle. There was also no support for side- or marginnotes, or academic referencing and citations.
-There also was no support for [`mermaid`][mermaid] diagrams or JSON-encoded data, and there was no plugin interface.
-The HTML template, CSS styling and JS runtime were all built and tracked outside of the `mmmfs` system itself.
-There was no unit tests for any of the project.
-
-[tup]: http://gittup.org/tup/
-[mermaid]: https://mermaidjs.github.io/
diff --git a/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index b6b0756..0000000
--- a/root/articles/mmmfs/ba_log/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,15 +0,0 @@
-import div, h1, ul, li from require 'mmm.dom'
-import link_to from (require 'mmm.mmmfs.util') require 'mmm.dom'
-import ropairs from require 'mmm.ordered'
-
-=>
-  div {
-    h1 (link_to @, "appendix: project log"), id: 'ba-log'
-    @gett 'intro: mmm/dom'
-    ul do
-      posts = for post in *@children
-        continue if post\get 'hidden: bool'
-        li link_to post, post\gett 'name: mmm/dom'
-
-      posts
-  }
diff --git a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md b/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md
deleted file mode 100644
index 92230a0..0000000
--- a/root/articles/mmmfs/conclusion/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,11 +0,0 @@
-# 8&emsp;conclusion
-
-The historical analysis and the evaluation of the proposed system show that many of the limitations of current
-mainstream operating systems can be worked around effectively. The flaws can also be attributed in part to some
-concrete design paradigms, which future system designers may seek to avoid. To this end, the framework provided for
-evaluation may also be useful.
-
-The system proposed and developed in the project corresponding to this thesis has been shown to successfully implement
-many of the properties were hoped to be achieved, such as a modular and consistent architecture and strong support for
-mixed-content transclusions. On the other hand, some limitations in the design are apparent. Many of these limitations
-constitute candidate topics for further research, and most can be attributed to trade-offs made in the development process.
diff --git a/root/articles/mmmfs/description: text$plain b/root/articles/mmmfs/description: text$plain
deleted file mode 100644
index 1322f1d..0000000
--- a/root/articles/mmmfs/description: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-a file, operating and content-management system to live in (powers this site)
diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
deleted file mode 100644
index 65024d4..0000000
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# 7&emsp;evaluation
-In this section, I will first take a look at the implementations of the examples for the use cases outlined above,
-and evaluate them with regard to the framework derived in the corresponding section above. After that, some general
-concerns and insights that have become apparent while developing the system and working with it will be reviewed.
-
-## 7.1&emsp;examples
-### 7.1.1&emsp;publishing and blogging
-Since mmmfs has grown out of the need for a versatile content management system for a personal website and blog, it is
-not surprising to see that it is still up to that job. Nevertheless, it is worth taking a look at its strengths and
-weaknesses in this context:
-
-The system has proven itself perfect for publishing small- and medium-size articles and blog posts, especially for its
-ability to flexibly transclude content from any source. This includes diagrams (such as in this thesis),
-videos (as in the documentation in the appendix), but also less conventional media such as
-interactive diagrams<mmm-embed path="../references/aspect-ratios" wrap="sidenote"></mmm-embed> or twitter postings.
-
-On the other hand, the development of the technical framework for this thesis has posed greater challenges.
-While the reference and sidenote systems integrated well with the rest of the system, some features like automated
-table-of-contents and section numbering were less obvious to tackle and finally completed manually.
-This is mostly due to the approach of splitting up the thesis into a multitude of fileders, and the current lack of
-mechanisms to re-capture information spread throughout the resulting hierarchy effectively.
-
-### 7.1.2&emsp;pinwall
-The pinwall example shows some strengths of the mmmfs system pretty convincingly.
-The type coercion layer completely abstracts away the complexities of transcluding different types of content,
-and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
-
-A great benefit of the use of mmmfs versus other technology for realizing this example is that the example can
-seamlessly embed not only plain text, markdown, images, videos, and interactive widgets, but also follow links to all
-of these types of content, and display them meaningfully. Accomplishing this with traditional frameworks would take
-great effort, where mmmfs benefits from the reuse of these conversions across the whole system.
-
-In addition, the script for the pinwall folder is 120 lines long, of which 30 lines are styling, while almost 60 lines
-take care of capturing and handling JS events. The bulk of complexity is therefore shifted towards interacting with the
-UI layer (in this case the browser), which could feasibly be simplified through a custom abstraction layer or the use of
-output means other than the web.
-
-### 7.1.3&emsp;slideshow
-A simplified image slideshow example consists of only 20 lines of code and demonstrates how the reactive component
-framework simplifies the generation of ad-hoc UI dramatically:
-
-```moon
-import ReactiveVar, text, elements from require 'mmm.component'
-import div, a, img from elements
-
-=>
-  index = ReactiveVar 1
-
-  prev = (i) -> math.max 1, i - 1
-  next = (i) -> math.min #@children, i + 1
-
-  div {
-    div {
-      a 'prev', href: '#', onclick: -> index\transform prev
-      index\map (i) -> text " image ##{i} "
-      a 'next', href: '#', onclick: -> index\transform next
-    },
-    index\map (i) ->
-      child = assert @children[i], "image not found!"
-      img src: @children[i]\gett 'URL -> image/png'
-  }
-```
-
-The presentation framework is a bit longer, but the added complexity is again required to deal with browser quirks,
-such as the fullscreen API and sizing content proportionally to the viewport size.
-The parts of the code dealing with the content are essentially identical, except that content is transcluded via the
-more general `mmm/dom` type-interface, allowing for a greater variety of types of content to be used as slides.
-
-## 7.2&emsp;general concerns
-While the system has proven pretty successful and moldable to the different use-cases that it has been tested in,
-there are also limitations in the proposed system that have become obvious in developing and working with the system.
-In this section, these limitations will be discussed individually, and directions for further research and solutions will
-be given where apparent.
-
-### 7.2.1&emsp;global set of converts
-In the current system, there is only a single, global set of *converts* that can be potentially applied to facets
-anywhere in the system.
-Therefore it is necessary to encode behavior directly (as code) in facets wherever exceptional behavior is required.
-For example, if a fileder containing multiple images wants to provide custom UI for each image when viewed independently,
-this code has to either be attached to every image individually (and redundantly), or added as a global convert.
-To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce
-a new type and change the images to use it, which may present even more problems, and works against the principle of
-compatibility that the system has been constructed for.
-
-A potential direction of research in the future is to allow specifying *converts* as part of the fileder tree.
-Application of *converts* could then be scoped to their fileders' subtrees, such that for any facet only the *converts*
-stored in the chain of its parents upwards are considered.
-This way, *converts* can be added locally if they only make sense within a given context.
-Additionally, it could be made possible to use this mechanism to locally override *converts* inherited from
-further up in the tree, for example, to specialize types based on their context in the system.
-
-<mmm-embed wrap="marginnote" path="../references/alternatives-to-trees">See also </mmm-embed>
-The biggest downside to this approach would be that it  presents another pressure factor for, while also reinforcing,
-the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
-
-### 7.2.2&emsp;code outside of the system
-At the moment, a large part of the mmmfs codebase is still separate from the content and developed outside of mmmfs
-itself. This is a result of the development process of mmmfs and was necessary to start the project as the filesystem
-itself matured, but has now become a limitation of the user experience: potential users of mmmfs would generally start
-by becoming familiar with the operation of mmmfs from within the system, as this is the expected (and designated)
-experience developed for them. All of the code that lives outside of the mmmfs tree is therefore invisible and opaque
-to them, actively limiting their understanding, and thereby the customizability, of the system.
-
-This weakness represents a failure to (fully) implement the quality of a "Living System" as proposed by
-*Ink and Switch*<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>.
-
-In general, however, some portion of code may always have to be left outside of the system.
-This also wouldn't necessarily represent a problem, but in this case it is particularly relevant
-for the global set of *converts* (see above), as well as the layout used to render the web view. 
-Both of these are expected to undergo changes as users adapt the system to their own content types and
-domains of interest, as well as their visual identity, respectively.
-
-### 7.2.3&emsp;type system
-The currently used type system based on strings and pattern matching has been largely satisfactory
-but has proven problematic for some anticipated use cases.
-It should be considered to switch to a more intricate,
-structural type system that allows encoding more concrete meta-data alongside the type,
-and to match *converts* based on a more flexible scheme of pattern matching.
-For example, it is envisaged to store the resolution of an image file in its type.
-Many *converts* might choose to ignore this additional information,
-but others could use this information to generate lower-resolution 'thumbnails' of images automatically.
-Using these mechanisms for example images could be requested with a maximum-resolution constraint to save on bandwidth
-when embedded in other documents.
-
-<div style="break-before: page;"></div>
-
-### 7.2.4&emsp;type-coercion
-By giving the system more information about the data it is dealing with,
-and then relying on the system to automatically transform between data-types,
-it is easy to lose track of which format data is concretely stored in.
-In much the same way that the application-centric paradigm alienates users from an understanding
-and feeling of ownership of their data by overemphasizing the tools in between,
-the automagical coercion of data types introduces distance between the user and
-an understanding of the data in the system.
-This poses a threat to the transparency of the system, and potentially a lack of the "Embodiment" quality (see above).
-
-Potential solutions could be to communicate the conversion path clearly and explicitly together with the content,
-as well as making this display interactive to encourage experimentation with custom conversion queries.
-Emphasizing the conversion process more strongly in this way might be a way to turn this feature from an opaque
-hindrance into a transparent tool. This should represent a challenge mostly in terms of UX and UI design.
-
-### 7.2.5&emsp;in-system editing
-Because many *converts* are not necessarily reversible, it is very hard to implement generic ways of editing stored data
-in the same format it is viewed. For example, the system trivially converts markdown-formatted text sources into
-viewable HTML markup, but it is hardly possible to propagate changes to the viewable HTML back to the markdown source.
-This particular instance of the problem might be solvable using a Rich-Text editor, but the general problem worsens when
-the conversion path becomes more complex: If the markdown source was fetched via HTTP from a remote URL (e.g. if the
-facet's type was `URL -> text/markdown`), it is not possible to edit the content at all, since the only data owned by
-the system is the URL string itself, which is not part of the viewable representation. Similarly, when viewing output
-that is generated by code (e.g. `text/moonscript -> mmm/dom`), the code itself is not visible to the user, and if the
-user wishes to change parts of the representation, the system is unable to relate these changes to elements of the code
-or assist the user in doing so.
-
-However, even where plain text is used and edited, a shortcoming of the current approach to editing is evident:
-The content editor is wholly separate from the visible representation, and only facets of the currently viewed fileder
-can be edited. This means that content cannot be edited in its context, which is exacerbated by the extreme
-fragmentation of content that mmmfs encourages. 
-
-As a result, interacting with the system at large is still a very different experience from editing content (and
-thereby extending the system) in it. This is expected to represent a major hurdle for users getting started with the
-system and is a major shortcoming in enabling end-user programming, as set as a goal for this project.
-A future iteration should carefully reconsider how editing could be integrated more holistically with the other core
-concepts of the design.
-
-<div style="break-before: page;"></div>
-
-### 7.2.6&emsp;end-user adoption
-As mentioned above, a conscious choice was made to exclude the implementation of a dedicated end-user programming
-facility in the system, and instead conventional programming languages and mechanisms were relied upon as the central
-way of customizing the system and experience. While this was a crucial choice to make in order to proceed with the
-project as a whole, it means that the system currently can not be adopted and used to its full extent by
-end-users. This also means that a full evaluation of the system with regard to end-user empowerment has to be left open
-until this can be changed by further work.
diff --git a/root/articles/mmmfs/examples/$order b/root/articles/mmmfs/examples/$order
deleted file mode 100644
index 4ee3140..0000000
--- a/root/articles/mmmfs/examples/$order
+++ /dev/null
@@ -1,5 +0,0 @@
-language_support
-image
-markdown
-gallery
-pinwall
diff --git a/root/articles/mmmfs/examples/gallery/$order b/root/articles/mmmfs/examples/gallery/$order
deleted file mode 100644
index 9d438bd..0000000
--- a/root/articles/mmmfs/examples/gallery/$order
+++ /dev/null
@@ -1,2 +0,0 @@
-link_to_image
-actual_image
diff --git a/root/articles/mmmfs/examples/gallery/actual_image/image$png.png b/root/articles/mmmfs/examples/gallery/actual_image/image$png.png
deleted file mode 100644
index b499413..0000000
--- a/root/articles/mmmfs/examples/gallery/actual_image/image$png.png
+++ /dev/null
diff --git a/root/articles/mmmfs/examples/gallery/actual_image/preview: image$png.png b/root/articles/mmmfs/examples/gallery/actual_image/preview: image$png.png
deleted file mode 100644
index f9dbfad..0000000
--- a/root/articles/mmmfs/examples/gallery/actual_image/preview: image$png.png
+++ /dev/null
diff --git a/root/articles/mmmfs/examples/gallery/link_to_image/URL -> image$png b/root/articles/mmmfs/examples/gallery/link_to_image/URL -> image$png
deleted file mode 100644
index 7cf76ff..0000000
--- a/root/articles/mmmfs/examples/gallery/link_to_image/URL -> image$png
+++ /dev/null
@@ -1 +0,0 @@
-https://picsum.photos/600/600/?image=101
diff --git a/root/articles/mmmfs/examples/gallery/link_to_image/preview: URL -> image$png b/root/articles/mmmfs/examples/gallery/link_to_image/preview: URL -> image$png
deleted file mode 100644
index 2b2233b..0000000
--- a/root/articles/mmmfs/examples/gallery/link_to_image/preview: URL -> image$png
+++ /dev/null
@@ -1 +0,0 @@
-https://picsum.photos/200/200/?image=101
diff --git a/root/articles/mmmfs/examples/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon b/root/articles/mmmfs/examples/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon
deleted file mode 100644
index 0178ac2..0000000
--- a/root/articles/mmmfs/examples/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon
+++ /dev/null
@@ -1,19 +0,0 @@
-import ReactiveVar, text, elements from require 'mmm.component'
-import div, a, img from elements
-
-=>
-  index = ReactiveVar 1
-
-  prev = (i) -> math.max 1, i - 1
-  next = (i) -> math.min #@children, i + 1
-
-  div {
-    div {
-      a 'prev', href: '#', onclick: -> index\transform prev
-      index\map (i) -> text " image ##{i} "
-      a 'next', href: '#', onclick: -> index\transform next
-    },
-    index\map (i) ->
-      child = assert @children[i], "image not found!"
-      img src: @children[i]\gett 'URL -> image/png'
-  }
diff --git a/root/articles/mmmfs/examples/gallery/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/gallery/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 9bdac54..0000000
--- a/root/articles/mmmfs/examples/gallery/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,12 +0,0 @@
-import div, h1, a, img, br from require 'mmm.dom'
-
-=>
-  link = (child) -> a {
-    href: '#',
-    onclick: -> BROWSER\navigate child.path
-    img src: child\gett 'preview', 'URL -> image/png'
-  }
-
-  content = [link child for child in *@children]
-  table.insert content, 1, h1 'gallery index'
-  div content
diff --git a/root/articles/mmmfs/examples/gallery/title: text$plain b/root/articles/mmmfs/examples/gallery/title: text$plain
deleted file mode 100644
index 2e9ef34..0000000
--- a/root/articles/mmmfs/examples/gallery/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-a gallery of images
diff --git a/root/articles/mmmfs/examples/image/URL -> image$png b/root/articles/mmmfs/examples/image/URL -> image$png
deleted file mode 100644
index c586722..0000000
--- a/root/articles/mmmfs/examples/image/URL -> image$png
+++ /dev/null
@@ -1 +0,0 @@
-https://picsum.photos/200?random
diff --git a/root/articles/mmmfs/examples/image/title: text$plain b/root/articles/mmmfs/examples/image/title: text$plain
deleted file mode 100644
index dca924f..0000000
--- a/root/articles/mmmfs/examples/image/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-link to a remote image
diff --git a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md
deleted file mode 100644
index 8a6a185..0000000
--- a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md
+++ /dev/null
@@ -1,88 +0,0 @@
-## 6.1&emsp;publishing and blogging
-### 6.1.1&emsp;blogging
-Blogging is pretty straightforward since it generally just involves publishing lightly-formatted text,
-interspersed with media such as images and videos or perhaps social media posts.
-Markdown is a great tool for this job, and has been integrated into the system to much success:
-There are two different types registered with *converts*: `text/markdown` and `text/markdown+span`.
-They both render to HTML (and DOM nodes), so they are immediately viewable as part of the system.
-The only difference for `text/markdown+span` is that it is limited to a single line,
-and doesn't render as a paragraph but rather just a line of text.
-This makes it suitable for denoting formatted-text titles and other small strings of text. 
-
-The problem of embedding other content together with text comfortably is also solved easily
-because Markdown allows embedding arbitrary HTML in the document.
-This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
-`<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmmfs.
-
-### 6.1.2&emsp;academic publishing
-<div class="sidenote" style="margin-top: 1.25rem">
-One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
-is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
-since it does not support interaction.
-</div>
-
-Academic publishing is notoriously complex, involving not only the transclusion of diagrams
-and other media but generally requiring precise and consistent control over formatting and layout.
-Some of these complexities are tedious to manage but present good opportunities for programmatic
-systems and media to do work for the writer.
-
-One such topic is the topic of references.
-References appear in various formats at multiple positions in an academic document;
-usually, they are referenced via a reduced visual form within the text of the document
-and then shown again with full details at the end of the document.
-
-For the sake of this thesis, referencing has been implemented using a subset of the popular
-BibTeX format for describing citations. Converts have been implemented for the `text/bibtex`
-type to convert to a full reference format (to `mmm/dom`) and to an inline side-note reference
-(`mmm/dom+link`) that can be transcluded using the `<mmm-link>` pseudo-tag.
-
-For convenience, a convert from the `URL -> cite/acm` type has been provided to `URL -> text/bibtex`,
-which generates links to the ACM Digital Library<mmm-embed path="../references/acm-dl" wrap="sidenote"></mmm-embed>
-API for accessing BibTeX citations for documents in the library. This means that it is enough to store the link to the
-ACM DL entry in mmmfs, and the reference will automatically be fetched, and therefore stay up to date with potential
-remote corrections.
-
-## 6.2&emsp;pinwall
-In many situations, and particularly for creative work, it is often useful to compile resources of
-different types for reference or inspiration and arrange them spatially so that they can be viewed
-at a glance or organized into different contexts, etc.
-Such a pinwall could serve for example to organize references to articles,
-to collect visual inspiration for a mood board, etc.
-
-As a collection, the Pinwall is primarily mapped to a Fileder in the system.
-Any content that is placed within can then be rendered by the Pinwall,
-which can constrain every piece of content to a rectangular piece on its canvas.
-This is possible through a simple script, e.g. of the type `text/moonscript -> fn -> mmm/dom`,
-which enumerates the list of children, wraps each in such a rectangular container
-and outputs the list of containers as DOM elements.
-
-The position and size of each panel are stored in an ad-hoc facet, encoded in the JSON data format:
-`pinwall_info: text/json`. Such a facet is set on each child and read whenever the script is called
-to render the children, plugging the values within the facet into the visual styling of the document.
-
-The script can also set event handlers that react to user input while the document is loaded,
-and allow the user to reposition and resize the individual pinwall items by clicking and dragging
-on the upper border or lower right-hand corner respectively.
-Whenever a change is made the event handler can then update the value in the `pinwall_info` facet,
-so that the updated position and size are stored for the next time the pinwall is opened.
-
-## 6.3&emsp;slideshow
-Another common use of digital documents is as aids in a verbal presentation.
-These often take the form of slideshows, for the creation of which a number of established applications exist.
-In simple terms, a slideshow is simply a linear series of screen-sized documents, that can be
-advanced (and rewound) one by one using keypresses.
-
-The implementation of this is rather straightforward as well.
-The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
-as well as a control interface with keys for advancing the active slide.
-It also allows putting the browser into fullscreen mode to maximize screen space and remove  visual elements
-of the website that may distract from the presentation, and register an event handler for keyboard accelerators
-for moving through the presentation.
-
-Finally, the script simply embeds the first of its child-fileders into the viewport rectangle.
-Once the current slide is changed, the next embedded child is simply chosen.
-
-<!--
-## code documentation
-/meta/mmm.dom/:%20text/html+interactive
--->
diff --git a/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md
deleted file mode 100644
index 126f407..0000000
--- a/root/articles/mmmfs/examples/intro: text$markdown+sidenotes.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# 6&emsp;example use-cases
-To illustrate the capabilities of the proposed system, and to compare the results with the framework introduced above,
-a number of example use cases have been chosen and implemented from the perspective of a user.
-In the following section I will introduce these use cases and briefly summarize the implementation
-approach in terms of the capabilities of the proposed system.
-
-<div style="break-before: page;"></div>
-
-<span class="sidenote">The online version is available at [s-ol.nu/ba](https://s-ol.nu/ba).</span>
-The following examples can be viewed and inspected in the interactive version online:
diff --git a/root/articles/mmmfs/examples/language_support/$order b/root/articles/mmmfs/examples/language_support/$order
deleted file mode 100644
index 3cc0e47..0000000
--- a/root/articles/mmmfs/examples/language_support/$order
+++ /dev/null
@@ -1,3 +0,0 @@
-javascript
-moonscript
-lua
diff --git a/root/articles/mmmfs/examples/language_support/javascript/text$javascript -> mmm$dom.js b/root/articles/mmmfs/examples/language_support/javascript/text$javascript -> mmm$dom.js
deleted file mode 100644
index de56531..0000000
--- a/root/articles/mmmfs/examples/language_support/javascript/text$javascript -> mmm$dom.js
+++ /dev/null
@@ -1,15 +0,0 @@
-const e = (elem, children) => {
-  const node = document.createElement(elem);
-
-  if (typeof children === 'string')
-    node.innerText = children;
-  else
-    children.forEach(child => node.appendChild(child));
-
-  return node;
-};
-
-return e('article', [
-  e('h1', 'JavaScript'),
-  e('p', 'JavaScript is supported natively in the browser but is not currently pre-rendered on the server.'),
-]);
diff --git a/root/articles/mmmfs/examples/language_support/javascript/title: text$plain b/root/articles/mmmfs/examples/language_support/javascript/title: text$plain
deleted file mode 100644
index 581fbc7..0000000
--- a/root/articles/mmmfs/examples/language_support/javascript/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-JavaScript
diff --git a/root/articles/mmmfs/examples/language_support/lua/text$lua -> mmm$dom.lua b/root/articles/mmmfs/examples/language_support/lua/text$lua -> mmm$dom.lua
deleted file mode 100644
index 62e79f1..0000000
--- a/root/articles/mmmfs/examples/language_support/lua/text$lua -> mmm$dom.lua
+++ /dev/null
@@ -1,9 +0,0 @@
-local d = require 'mmm.dom'
-
-local lua = d.a { 'Lua', href = 'https://www.lua.org/' }
-local fengari = d.a { 'fengari.io', href = 'https://fengari.io/' }
-
-return d.article {
-  d.h1 'Lua',
-  d.p { lua, ' is fully supported using ', fengari, ' on the Client.' }
-}
diff --git a/root/articles/mmmfs/examples/language_support/lua/title: text$plain b/root/articles/mmmfs/examples/language_support/lua/title: text$plain
deleted file mode 100644
index 0f9d550..0000000
--- a/root/articles/mmmfs/examples/language_support/lua/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-Lua
diff --git a/root/articles/mmmfs/examples/language_support/moonscript/text$moonscript -> mmm$dom.moon b/root/articles/mmmfs/examples/language_support/moonscript/text$moonscript -> mmm$dom.moon
deleted file mode 100644
index 5cc50e6..0000000
--- a/root/articles/mmmfs/examples/language_support/moonscript/text$moonscript -> mmm$dom.moon
+++ /dev/null
@@ -1,10 +0,0 @@
-import a, article, h1, p from require 'mmm.dom'
-
-moonscript = a 'MoonScript', href: 'https://moonscript.org/'
-lua = a 'Lua', href: 'https://www.lua.org/'
-fengari = a 'fengari.io', href: 'https://fengari.io/'
-
-article {
-  h1 'MoonScript',
-  p moonscript, " is compiled to ", lua, " on the server, which is then executed on the client using ", fengari, "."
-}
diff --git a/root/articles/mmmfs/examples/language_support/moonscript/title: text$plain b/root/articles/mmmfs/examples/language_support/moonscript/title: text$plain
deleted file mode 100644
index f8871ac..0000000
--- a/root/articles/mmmfs/examples/language_support/moonscript/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-MoonScript
diff --git a/root/articles/mmmfs/examples/language_support/preview: text$markdown b/root/articles/mmmfs/examples/language_support/preview: text$markdown
deleted file mode 100644
index d6c2845..0000000
--- a/root/articles/mmmfs/examples/language_support/preview: text$markdown
+++ /dev/null
@@ -1,6 +0,0 @@
-this Fileder contains some minimal examples showing support for various languages `mmmfs` supports currently.
-
-Language support is mostly limited by the fact that `mmmfs` currently targets web browsers,
-on the server any scripting language that can be executed can theoretically be integrated with minimal effort.
-
-Using the inspector mode to view the source of the Fileders below is encouraged.
diff --git a/root/articles/mmmfs/examples/language_support/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/language_support/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 4ae0679..0000000
--- a/root/articles/mmmfs/examples/language_support/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,16 +0,0 @@
-import article, h1, p, ul, li, a from require 'mmm.dom'
-
-single = (a) -> a
-
-=>
-  children = for child in *@children
-    title = child\gett 'title: text/plain'
-    li a title, href: child.path, onclick: (e) =>
-      e\preventDefault!
-      BROWSER\navigate child.path
-
-  article {
-    h1 single @gett 'title: text/plain'
-    p single @gett 'preview: mmm/dom'
-    ul children
-  }
diff --git a/root/articles/mmmfs/examples/language_support/title: text$plain b/root/articles/mmmfs/examples/language_support/title: text$plain
deleted file mode 100644
index ae06474..0000000
--- a/root/articles/mmmfs/examples/language_support/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-scripting language support
diff --git a/root/articles/mmmfs/examples/markdown/text$markdown.md b/root/articles/mmmfs/examples/markdown/text$markdown.md
deleted file mode 100644
index 880eedb..0000000
--- a/root/articles/mmmfs/examples/markdown/text$markdown.md
+++ /dev/null
@@ -1,20 +0,0 @@
-This is a markdown document rendered using [marked][marked] on the client, and [discount][discount] on the server.
-All Markdown features are supported, for example there is support for lists...
-
-- a list of things
-- (two things)
-
-...and syntax-highlighted code tags:
-
-```
-print "Hello World"
-```
-
-Since Markdown supports inline HTML, mmmfs shorthands can also be used to embed and reference content from elsewhere in
-the system. For example, the title of this fileder can be embedded using
-`<mmm-embed facet="title"></mmm-embed>`:
-
-<mmm-embed facet="title"></mmm-embed>
-
-[marked]: https://marked.js.org/
-[discount]: https://luarocks.org/modules/craigb/discount
diff --git a/root/articles/mmmfs/examples/markdown/title: text$plain b/root/articles/mmmfs/examples/markdown/title: text$plain
deleted file mode 100644
index 7915148..0000000
--- a/root/articles/mmmfs/examples/markdown/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-markdown content
diff --git a/root/articles/mmmfs/examples/pinwall/$order b/root/articles/mmmfs/examples/pinwall/$order
deleted file mode 100644
index b8b054a..0000000
--- a/root/articles/mmmfs/examples/pinwall/$order
+++ /dev/null
@@ -1,3 +0,0 @@
-image
-text
-video
diff --git a/root/articles/mmmfs/examples/pinwall/image/image$png.png b/root/articles/mmmfs/examples/pinwall/image/image$png.png
deleted file mode 100644
index 1628d99..0000000
--- a/root/articles/mmmfs/examples/pinwall/image/image$png.png
+++ /dev/null
diff --git a/root/articles/mmmfs/examples/pinwall/image/pinwall_info: text$json b/root/articles/mmmfs/examples/pinwall/image/pinwall_info: text$json
deleted file mode 100644
index e5893ac..0000000
--- a/root/articles/mmmfs/examples/pinwall/image/pinwall_info: text$json
+++ /dev/null
@@ -1 +0,0 @@
-{"x": 94.0, "y": 265.0, "w": 205.0, "h": 155.0}
\ No newline at end of file
diff --git a/root/articles/mmmfs/examples/pinwall/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/pinwall/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index e611579..0000000
--- a/root/articles/mmmfs/examples/pinwall/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,120 +0,0 @@
-import article, div from require 'mmm.dom'
-import convert from require 'mmm.mmmfs.conversion'
-
-update_info = (fileder, x, y, w, h) ->
-  info = (fileder\get 'pinwall_info: table') or x: 100, y: 100, w: 300, h: 300
-  info.x = x if x
-  info.y = y if y
-  info.w = w if w
-  info.h = h if h
-
-  json = convert 'table', 'text/json', info, fileder, 'pinwall_info'
-  fileder\set 'pinwall_info: text/json', json
-
-CLIENT = MODE == 'CLIENT'
-
-=>
-
-  pending = {}
-  observe = if CLIENT
-    map = {}
-    observer = js.new js.global.ResizeObserver, (_, entries) ->
-      for entry in js.of entries
-        if child = map[entry.target]
-          rect = entry.contentRect
-          pending[child] = -> update_info child, nil, nil, rect.width, rect.height
-
-    (node, child) ->
-      map[node] = child
-      observer\observe node
-
-  drag = nil
-  
-  children = for child in *@children
-      info = (child\get 'pinwall_info: table') or x: 100, y: 100, w: 300, h: 300
-      wrapper = div {
-        style:
-          position: 'absolute'
-          padding: '10px'
-          resize: 'both'
-          overflow: 'hidden'
-          background: 'var(--gray-dark)'
-          border: '1px solid var(--gray-bright)'
-
-          left: "#{info.x}px"
-          top: "#{info.y}px"
-          width: "#{info.w}px"
-          height: "#{info.h}px"
-
-        -- handle for moving the child
-        div {
-          style:
-            top: '0'
-            left: '0'
-            right: '0'
-            height: '10px'
-            cursor: 'pointer'
-            position: 'absolute'
-
-          onmousedown: CLIENT and (_, e) ->
-            node = e.target.parentElement
-            drag = {
-              :child
-              :node
-
-              startX: tonumber node.style.left\match '(%d+)px'
-              startY: tonumber node.style.top\match '(%d+)px'
-              startMouseX: e.clientX
-              startMouseY: e.clientY
-            }
-        }
-
-        -- child content
-        div {
-          style:
-            width: '100%'
-            height: '100%'
-            background: 'var(--white)'
-
-          (child\gett 'mmm/dom')
-        }
-      }
-
-      -- listen for resize events
-      observe wrapper, child if CLIENT
-      wrapper
-
-  children.style = {
-    width: '1000px'
-    height: '500px'
-  }
-
-  if CLIENT
-    children.onmousemove = (_, e) ->
-      return unless drag
-
-      x = drag.startX + (e.clientX - drag.startMouseX)
-      y = drag.startY + (e.clientY - drag.startMouseY)
-      drag.node.style.left = "#{x}px"
-      drag.node.style.top = "#{y}px"
-
-    children.onmouseup = (_, e) ->
-      for k, func in pairs pending
-        func!
-      pending = {}
-
-      return unless drag
-
-      x = drag.startX + (e.clientX - drag.startMouseX)
-      y = drag.startY + (e.clientY - drag.startMouseY)
-      update_info drag.child, x, y
-      drag = nil
-
-    children.onmouseleave = (_, e) ->
-      return unless drag
-
-      drag.node.style.left = "#{drag.startX}px"
-      drag.node.style.top = "#{drag.startY}px"
-      drag = nil
-
-  article children
diff --git a/root/articles/mmmfs/examples/pinwall/text/pinwall_info: text$json b/root/articles/mmmfs/examples/pinwall/text/pinwall_info: text$json
deleted file mode 100644
index 39bdb45..0000000
--- a/root/articles/mmmfs/examples/pinwall/text/pinwall_info: text$json
+++ /dev/null
@@ -1 +0,0 @@
-{"x": 53.0, "y": 64.0, "w": 396.0, "h": 74.0}
\ No newline at end of file
diff --git a/root/articles/mmmfs/examples/pinwall/text/text$plain.txt b/root/articles/mmmfs/examples/pinwall/text/text$plain.txt
deleted file mode 100644
index 8838e5a..0000000
--- a/root/articles/mmmfs/examples/pinwall/text/text$plain.txt
+++ /dev/null
@@ -1,4 +0,0 @@
-This is a pinwall example.
-Every box is a separate fileder.
-The boxes can be rearranged and resized freely.
-If the server is in read-write mode, the changes are saved persistently in real time.
diff --git a/root/articles/mmmfs/examples/pinwall/title: text$plain b/root/articles/mmmfs/examples/pinwall/title: text$plain
deleted file mode 100644
index c629992..0000000
--- a/root/articles/mmmfs/examples/pinwall/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-a pinwall
diff --git a/root/articles/mmmfs/examples/pinwall/video/URL -> video$mp4 b/root/articles/mmmfs/examples/pinwall/video/URL -> video$mp4
deleted file mode 100644
index 6364771..0000000
--- a/root/articles/mmmfs/examples/pinwall/video/URL -> video$mp4
+++ /dev/null
@@ -1 +0,0 @@
-https://file-examples.com/wp-content/uploads/2017/04/file_example_MP4_480_1_5MG.mp4
diff --git a/root/articles/mmmfs/examples/pinwall/video/pinwall_info: text$json b/root/articles/mmmfs/examples/pinwall/video/pinwall_info: text$json
deleted file mode 100644
index 7be8702..0000000
--- a/root/articles/mmmfs/examples/pinwall/video/pinwall_info: text$json
+++ /dev/null
@@ -1 +0,0 @@
-{"x": 534.0, "y": 136.0, "w": 387.0, "h": 218.0}
\ No newline at end of file
diff --git a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 2988f29..0000000
--- a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,44 +0,0 @@
--- main content
--- doesn't have a name prefix (e.g. preview: fn -> mmm/dom)
--- uses the 'fn ->' conversion to execute the lua function on @get
--- resolves to a value of type mmm/dom
-=>
-  html = require 'mmm.dom'
-  import h4, div, a, span, ul, li from html
-  import link_to from (require 'mmm.mmmfs.util') html
-
-  -- render a preview block
-  preview = (child) ->
-    -- get 'title' as 'text/plain' (error if no value or conversion possible)
-    title = child\gett 'title', 'text/plain'
-
-    -- get 'preview' as a DOM description (nil if no value or conversion possible)
-    -- content = child\get 'preview', 'mmm/dom'
-
-    -- div {
-    --   h4 title, style: { margin: 0, cursor: 'pointer' }, onclick: -> BROWSER\navigate child.path
-    --   content or span '(no renderable content)', style: { color: 'red' },
-    --   style: {
-    --     display: 'inline-block',
-    --     width: '300px',
-    --     height: '200px',
-    --     padding: '4px',
-    --     margin: '8px',
-    --     border: '4px solid #eeeeee',
-    --     overflow: 'hidden',
-    --   },
-    -- }
-
-    li link_to child
-
-  examples = ul for child in *@children
-    preview child
-
-  div {
-    style:
-      'break-after': 'page'
-
-    (@gett 'intro: mmm/dom')
-    examples
-    (@gett 'implementation: mmm/dom')
-  }
diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
deleted file mode 100644
index e5f3c7e..0000000
--- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# 4&emsp;evaluation framework
-
-In this section, I will collect approaches and reviews of different end-user software systems from current literature,
-as well as derive and present my own requirements and guiding principles for the development of a new system.
-
-Firstly, I will take a look at a framework for evaluating end-user computing systems from literature, before presenting
-three concrete design principles and components for a new system.
-
-4.1&emsp;qualities of successful end-user computing
----------------------------------------------------
-
-*Ink and Switch* suggest three qualities for tools striving to support <span style="display: inline-block;">
-end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>:</span>
-
-- *Embodiment*, i.e. reifying central concepts of the programming model as more concrete, tangible objects
-  in the digital space (for example, through visual representation),
-  in order to reduce cognitive load on the user.
-- *Living System*, by which they seem to describe the malleability of a system or environment,
-  and in particular the ability to make changes at different levels of depth in the system with
-  very short feedback loops and a feeling of direct experience.
-- *In-place toolchain*, denoting the availability of tools to customize and author the experience,
-  as well as a certain accessibility of these tools, granted by a conceptual affinity between the
-  use of the tools and general 'passive' use of containing system at large. 
-
-These serve as guiding principles for the design and evaluation of computer systems for end-users but are by nature
-very abstract. The following properties are therefore derived as more concrete proposals based on more specific
-constraints: namely the construction of a system for end-users to keep, structure and display personal information and
-thoughts.
-
-<div style="break-after: page;"></div>
-
-4.2&emsp;modularity
--------------------
-
-The *UNIX Philosophy*<mmm-embed path="../references/unix" wrap="sidenote"></mmm-embed> describes the software design
-paradigm pioneered in the creation of the Unix operating system at the AT&T Bell Labs research center in the 1960s. The
-concepts are considered quite influential and are still notably applied in the Linux community. Many attempts at
-summaries exist, but the following includes the pieces that are especially relevant even today:
-
-<mmm-embed path="../references/unix" wrap="marginnote"></mmm-embed>
-> Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes
-> it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer.
-> Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a
-> system comes more from the relationships among programs than from the programs themselves. Many UNIX programs do quite
-> trivial things in isolation, but, combined with other programs, become general and useful tools.
-
-This approach has multiple benefits with regard to end-user programmability: Assembling the system out of simple,
-modular pieces means that for any given task a user may want to implement, it is very likely that preexisting parts
-of the system can help the user realize a solution. Wherever such a preexisting part exists, it pays off designing it
-in such a way that it is easy to integrate for the user later. Assembling the system as a collection of modular,
-interacting pieces also enables future growth and customization, since pieces may be swapped out with customized or
-alternate software at any time.
-
-Settling on a specific modular design model, and reifying other components of a system in terms of it, also corresponds
-directly to the concept of *Embodiment* described by Ink & Switch.
-
-4.3&emsp;content transclusion
------------------------------
-
-The strengths of modular architectures should similarly extend also into the way the system will be used by users.
-If users are to store their information and customized behavior in such an architecture, then powerful tools need to be
-present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be
-linked to (as envisioned for the *Memex*, see above), but also to be <mmm-embed wrap="marginnote"
-path="../references/transclusion">The term <i>transclusion</i> refers to the concept of including content from a
-separate document, possibly stored remotely, by reference rather than by duplication. See also
-</mmm-embed>*transcluded*,
-to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include
-content in a variety other formats (such as images and text) from anywhere else in the system. Behaviors also should be
-able to be transcluded and reused to facilitate the creation of ad-hoc systems and applets based on user needs. For
-example, a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
-
-By forming the immediately user-visible layer of the system out of the same abstractions that the deeper levels of the
-system are made of, the sense of a *Living System* is also improved: skills that are learned at one (lower) level of the
-system carry on into further interaction with the system on deeper levels, as does progress in understanding the
-system's mechanisms.
-
-While there are drawbacks to cloud-storage of data (as outlined above), the utility of distributed systems is
-acknowledged, and the system should therefore be able to include content and behaviors via the network.
-This ability should be integrated deeply into the system, so that data can be treated independently of its origin and
-storage conditions, with as little caveats as possible. In particular, the interactions of remote data access and
-content transclusion should be paid attention to and taken into consideration for a system's design.
-
-4.4&emsp;end-user programming
------------------------------
-
-In order to provide users full access to their information as well as the computational infrastructure,
-users need to be able to finely customize and reorganize the smallest pieces to suit their own purposes,
-in other words: be able to program.
-
-While there is an ongoing area of research focusing on the development of new programming paradigms, 
-methodologies, and tools that are more accessible and cater to the wide
-range of end-users<mmm-embed path="../references/subtext" wrap="sidenote"></mmm-embed>,
-in order to keep the scope of this work appropriate,
-conventional programming languages are used for the time being.
-Confidence is placed in the fact that eventually more user-friendly languages will be available and,
-given the goal of modularity, should be implementable in a straightforward fashion.
diff --git a/root/articles/mmmfs/historical-approaches/$order b/root/articles/mmmfs/historical-approaches/$order
deleted file mode 100644
index b98a91b..0000000
--- a/root/articles/mmmfs/historical-approaches/$order
+++ /dev/null
@@ -1 +0,0 @@
-star-graph
diff --git a/root/articles/mmmfs/historical-approaches/star-graph/image$png.png b/root/articles/mmmfs/historical-approaches/star-graph/image$png.png
deleted file mode 100644
index ed4003c..0000000
--- a/root/articles/mmmfs/historical-approaches/star-graph/image$png.png
+++ /dev/null
diff --git a/root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md b/root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md
deleted file mode 100644
index eb115dd..0000000
--- a/root/articles/mmmfs/historical-approaches/star-graph/note: text$markdown.md
+++ /dev/null
@@ -1,4 +0,0 @@
-<p><i>How systems influenced later systems. This graph summarizes how various systems related to Star have influenced
-one another over the years. Time progresses downwards. Double arrows indicate direct successors (i.e.,
-follow-on versions). [...]</i></p>
-<mmm-embed wrap="raw" path="../../references/xerox-star"></mmm-embed>
diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
deleted file mode 100644
index dfe9390..0000000
--- a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,73 +0,0 @@
-<div style="break-before: page;"></div>
-
-# 3&emsp;historical approaches
-
-Two of the earliest holistic computing systems, the Xerox Alto and Xerox Star, both developed at Xerox PARC and
-introduced in the 70s and early 80s pioneered not only graphical user-interfaces but also the "Desktop Metaphor".
-The desktop metaphor presents information as stored in "Documents" that can be organized in folders and on the
-"Desktop". It invokes a strong analogy to physical tools. One of the differences between the Xerox Star system and
-other systems at the time, as well as the systems we use currently, is that the type of data a file represents is
-directly known to the system.
-
-In a retrospective analysis of the Xerox Star's impact on the computer industry, the desktop metaphor is described as
-follows:
-
-<mmm-embed path="../references/xerox-star" wrap="marginnote"></mmm-embed>
-> In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
-> They do not "invoke a text editor", they "open a document".
-> The system knows the type of each file and notifies the relevant application program when one is opened.
->
-> The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a
-> program other than its "assigned" application. \[...\]
-> Star's designers feel that, for its audience, the advantages of allowing users to forget about programs outweighs
-> this disadvantage.
-
-Other systems at the time lacked any knowledge of the type of files, and while mainstream operating systems of today
-have retro-fit the ability to associate and memorize the preferred applications to use for a given file based on its
-name suffix, the intention of making applications a secondary, technical detail of working with the computer has
-surely been lost.
-
-Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the
-system (the objects being anything from files to characters or paragraphs). These typed pieces of information are
-labeled with a name and persistently stored, providing a mechanism to store metadata such as user preference for
-ordering or the default view mode of a folder for example.
-
-The earliest indirect influence for the Xerox Alto and many other systems of its time was the *Memex*.
-The *Memex* is a hypothetical device and system for knowledge management. Proposed by Vannevar Bush in 1945<mmm-embed
-path="../references/memex" wrap="sidenote"></mmm-embed>, the concept predates much of the technology that later was used
-to implement many parts of the vision.
-
-<mmm-embed path="star-graph" facet="note" wrap="marginnote" style="margin-top: 1rem;"></mmm-embed>
-<mmm-embed path="star-graph" nolink></mmm-embed>
-
-<!--
-While the article extrapolates from existing technology at the time, describing at times
-very concrete machinery based on microfilm and mechanical contraptions, many of the conceptual predictions became
-true or inspired  ....
--->
-
-One of the most innovative elements of Bush's predictions is the idea of technologically cross-referenced and
-connected information, which would later be known and created as *hypertext*. While hypertext powers the majority of
-today's internet, many of the advantages that Bush imagined have not carried over into the personal use of computers.
-There are very few tools for creating personal, highly-interconnected knowledge bases, even though it is technologically
-feasible and a proven concept (exemplified for example by the massively successful online encyclopedia
-*Wikipedia*<mmm-embed path="../references/wikipedia" wrap="sidenote"></mmm-embed>).
-
-While there are few such tools available today, one of the systems that could be said to have come closest to a
-practical implementation of a Memex-inspired system for personal use might be Apple's *HyperCard*.
-
-In a live demonstration<mmm-embed path="../references/hypercard" wrap="sidenote"></mmm-embed>, the creators of the
-software showcase a system of stacks of cards that together implement, amongst others, a calendar (with yearly and
-weekly views), a list of digital business cards for storing phone numbers and addresses, and a todo list. However these
-stacks of cards are not just usable by themselves, it is also demonstrated how stacks can link to each other in
-meaningful ways, such as jumping to the card corresponding to a specific day from the yearly calendar view or
-automatically looking up the card corresponding to a person's first name from a mention of the name in the text on a
-different card.
-
-Alongside Spreadsheets, *HyperCard* remains one of the most successful implementations of end-user programming, even
-today. While its technical abilities have been long matched and surpassed by other software (such as the ubiquitous
-*Hypertext Markup Language* HTML, and the associated programming language *JavaScript*), these technical successors have
-failed the legacy of *HyperCard* as an end-user tool: While it is easier than ever to publish content on the web
-(through various social media and microblogging services), the benefits of hypermedia as a customizable medium for
-personal management have nearly vanished. End-users do not create hypertext anymore.
-
diff --git a/root/articles/mmmfs/introduction/text$markdown.md b/root/articles/mmmfs/introduction/text$markdown.md
deleted file mode 100644
index b8550fe..0000000
--- a/root/articles/mmmfs/introduction/text$markdown.md
+++ /dev/null
@@ -1,18 +0,0 @@
-1&emsp;introduction
-====================
-
-As of December 2019, there are only four major operating systems available to end-users for desktop and mobile
-devices<mmm-embed path="../references/market-share" wrap="sidenote"></mmm-embed>. All of these systems are comparatively inflexible and
-can only be customized by users where the system or application developers have anticipated a need with corresponding
-options. Only a small minority of professional or hobby developers have the knowledge and tools at their disposal to
-create their own digital experiences, and even for them, the process is often too complex and inefficient to do so
-effectively.  
-However, historically, empowered ownership of the computing experience was not meant to be restricted only to
-end-users. Many computing systems designed during the computer revolution were designed specifically with the goal of
-complete customizability by users, but little of this approach remains in the systems we use today.
-
-In the first section of this thesis, I will discuss some of the limitations of mainstream operating systems and
-potential causes in detail. Next, I will highlight some of the contrasting approaches found in historic computing
-systems, and then derive a framework for the evaluation of end-user computing systems with regard to user empowerment.
-I will then discuss a new computing system, demonstrate it in some example use cases, and evaluate it using the
-framework.
diff --git a/root/articles/mmmfs/mmmfs/$order b/root/articles/mmmfs/mmmfs/$order
deleted file mode 100644
index 5a5d5ab..0000000
--- a/root/articles/mmmfs/mmmfs/$order
+++ /dev/null
@@ -1,3 +0,0 @@
-type_coercion_graph
-tree_mmmfs
-tree_mainstream
diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
deleted file mode 100644
index f04e671..0000000
--- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,197 +0,0 @@
-# 5&emsp;system description
-
-Alongside this thesis, a new end-user computing system has been developed together with the framework presented above.
-The system, `mmmfs`, is a personal data storage and processing system that was initially developed as a tool for
-generating static websites but has now been extended with capabilities for live interaction and introspection, as well
-as embedded editing, as part of this work.
-
-mmmfs has been designed with a focus on data ownership for users. One of the main driving ideas is to unlock data
-from external data silos and file formats by making data available uniformly across different storage systems and
-formats. Secondly, computation and interactive elements are also integrated into this paradigm, so that mmmfs can be
-seamlessly extended and molded to the user's needs.
-
-The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and
-the *Fileder Unified Data Model* for unified data storage and access. In the next sections, the design and
-implementation of these two components will be described in detail.
-
-## 5.1&emsp;data storage model
-The Fileder Model is the underlying unified data storage model.
-Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
-
-<mmm-embed path="tree_mainstream">schematic view of an example tree in a mainstream filesystem</mmm-embed>
-
-In common filesystems, as pictured, data can be organized hierarchically into *folders* (or *directories*),
-which serve only as containers of *files*, in which data is actually stored. While *directories* are fully transparent
-to both system and user (they can be created, browsed, listed and viewed by both), *files* are, from the system
-perspective, mostly opaque and inert blocks of data.
-
-Some metadata, such as file size and access permissions, is associated with each file,
-but notably, the type of data is generally not actually stored in the filesystem,
-but determined loosely based on multiple heuristics depending on the system and context.
-Some notable mechanisms are:
-
-- Suffixes at the end of the filename are often used to indicate which kind of data a file contains. However there is no
-  centralized standardization of suffixes, and often one suffix is used for multiple incompatible versions of a
-  file-formats, or multiple suffixes are used interchangeably for one format.
-- Many file-formats specify a specific data-pattern either at the very beginning or very end of a given file.
-  On UNIX systems the `libmagic` database and library of these so-called *magic constants* is commonly used to guess
-  the file-type based on these fragments of data.
-- on UNIX systems, files to be executed are checked by a variety of methods<mmm-embed path="../references/linux-exec"
-  wrap="sidenote"></mmm-embed> in order to determine which format would fit. For example, script files, the "shebang"
-  symbol, `#!`, can be used to specify the program that should parse this file in the first line of the file.
- 
-It should be clear already from this short list that to mainstream operating systems, as well as the applications
-running on them, the format of a file is almost completely unknown and, at best, educated guesses can be made.
-
-Because these various mechanisms are applied at different times by the operating system and applications, it is possible
-for files to be labeled or considered as being in different formats at the same time by different components of the
-system.
-
-This leads to confusion about the factual format of data among users<mmm-embed path="../references/renaming"
-wrap="sidenote" style="margin-top: -3rem;">For example, the difference between changing a file extension and converting
-a file between two formats is often unclear to users, as evident from questions like this:  </mmm-embed>, but can
-also pose a serious security risk:
-Under some circumstances, it is possible that a file contains maliciously-crafted code and is treated as an executable
-by one software component, while a security mechanism meant to detect such code determines the same file to be a
-legitimate image<mmm-embed path="../references/poc-or-gtfo" wrap="sidenote" style="margin-top: 2rem"></mmm-embed>
-(the file may in fact be valid in both formats).
-
-In mmmfs, the example above might look like this instead:
-<mmm-embed path="tree_mmmfs">schematic view of an example mmmfs tree</mmm-embed>
-
-Superficially, this may look quite similar: there are still only two types of nodes (referred to as *fileders* and
-*facets*), and again one of them, the *fileders* are used only to hierarchically organize *facets*. Unlike *files*,
-*facets* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that
-is explicitly designed to be understood and used by the system.
-
-Despite the similarities, the semantics of this system are very different: In mainstream filesystems, each *file* stands
-for itself only; i.e. in a *directory*, no relationship between *files* is assumed by default, and files are most of the
-time read or used outside of the context they exist in in the filesystem.
-
-In mmmfs, a *facet* should only ever be considered an aspect of its *fileder*, and never as separate from it.
-A *fileder* can contain multiple *facets*, but they are meant to be alternate or equivalent representations of the
-*fileder* itself. Though for some uses it is required, software generally does not have to be directly aware of the
-*facets* existing within a *fileder*, rather it assumes the presence of content in the representation that it requires,
-and simple requests it. The *Type Coercion Engine* (see below) will then attempt to satisfy this request based on the
-*facets* that are in fact present.
-
-Semantically a *fileder*, like a *directory*, also encompasses all the other *fileders* nested within itself
-(recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural
-way of structuring complex data, both for access by the system and its components, as well as the user themself.
-
-<div style="break-after: page;"></div>
-
-## 5.2&emsp;type system and coercion engine
-As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a
-*fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system
-then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many
-steps such as converting between similar file formats, running executable code stored in a facet, or fetching remote
-content. The component that requested the data is isolated from this process and does not have to deal with any of the
-details.
-
-In the current iteration of the type system, types are simple strings of text and loosely based on MIME-types<mmm-embed
-path="../references/mime-types" wrap="sidenote"></mmm-embed>.
-MIME types consist of a major- and minor category, and optionally a 'suffix'.
-Here are some common MIME-types that are also used in mmmfs:
-
-- `text/html` and `text/html+frag` (mmmfs only)
-- `text/javascript`
-- `image/png`
-- `image/jpeg`
-
-While these types allow some amount of specificity, they fall short of describing their content especially in cases
-where formats overlap: Source code, for example, is often distributed in `.tar.gz` archive files (directory-trees that
-are first bundled into an `application/x-tar` archive, and then compressed into an `application/gzip` archive). Using
-either of these two types is respectively incorrect or insufficient information to properly treat and extract the
-contained data.
-
-To mitigate this problem, mmmfs *types* can be nested. This is denoted in mmmfs *type* strings using the `->` symbol,
-e.g. the mmmfs *types* `application/gzip -> application/tar -> dirtree` and `URL -> image/jpeg` describe a
-tar-gz-compressed directory tree and the URL linking to a JPEG-encoded picture respectively.
-
-Depending on the outer type this nesting can mean different things:
-for URLs, the nested type is expected to be found after fetching the URL with HTTP,
-compression formats are expected to contain contents of the nested types,
-and executable formats are expected to output data of the nested type.
-
-It is a lot more important to be able to accurately describe the type of a *facet* in mmmfs than in mainstream operating
-systems because while in the latter types are mostly used only associate an application that will then prompt the user
-for further steps if necessary, mmmfs uses the *type* to automatically find one or more programs to execute, in order to
-convert or transform the data stored in a *facet* into the *type* required in the context where it was requested.
-
-This process of *type coercion* uses a database of known *converts* that can be applied to data. Every *convert*
-consists of a description of the input *types* that it can accept, the output *type* it would produce for a given input
-type, as well as the code for actually converting a given piece of data. Simple *converts* may simply consist of a fixed
-in and output type, such as this *convert* for rendering Markdown-encoded text to an HTML hypertext fragment:
-
-    {
-      inp: 'text/markdown'
-      out: 'text/html+frag'
-      transform: (value, ...) ->
-        -- implementation stripped for brevity
-    }
-
-Other *converts*, on the other hand, may accept a wide range of input types:
-
-    {
-      inp: 'URL -> image/.*'
-      out: 'text/html+frag'
-      transform: (url) -> img src: url
-    }
-
-This convert uses a Lua Pattern to specify that it can accept an URL to any type of image,
-and convert it to an HTML fragment.
-
-By using the pattern substitution syntax provided by the Lua `string.gsub` function, converts can also make the type
-they return depend on the input type, as is required often when nested types are unpacked:
-
-    {
-      inp: 'application/gzip -> (.*)'
-      out: '%1'
-      transform: (data) ->
-        -- implementation stripped for brevity
-    }
-
-This *convert* accepts an `application/gzip` *type* wrapping any other *type*, and captures that nested type in a
-pattern group. It then uses the substitution syntax to specify that nested type as the output of the conversion.
-For an input *type* of `application/gzip -> image/png` this *convert* would therefore generate the type `image/png`. 
-
-This last example further demonstrates the flexibility of this approach:
-
-    {
-      inp: 'text/moonscript -> (.*)'
-      out: 'text/lua -> %1'
-      transform: (code) -> moonscript.to_lua code
-    }
-
-This *convert* transpiles MoonScript source-code into Lua source-code, while keeping the nested type
-(in this case the result expected when executing either script) the same.
-
-In addition to the attributes shown above, every *convert* is also rated with a *cost* value. The cost value is meant to
-roughly estimate both the cost (in terms of computing power) of the conversion, as well as the accuracy or immediacy of
-the conversion. For example, resizing an image to a lower size should have a high cost, because the process is
-computationally expensive, but also because a smaller image represents the original image to a lesser degree.
-Similarly, a URL to a piece of content is a less immediate representation than the content itself, so the cost of a
-*convert* that simply generates the URL to a piece of data should be high even if the process is very cheap to compute.
-
-Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was
-present as accurately as possible. It is also important to prevent some nonsensical results from occurring, such as
-displaying a link to content instead of the content itself because the link is cheaper to create than completely
-converting the content does.
-
-Type coercion is implemented using a general pathfinding algorithm, based on *Dijkstra's Algorithm*<mmm-embed
-path="../references/dijkstra" wrap="sidenote"></mmm-embed>. First, the set of given *types* is found by selecting all
-*facets* of the *fileder* that match the *name* given in the query. The set of given *types* is marked in green in the
-following example graph.
-From there the algorithm recursively checks whether it can reach other *types* by applying all matching *converts* to
-the *type* that is the cheapest to reach currently, excluding any *types* that have already been exhaustively-searched
-in this way. All *types* found that have not yet been inserted into the set of given *types* are then added to the
-set, so that they may be searched as well.
-
-The algorithm doesn't stop immediately after reaching a *type* from the result set, it continues to search until it
-either completely exhausts the result-space, or until all non-exhaustively searched paths already have costs higher than
-the allowed maximum. This ensures that the optimal path is found, even if a more expensive path is found more quickly
-initially.
-
-<mmm-embed path="type_coercion_graph">excerpt of the graph of conversion paths from two starting facets to mmm/dom
-</mmm-embed>
diff --git a/root/articles/mmmfs/mmmfs/tree_mainstream/text$mermaid-graph b/root/articles/mmmfs/mmmfs/tree_mainstream/text$mermaid-graph
deleted file mode 100644
index 3227e47..0000000
--- a/root/articles/mmmfs/mmmfs/tree_mainstream/text$mermaid-graph
+++ /dev/null
@@ -1,11 +0,0 @@
-graph TD
-  Documents --> Movies --> m1{{A Movie.mp4}}
-  Documents --> Pictures --> vacation[Summer Vacation]
-  vacation --> v1{{1.jpg}}
-  vacation --> v2{{2.jpg}}
-  Pictures --> Projects
-  Projects --> p1{{1.jpg}}
-  Projects --> p2{{2.jpg}}
-
-  classDef file fill:#f9f;
-  class m1,v1,v2,p1,p2 file;
diff --git a/root/articles/mmmfs/mmmfs/tree_mmmfs/text$mermaid-graph b/root/articles/mmmfs/mmmfs/tree_mmmfs/text$mermaid-graph
deleted file mode 100644
index 7b4f6f4..0000000
--- a/root/articles/mmmfs/mmmfs/tree_mmmfs/text$mermaid-graph
+++ /dev/null
@@ -1,21 +0,0 @@
-graph TD
-  Documents --> Movies --> m1[A Movie.mp4]
-  m1 --> m1.f{{video/mp4}}
-
-  Documents --> Pictures --> vacation[Summer Vacation]
-  vacation --> slideshow{{slideshow: script -> UI}}
-  vacation --> gallery{{gallery: script -> UI}}
-  vacation --> v1[1.jpg]
-  vacation --> v2[2.jpg]
-  v1 --> v1.f{{image/jpeg}}
-  v2 --> v2.f{{image/jpeg}}
-
-  Pictures --> Projects
-  Projects --> p1[1.jpg]
-  Projects --> p2[2.jpg]
-  p1 --> p1.f{{image/jpeg}}
-  p2 --> p2.f{{image/jpeg}}
-
-  classDef default fill:#f00,stroke:#333,stroke-width:4px;
-  classDef file fill:#f9f;
-  class slideshow,gallery,m1.f,v1.f,v2.f,p1.f,p2.f file;
diff --git a/root/articles/mmmfs/mmmfs/type_coercion_graph/text$mermaid-graph b/root/articles/mmmfs/mmmfs/type_coercion_graph/text$mermaid-graph
deleted file mode 100644
index cf2cf1e..0000000
--- a/root/articles/mmmfs/mmmfs/type_coercion_graph/text$mermaid-graph
+++ /dev/null
@@ -1,22 +0,0 @@
-graph LR
-  md_lua[text/lua -> text/markdown]
-  md[text/markdown]
-  moon[text/moonscript -> fn -> mmm/dom]
-  lua[text/lua -> fn -> mmm/dom]
-  fn[fn -> mmm/dom]
-  dom[mmm/dom]
-  moon_url[URL -> text/moonscript -> fn -> mmm/dom]
-  lua_url[URL -> text/lua -> fn -> mmm/dom]
-
-  md_lua -- cost: 1 --> md -- cost: 2 --> dom
-  moon -- cost: 5 --> moon_url
-  moon -- cost: 1 --> fn -- cost: 2 --> dom
-  moon -- cost: 2 --> lua -- cost: 5 --> lua_url
-  lua -- cost: 1 --> fn
-  moon_url -- cost: 10 --> dom
-  lua_url -- cost: 10 -->dom
-
-  classDef given fill:#ada;
-  classDef path stroke:#ada;
-  linkStyle 3,1,0,4 stroke:#8d8,stroke-width:2px
-  class md_lua,moon given
diff --git a/root/articles/mmmfs/motivation/$order b/root/articles/mmmfs/motivation/$order
deleted file mode 100644
index accfc0b..0000000
--- a/root/articles/mmmfs/motivation/$order
+++ /dev/null
@@ -1,2 +0,0 @@
-app-types
-creative
diff --git a/root/articles/mmmfs/motivation/app-types/text$markdown.md b/root/articles/mmmfs/motivation/app-types/text$markdown.md
deleted file mode 100644
index aedef1c..0000000
--- a/root/articles/mmmfs/motivation/app-types/text$markdown.md
+++ /dev/null
@@ -1,3 +0,0 @@
-While there can be a distinction between *Native Applications* and *Web Applications* or *Cloud Services*, the following
-arguments apply to all different technical implementations of this same concept. The problems associated specifically
-with Web- and Cloud-based application models will be discussed separately below.
diff --git a/root/articles/mmmfs/motivation/creative/text$markdown.md b/root/articles/mmmfs/motivation/creative/text$markdown.md
deleted file mode 100644
index 9dd6162..0000000
--- a/root/articles/mmmfs/motivation/creative/text$markdown.md
+++ /dev/null
@@ -1,2 +0,0 @@
-Note that 'creative' here does not only mean 'artistic': this applies to any field, and limits the ability of domain
-experts to push the boundaries of practice by using technology in innovative ways.
diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
deleted file mode 100644
index 64a3459..0000000
--- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
+++ /dev/null
@@ -1,138 +0,0 @@
-# 2&emsp;drawbacks of current systems
-
-The project that this thesis accompanies was created out of frustration with the computing systems that are currently
-popular and widely available to end-users. The following sections document and exemplify the perceived shortcomings that
-these systems exhibit, as attributed to specific concepts or paradigms that the systems seem to be designed around. 
-
-2.1&emsp;application-centric design
------------------------------------
-
-The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs,
-using the mainstream operating systems Apple iOS and Mac&nbsp;OS&nbsp;X, Microsoft&nbsp;Windows or Android.
-
-<mmm-embed path="app-types" wrap="marginnote"></mmm-embed>
-All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their
-interaction model. The functionality and capabilities of digital devices are bundled, marketed, sold and distributed
-as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple
-problems.
-
-For one, since applications are produced by private companies on the software market,
-developers compete on features integrated into their applications. To stay relevant, monolithic software or software
-suites tend to accrete features rather then modularize and delegate to other software<mmm-embed wrap="sidenote"
-path="../references/appliances"></mmm-embed>. This makes many software packages more complex and unintuitive than
-they need to be, and also cripples interoperability between applications and data formats.
-
-Because (private) software developers are incentivized to keep customers, they make use of network effects to keep
-customers locked-in. This often means re-implementing services and functionality that is already available to users,
-and integrating it directly in other applications or as a new product by the same organization.
-While this strategy helps big software companies retain customers, it harms users, who have to navigate a complex
-landscape of multiple incompatible, overlapping, and competing software ecosystems.
-Data of the same kind, a rich-text document, for example, can be shared easily within the software systems of a certain
-manufacturer and with other users of the same, but sharing with users of a competing system, even if it has almost the
-same capabilities, can often be problematic<mmm-embed path="../references/lock-in" wrap="sidenote"></mmm-embed>.
-
-Another issue is that due to the technical challenges of development in this paradigm, applications are designed and
-developed by experts in application development, rather than experts in the domain of the tool. While developers may
-solicit feedback, advice, and ideas from domain experts, communication is a barrier. Additionally, domain experts are
-generally unfamiliar with the technical possibilities, and may therefore not be able to express feedback that would lead
-to more significant advances.
-<mmm-embed path="creative" wrap="marginnote"></mmm-embed>
-As a result, creative use of computer technology is limited to programmers, since applications constrain their users to
-the paths and abilities that the developers anticipated and deemed useful.
-
-The application-centric computing metaphor treats applications as black boxes and provides no means to understand,
-customize or modify the behavior of apps, intentionally obscuring the inner-workings of applications and
-completely cutting users off from this type of ownership over their technology. While the trend seems to be to further
-hide the way desktop operating systems work<mmm-embed path="../references/osx-files" wrap="sidenote"></mmm-embed>,
-mobile systems like Apple's *iOS* were designed as such *walled gardens* from the start.
-
-2.2&emsp;cloud computing
-------------------------
-
-*Web Apps* often offer similar functionality to other applications but are subject to additional limitations:
-In most cases, they are only accessible or functional in the presence of a stable internet connection,
-and they have very limited access to the resources of the physical computer they are running on.
-For example, they usually cannot interact directly with the file system, hardware peripherals or other applications,
-other than through a standardized set of interactions (e.g. selecting a file via a visual menu, capturing audio and
-video from a webcam, opening another website).
-
-Cloud software, as well as subscription-model software with online-verification mechanisms, are additionally subject
-to license changes, updates modifying, restricting or simply removing past functionality, etc. Additionally, many cloud
-software solutions and ecosystems store the users' data in the cloud, often across national borders, where legal and
-privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwilling to
-continue servicing a customer, the user's data may be irrecoverably lost (or access prevented). This can have serious
-consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for
-whom an inability to access their tools or their cloud-stored data can pose an existential threat.
-
-2.3&emsp;inert data (and data formats)
---------------------------------------
-
-Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data
-created and left behind by apps and applications in the computing model that is currently prevalent: Most data today
-is either intrinsically linked to one specific application, that controls and limits access to the actual information,
-or, even worse, stored in the cloud where users have no direct access at all. In the latter case, users depend solely on
-online tools that require a stable network connection and a modern browser and could be modified, removed, or otherwise
-negatively impacted at any moment.
-
-Aside from being inaccessible to users, the resulting complex proprietary formats are also opaque and useless to other
-applications and the operating system, which often is a huge missed opportunity: 
-The .docx format, for example, commonly used for storing mostly textual data enriched with images and on occasion videos,
-is in fact a type of archive that can contain many virtual files internally, such as the various media files contained
-within. However this is completely unknown to the user and operating system, and so users are unable to access the
-contents in this way. As a result, editing an image contained in a word document is far from a trivial task: first the
-document has to be opened in a word processing application, then the image has to be exported from it and saved in its
-own, temporary file. This file can then be edited and saved back to disk. Once updated, the image may be reimported
-into the .docx document. If the word-processing application supports this, the old image may be replaced directly,
-otherwise, the user may have to remove the old image, insert the new one, and carefully ensure that the positioning in
-the document remains intact.
-
-2.4&emsp;disjointed filesystems
--------------------------------
-
-The filesystems and file models used on modern computing devices generally operate on the assumption that every
-individual file stands for itself. Grouping of files in folders is allowed as a convenience for users, but most
-applications only ever concern themselves with a single file at a time, independent of the context the file is stored
-in.
-
-Data rarely really fits this concept of individual files very well, and even when it does, it is rarely exposed to
-the user that way: The 'Contacts' app on a mobile phone, for example, does not store each contact's information in a
-separate 'file' (as the word may suggest initially), but rather keeps all information in a single database file,
-which is hidden away from the user. Consequently, access to the information contained in the database is only enabled
-through the contacts application's graphical interface, and not through other applications that generically operate on
-files.
-
-Another example illustrates how a more powerful file (organization) system could render such formats and applications
-obsolete: Given the simple task of collecting and arranging a mixed collection of images, videos, and texts to
-brainstorm, many might be tempted to open an application like *Microsoft Word* or *Adobe Photoshop* and create a new
-document there. Both *Photoshop* files and *Word* documents are capable of containing texts and images, but when such
-content is copied into them from external sources, such as other files on the same computer, or quotes and links from
-the internet, these relationships are irrevocably lost. As illustrated above, additionally, it becomes a lot harder to
-edit the content once it is aggregated. To choose an application for this task is a hard trade-off to make, because in
-applications primarily designed for word processing, arranging content visually is hard to do, and image editing and
-video embedding options are limited, while tools better suited to these tasks lack nuance when working with text.
-
-To avoid facing this dilemma, a more sensible system could leave the task of positioning and aggregating content of
-different types to one software component, while multiple different software components could be responsible for editing
-the individual pieces of content so that the most appropriate one can be chosen for each element. While creating the
-technological interface between these components is certainly a challenge, the resulting system would greatly benefit
-from the exponentially-growing capabilities resulting from the modular reuse of components across many contexts: A rich
-text editor component could be used for example not just in a mixed media collection as proposed above, but also for
-an email editor or the input fields in a browser.
-
-<div style="height: 2rem;"></div>
-
-To summarize, for various reasons, the metaphors and driving concepts of computing interfaces today prevent users from
-deeply understanding the software they use and the data they own, from customizing and improving their experience and
-interactions, and from properly owning, contextualizing and connecting their data.
-
-Interestingly, these deficits do not appear throughout the history of today's computing systems but are based in rather
-recent developments in the field. In fact, the most influential systems in the past aspired to the polar opposites, as I
-will show in the next section.
-
-<!--
-Chiusano blames these issues on the metaphor of the *machine*, and likens apps and applications to appliances.
-According to him, what should really be provided are *tools*:
-composable pieces of software that naturally lend themselves to, or outrightly call for,
-integration into the users' other systems and customization,
-rather than lure into the walled-gardens of corporate ecosystems using network-effects.
--->
diff --git a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 615075a..0000000
--- a/root/articles/mmmfs/print: text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,26 +0,0 @@
--- main content
--- doesn't have a name prefix (e.g. preview: fn -> mmm/dom)
--- uses the 'fn ->' conversion to execute the lua function on @get
--- resolves to a value of type mmm/dom
-=>
-  html = require 'mmm.dom'
-  import article, h1, p, div from html
-  import moon from (require 'mmm.highlighting').languages
-
-  article with _this = class: 'sidenote-container spacious', style: { 'max-width': '640px', 'line-height': '1.5' }
-    append = (a) -> table.insert _this, a
-
-    append div {
-      h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 }
-      p {
-        style:
-          'margin-top': 0
-          'padding-bottom': '0.2em'
-          'border-bottom': '1px solid black'
-
-        "A Historical Investigation and Development of a File-System-Based Environment"
-      }
-    }
-
-    for child in *@children
-      append (child\get 'print: mmm/dom') or (child\gett 'mmm/dom')
diff --git a/root/articles/mmmfs/references/$order b/root/articles/mmmfs/references/$order
deleted file mode 100644
index d2a668b..0000000
--- a/root/articles/mmmfs/references/$order
+++ /dev/null
@@ -1,22 +0,0 @@
-poc-or-gtfo
-aspect-ratios
-memex
-appliances
-super-powers
-dijkstra
-subtext
-mime-types
-alternatives-to-trees
-xerox-star
-unix
-transclusion
-adobe
-acm-dl
-hypercard
-inkandswitch
-linux-exec
-wikipedia
-market-share
-osx-files
-renaming
-lock-in
diff --git a/root/articles/mmmfs/references/acm-dl/text$bibtex b/root/articles/mmmfs/references/acm-dl/text$bibtex
deleted file mode 100644
index 8fb36a2..0000000
--- a/root/articles/mmmfs/references/acm-dl/text$bibtex
+++ /dev/null
@@ -1,5 +0,0 @@
-@online{acm-dl,
-  title = {ACM Digital Library},
-  url = {https://dl.acm.org},
-  year = {n. d.},
-}
diff --git a/root/articles/mmmfs/references/adobe/text$bibtex b/root/articles/mmmfs/references/adobe/text$bibtex
deleted file mode 100644
index 55904aa..0000000
--- a/root/articles/mmmfs/references/adobe/text$bibtex
+++ /dev/null
@@ -1,8 +0,0 @@
-@online{adobe,
-  title = {Adobe is cutting off users in Venezuela due to US sanctions},
-  url = {https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions},
-  publisher = {The Verge},
-  author = {Lee, Dami},
-  year = {2019, October 7},
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/alternatives-to-trees/text$bibtex b/root/articles/mmmfs/references/alternatives-to-trees/text$bibtex
deleted file mode 100644
index 19c134e..0000000
--- a/root/articles/mmmfs/references/alternatives-to-trees/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@web{alternatives:to:trees,
-  title = {Alternatives to Trees},
-  url = {https://www.oocities.org/tablizer/sets1.htm},
-  author = {Jacobs, B.}
-  year = {2004},
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/appliances/text$bibtex b/root/articles/mmmfs/references/appliances/text$bibtex
deleted file mode 100644
index 56fa8c8..0000000
--- a/root/articles/mmmfs/references/appliances/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{appliances,
-  title = {The future of software, the end of apps, and why UX designers should care about type theory},
-  url = {http://pchiusano.github.io/2013-05-22/future-of-software.html},
-  author = {Chiusano, Paul},
-  year = {2013},
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/aspect-ratios/text$bibtex b/root/articles/mmmfs/references/aspect-ratios/text$bibtex
deleted file mode 100644
index 37cea92..0000000
--- a/root/articles/mmmfs/references/aspect-ratios/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@web{aspect:ratios,
-  title = {Aspect-ratio independent UIs},
-  url = {https://s-ol.nu/aspect-ratios},
-  author = {Bekic, Sol}
-  year = {2019},
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/dijkstra/text$bibtex b/root/articles/mmmfs/references/dijkstra/text$bibtex
deleted file mode 100644
index c38a470..0000000
--- a/root/articles/mmmfs/references/dijkstra/text$bibtex
+++ /dev/null
@@ -1,17 +0,0 @@
-@article{10.1007/BF01386390,
-  author = {Dijkstra, Edsger W.},
-  title = {A Note on Two Problems in Connexion with Graphs},
-  year = {1959},
-  issue_date = {December 1959},
-  publisher = {Springer-Verlag},
-  address = {Berlin, Heidelberg},
-  volume = {1},
-  number = {1},
-  issn = {0029-599X},
-  url = {https://doi.org/10.1007/BF01386390},
-  doi = {10.1007/BF01386390},
-  journal = {Numer. Math.},
-  month = dec,
-  pages = {269–271},
-  numpages = {3}
-}
diff --git a/root/articles/mmmfs/references/hypercard/text$bibtex b/root/articles/mmmfs/references/hypercard/text$bibtex
deleted file mode 100644
index b23cfcb..0000000
--- a/root/articles/mmmfs/references/hypercard/text$bibtex
+++ /dev/null
@@ -1,6 +0,0 @@
-@online{hypercard,
-  title = {Computer Chronicles, Episode 501},
-  url = {https://archive.org/details/CC501_hypercard},
-  visited = {2019-12-18},
-  year = {1987},
-}
diff --git a/root/articles/mmmfs/references/inkandswitch/markdown: text$moonscript -> fn -> text$markdown.md b/root/articles/mmmfs/references/inkandswitch/markdown: text$moonscript -> fn -> text$markdown.md
deleted file mode 100644
index 9439841..0000000
--- a/root/articles/mmmfs/references/inkandswitch/markdown: text$moonscript -> fn -> text$markdown.md
+++ /dev/null
@@ -1 +0,0 @@
-=> "```\n" .. (@gett 'text/bibtex') .. "\n```"
diff --git a/root/articles/mmmfs/references/inkandswitch/text$bibtex b/root/articles/mmmfs/references/inkandswitch/text$bibtex
deleted file mode 100644
index 8b5f298..0000000
--- a/root/articles/mmmfs/references/inkandswitch/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{inkandswitch,
-  title = {End-user Programming},
-  url = {https://inkandswitch.com/end-user-programming.html},
-  publisher = {Ink & Switch},
-  year = {2019},
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/linux-exec/text$bibtex b/root/articles/mmmfs/references/linux-exec/text$bibtex
deleted file mode 100644
index e0e415f..0000000
--- a/root/articles/mmmfs/references/linux-exec/text$bibtex
+++ /dev/null
@@ -1,8 +0,0 @@
-@online{linux:exec,
-  title = {How does Linux execute a file?},
-  url = {https://stackoverflow.com/a/23295724/1598293},
-  publisher = {stackoverflow.com},
-  note = {answered by osgx},
-  visited = {2019-12-18},
-  year = 2014,
-}
diff --git a/root/articles/mmmfs/references/lock-in/text$bibtex b/root/articles/mmmfs/references/lock-in/text$bibtex
deleted file mode 100644
index 28d780c..0000000
--- a/root/articles/mmmfs/references/lock-in/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{lock:in,
-  title = {The Cloud is the Ultimate Vendor Lock-in},
-  url = {https://www.digital-manifesto.org/the-cloud-is-the-ultimate-vendor-lock-in/},
-  author = {Zielemans, François},
-  year = {2017},
-  visited = {2019-11-18},
-}
diff --git a/root/articles/mmmfs/references/market-share/text$bibtex b/root/articles/mmmfs/references/market-share/text$bibtex
deleted file mode 100644
index 430af2f..0000000
--- a/root/articles/mmmfs/references/market-share/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{market:share,
-  title = {Operating System Market Share - Desktop and Mobile},
-  year = {2019},
-  url = {https://s-ol.nu/ba/ref/nms},
-  oldURL = {https://netmarketshare.com/operating-system-market-share.aspx?options=%7B%22filter%22%3A%7B%22%24and%22%3A%5B%7B%22deviceType%22%3A%7B%22%24in%22%3A%5B%22Desktop%2Flaptop%22%2C%22Mobile%22%5D%7D%7D%5D%7D%2C%22dateLabel%22%3A%22Trend%22%2C%22attributes%22%3A%22share%22%2C%22group%22%3A%22platform%22%2C%22sort%22%3A%7B%22share%22%3A-1%7D%2C%22id%22%3A%22platformsDesktop%22%2C%22dateInterval%22%3A%22Monthly%22%2C%22dateStart%22%3A%222018-12%22%2C%22dateEnd%22%3A%222019-11%22%2C%22hiddenSeries%22%3A%7B%7D%2C%22tableOrder%22%3A%5B%5B2%2C%22desc%22%5D%5D%2C%22segments%22%3A%22-1000%22%7D},
-  publisher = {NetMarketShare},
-}
diff --git a/root/articles/mmmfs/references/memex/text$bibtex b/root/articles/mmmfs/references/memex/text$bibtex
deleted file mode 100644
index 313eec7..0000000
--- a/root/articles/mmmfs/references/memex/text$bibtex
+++ /dev/null
@@ -1,8 +0,0 @@
-@online{memex,
-  author = {Bush, Vannevar},
-  title = {As we may think},
-  journal = {Atlantic Monthly},
-  year = {1945},
-  visited = {2019-12-18},
-  url = {https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/}
-}
diff --git a/root/articles/mmmfs/references/mime-types/text$bibtex b/root/articles/mmmfs/references/mime-types/text$bibtex
deleted file mode 100644
index c49b553..0000000
--- a/root/articles/mmmfs/references/mime-types/text$bibtex
+++ /dev/null
@@ -1,14 +0,0 @@
-@article{rfc6838,
-  series = {Request for Comments},
-  number = 6838,
-  howpublished = {RFC 6838},
-  publisher = {Internet Engineering Task Force},
-  doi =  {10.17487/RFC6838},
-  url =  {https://tools.ietf.org/html/rfc6838},
-  author = {Freed, Ned and Klensin, John C. and Hansen, Tony},
-  title =  {Media Type Specifications and Registration Procedures},
-  pagetotal = 32,
-  year =  2013,
-  month =  jan,
-  abstract = {This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.},
-}
diff --git a/root/articles/mmmfs/references/osx-files/text$bibtex b/root/articles/mmmfs/references/osx-files/text$bibtex
deleted file mode 100644
index 7c70a87..0000000
--- a/root/articles/mmmfs/references/osx-files/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{osx:files,
-  title = {Where is "Show Package Contents"},
-  url = {https://discussions.apple.com/thread/6740790},
-  publisher = {Apple Communities},
-  visited = {2019-12-27},
-  year = 2014,
-}
diff --git a/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex b/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex
deleted file mode 100644
index 7cac092..0000000
--- a/root/articles/mmmfs/references/poc-or-gtfo/text$bibtex
+++ /dev/null
@@ -1,8 +0,0 @@
-@article{PoC:or:GTFO,
-  author = {Albertini, Ange},
-  title = {Abusing file formats; or, Corkami, the Novella},
-  year = {2015},
-  journal = {PoC||GTFO},
-  volume = {7},
-  pages = {18-41},
-}
diff --git a/root/articles/mmmfs/references/renaming/text$bibtex b/root/articles/mmmfs/references/renaming/text$bibtex
deleted file mode 100644
index 660bc2c..0000000
--- a/root/articles/mmmfs/references/renaming/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{renaming,
-  title = {Why is it possible to convert a file just by renaming it?},
-  url = {https://askubuntu.com/q/166602},
-  publisher = {askubuntu.com},
-  year = 2012,
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/subtext/cite$doi b/root/articles/mmmfs/references/subtext/cite$doi
deleted file mode 100644
index 2ac65b5..0000000
--- a/root/articles/mmmfs/references/subtext/cite$doi
+++ /dev/null
@@ -1 +0,0 @@
-10.1145/1103845.1094851
diff --git a/root/articles/mmmfs/references/subtext/text$bibtex b/root/articles/mmmfs/references/subtext/text$bibtex
deleted file mode 100644
index 7e9eb9d..0000000
--- a/root/articles/mmmfs/references/subtext/text$bibtex
+++ /dev/null
@@ -1,18 +0,0 @@
-@article{10.1145/1103845.1094851,
-  author = {Edwards, Jonathan},
-  title = {Subtext: Uncovering the Simplicity of Programming},
-  year = {2005},
-  issue_date = {October 2005},
-  publisher = {Association for Computing Machinery},
-  address = {New York, NY, USA},
-  volume = {40},
-  number = {10},
-  issn = {0362-1340},
-  url = {https://doi.org/10.1145/1103845.1094851},
-  doi = {10.1145/1103845.1094851},
-  journal = {SIGPLAN Not.},
-  month = oct,
-  pages = {505–518},
-  numpages = {14},
-  keywords = {copying, non-textual programming, prototypes, visual programming},
-}
diff --git a/root/articles/mmmfs/references/super-powers/text$bibtex b/root/articles/mmmfs/references/super-powers/text$bibtex
deleted file mode 100644
index 5eabda8..0000000
--- a/root/articles/mmmfs/references/super-powers/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{super:powers,
-  title = {Super-powers, but not yours},
-  url = {http://object.network/manifesto-negative.html},
-  author = {Cragg, Duncan},
-  year = {2016},
-  visited = {2019-12-18},
-}
diff --git a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 7b96c10..0000000
--- a/root/articles/mmmfs/references/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,13 +0,0 @@
-=>
-  html = require 'mmm.dom'
-  import div, h1, ol, li from html
-
-  refs = for ref in *@children
-    li ref\gett 'mmm/dom'
-  div {
-    class: 'print-ownpage'
-
-    h1 "references", id: 'references'
-    ol with refs
-      refs.style = 'line-height': 'normal'
-  }
diff --git a/root/articles/mmmfs/references/transclusion/text$bibtex b/root/articles/mmmfs/references/transclusion/text$bibtex
deleted file mode 100644
index e323662..0000000
--- a/root/articles/mmmfs/references/transclusion/text$bibtex
+++ /dev/null
@@ -1,10 +0,0 @@
-@article{article,
-  author = {Kolbitsch, Josef and Maurer, Hermann},
-  year = {2006},
-  month = {06},
-  pages = {161-173},
-  title = {Transclusions in an HTML-Based Environment},
-  volume = {14},
-  journal = {CIT},
-  doi = {10.2498/cit.2006.02.07},
-}
diff --git a/root/articles/mmmfs/references/unix/text$bibtex b/root/articles/mmmfs/references/unix/text$bibtex
deleted file mode 100644
index 70b139d..0000000
--- a/root/articles/mmmfs/references/unix/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@book{10.5555/577766,
-  author = {Kernighan, Brian W. and Pike, Rob},
-  title = {The UNIX Programming Environment},
-  year = {1983},
-  isbn = {0139376992},
-  publisher = {Prentice Hall Professional Technical Reference}
-}
diff --git a/root/articles/mmmfs/references/wikipedia/text$bibtex b/root/articles/mmmfs/references/wikipedia/text$bibtex
deleted file mode 100644
index d88d58c..0000000
--- a/root/articles/mmmfs/references/wikipedia/text$bibtex
+++ /dev/null
@@ -1,7 +0,0 @@
-@online{wikipedia,
-  title = {Hyperlink - Wikis},
-  url = {https://en.wikipedia.org/wiki/Hyperlink#Wikis},
-  publisher = {wikipedia.org},
-  visited = {2019-12-18},
-  year = {n. d.},
-}
diff --git a/root/articles/mmmfs/references/xerox-star/cite$doi b/root/articles/mmmfs/references/xerox-star/cite$doi
deleted file mode 100644
index b849172..0000000
--- a/root/articles/mmmfs/references/xerox-star/cite$doi
+++ /dev/null
@@ -1 +0,0 @@
-10.1109/2.35211
diff --git a/root/articles/mmmfs/references/xerox-star/text$bibtex b/root/articles/mmmfs/references/xerox-star/text$bibtex
deleted file mode 100644
index 870eed4..0000000
--- a/root/articles/mmmfs/references/xerox-star/text$bibtex
+++ /dev/null
@@ -1,18 +0,0 @@
-@article{10.1109/2.35211,
-  oldauthor = {Johnson, Jeff and Roberts, Teresa L. and Verplank, William and Smith, David C. and Irby, Charles H. and Beard, Marian and Mackey, Kevin},
-  author = {Johnson, Jeff et al.},
-  title = {The Xerox Star: A Retrospective},
-  year = {1989},
-  issue_date = {September 1989},
-  publisher = {IEEE Computer Society Press},
-  address = {Washington, DC, USA},
-  volume = {22},
-  number = {9},
-  issn = {0018-9162},
-  url = {https://doi.org/10.1109/2.35211},
-  doi = {10.1109/2.35211},
-  journal = {Computer},
-  month = sep,
-  pages = {11–26, 28–29},
-  numpages = {1},
-}
diff --git a/root/articles/mmmfs/statement-of-originality/text$html+frag.html b/root/articles/mmmfs/statement-of-originality/text$html+frag.html
deleted file mode 100644
index d6dcbc0..0000000
--- a/root/articles/mmmfs/statement-of-originality/text$html+frag.html
+++ /dev/null
@@ -1,13 +0,0 @@
-<div class="print-only print-ownpage" style="margin: 4cm 0 0;">
-<h1 id="statement">statement of originality</h1>
-<p style="margin-top: 5cm">
-This is to certify that the content of this project, documentation and thesis is my own work. It 
-has not been submitted for any other degree or other purposes. I certify that the intellectual 
-content of my submission is the product of my own work and that all the assistance received in 
-preparing it as well as all sources used have been properly acknowledged.
-</p>
-
-<div style="border-top: 1px solid #000; width: 7cm; margin-top: 3cm;">
-Sol Bekic
-</div>
-</div>
diff --git a/root/articles/mmmfs/table-of-contents/text$html+frag.html b/root/articles/mmmfs/table-of-contents/text$html+frag.html
deleted file mode 100644
index 2b94109..0000000
--- a/root/articles/mmmfs/table-of-contents/text$html+frag.html
+++ /dev/null
@@ -1,91 +0,0 @@
-<!--
-{
-  const fmt = x => `<a href="#${x.id}">${x.innerText}</a>`;
-
-  const parse = e => ({
-    num: +e.tagName.substr(1),
-    fmt: fmt(e),
-  });
-
-  const render = (list) => {
-    let str = '';
-    let num = 0;
-    for (e of list) {
-      while (e.num > num) {
-        str += '<ol style="list-style: none; padding-left: 2rem;">'
-        num += 1;
-      }
-
-      while (e.num < num) {
-        str += '</ol>';
-        num -= 1;
-      }
-
-      str += `<li>${e.fmt}</li>`;
-    }
-    return str;
-  };
-
-  render([...$0.querySelectorAll('h1, h2, h3, h4, h5').values()].map(parse));
-}
--->
-<section class="print-ownpage">
-  <h1 id="table-of-contents">table of contents</h1>
-  <ol style="list-style: none;">
-      <li><a href="#abstract">abstract</a></li>
-      <li><a href="#table-of-contents">table of contents</a></li>
-      <li><a href="#1introduction">1&emsp;introduction</a></li>
-      <li><a href="#2drawbacks-of-current-systems">2&emsp;drawbacks of current systems</a></li>
-      <ol style="list-style: none; padding-left: 2rem;">
-          <li><a href="#21application-centric-design">2.1&emsp;application-centric design</a></li>
-          <li><a href="#22cloud-computing">2.2&emsp;cloud computing</a></li>
-          <li><a href="#23inert-data-and-data-formats">2.3&emsp;inert data (and data formats)</a></li>
-          <li><a href="#24disjointed-filesystems">2.4&emsp;disjointed filesystems</a></li>
-      </ol>
-      <li><a href="#3historical-approaches">3&emsp;historical approaches</a></li>
-      <li><a href="#4evaluation-framework">4&emsp;evaluation framework</a></li>
-      <ol style="list-style: none; padding-left: 2rem;">
-          <li><a href="#41qualities-of-successful-end-user-computing">4.1&emsp;qualities of successful end-user computing</a></li>
-          <li><a href="#42modularity">4.2&emsp;modularity</a></li>
-          <li><a href="#43content-transclusion">4.3&emsp;content transclusion</a></li>
-          <li><a href="#44end-user-programming">4.4&emsp;end-user programming</a></li>
-      </ol>
-      <li><a href="#5system-description">5&emsp;system description</a></li>
-      <ol style="list-style: none; padding-left: 2rem;">
-          <li><a href="#51data-storage-model">5.1&emsp;data storage model</a></li>
-          <li><a href="#52type-system-and-coercion-engine">5.2&emsp;type system and coercion engine</a></li>
-      </ol>
-      <li><a href="#6example-use-cases">6&emsp;example use-cases</a></li>
-      <ol style="list-style: none; padding-left: 2rem;">
-          <li><a href="#61publishing-and-blogging">6.1&emsp;publishing and blogging</a></li>
-          <ol style="list-style: none; padding-left: 2rem;">
-              <li><a href="#611blogging">6.1.1&emsp;blogging</a></li>
-              <li><a href="#612scientific-publishing">6.1.2&emsp;scientific publishing</a></li>
-          </ol>
-          <li><a href="#62pinwall">6.2&emsp;pinwall</a></li>
-          <li><a href="#63slideshow">6.3&emsp;slideshow</a></li>
-      </ol>
-      <li><a href="#7evaluation">7&emsp;evaluation</a></li>
-      <ol style="list-style: none; padding-left: 2rem;">
-          <li><a href="#71examples">7.1&emsp;examples</a></li>
-          <ol style="list-style: none; padding-left: 2rem;">
-              <li><a href="#711publishing-and-blogging">7.1.1&emsp;publishing and blogging</a></li>
-              <li><a href="#712pinwall">7.1.2&emsp;pinwall</a></li>
-              <li><a href="#713slideshow">7.1.3&emsp;slideshow</a></li>
-          </ol>
-          <li><a href="#72general-concerns">7.2&emsp;general concerns</a></li>
-          <ol style="list-style: none; padding-left: 2rem;">
-              <li><a href="#721global-set-of-converts">7.2.1&emsp;global set of converts</a></li>
-              <li><a href="#722code-outside-of-the-system">7.2.2&emsp;code outside of the system</a></li>
-              <li><a href="#723type-system">7.2.3&emsp;type system</a></li>
-              <li><a href="#724type-coercion">7.2.4&emsp;type-coercion</a></li>
-              <li><a href="#725in-system-editing">7.2.5&emsp;in-system editing</a></li>
-              <li><a href="#726end-user-adoption">7.2.6&emsp;end-user adoption</a></li>
-          </ol>
-      </ol>
-      <li><a href="#8conclusion">8&emsp;conclusion</a></li>
-      <li><a href="#references">references</a></li>
-      <li><a href="#ba-log">appendix: project log</a></li>
-      <li><a href="#statement">statement of originality</a></li>
-  </ol>
-</section>
diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index 6c5b1d3..0000000
--- a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,26 +0,0 @@
--- main content
--- doesn't have a name prefix (e.g. preview: fn -> mmm/dom)
--- uses the 'fn ->' conversion to execute the lua function on @get
--- resolves to a value of type mmm/dom
-=>
-  html = require 'mmm.dom'
-  import article, h1, p, div from html
-  import moon from (require 'mmm.highlighting').languages
-
-  article with _this = class: 'sidenote-container spacious', style: { 'max-width': '640px', 'line-height': '1.5' }
-    append = (a) -> table.insert _this, a
-
-    append div {
-      h1 'Empowered End-User Computing', style: { 'margin-bottom': 0 }
-      p {
-        style:
-          'margin-top': 0
-          'padding-bottom': '0.2em'
-          'border-bottom': '1px solid black'
-
-        "A Historical Investigation and Development of a File-System-Based Environment"
-      }
-    }
-
-    for child in *@children
-      append child\gett 'mmm/dom'
diff --git a/root/articles/mmmfs/title/text$html+frag.html b/root/articles/mmmfs/title/text$html+frag.html
deleted file mode 100644
index 063b52a..0000000
--- a/root/articles/mmmfs/title/text$html+frag.html
+++ /dev/null
@@ -1,21 +0,0 @@
-<div class="print-only print-ownpage" style="font-size: 1.5rem; width: calc(100% + var(--sidenote-width))">
-  <div style="font-size: 2rem; margin-top: 4cm">
-    <h1>Empowered End-User Computing:</h1>
-    <span>A Historical Investigation and Development of a File-System-Based Environment</span>
-  </div>
-  <div style="width: 14cm; margin: 7cm auto 0">
-    <p>by</p>
-    <p>
-      Sol Bekic<br />
-      Student ID 11114279<br />
-      sol.bekic+ba@s-ol.nu
-    </p>
-    <p>
-      written in the Winter Term 2019/20<br />
-      for BA Digital Games<br />
-      at Cologne Game Lab / TH Köln
-    </p>
-    <p>supervised by Prof. Dr. Gundolf S. Freyermuth</p>
-    <p>submitted on 2020-01-07</p>
-  </div>
-</div>
diff --git a/root/articles/realities/description: text$plain b/root/articles/realities/description: text$plain
deleted file mode 100644
index c7a0891..0000000
--- a/root/articles/realities/description: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-exploring the nesting relationships of virtual and other realities
diff --git a/root/articles/realities/text$moonscript -> mmm$component.moon b/root/articles/realities/text$moonscript -> mmm$component.moon
deleted file mode 100644
index a7dc365..0000000
--- a/root/articles/realities/text$moonscript -> mmm$component.moon
+++ /dev/null
@@ -1,542 +0,0 @@
-import elements from require 'mmm.component'
-import h1, h2, p, a, i, div, ol, li, br, hr, span, button, section, article from elements
-
-_content = div!
-append = _content\append
-
-if MODE == 'SERVER'
-  export ^
-  class Diagram
-    style = {
-      display: 'inline-block',
-      width: '150px',
-      height: '80px',
-      'line-height': '80px',
-      color: '#fff',
-      background: '#666',
-    }
-
-    @id = 1
-    new: (@func) =>
-      @id = "diagram-#{@@id}"
-      @@id += 1
-
-    render: =>
-      rplc = with div id: @id, :style
-        \append '(diagram goes here)'
-        -- \append "<script type=\"text/lua\">
-        --   local rplc = js.global.document:getElementById('#{@id}');
-        --   local fn = #{compile @func}
-        --   diag = Diagram(fn)
-        --   rplc.parentNode:replaceChild(diag.node, rplc)
-        -- </script>"
-      rplc\render!
-
-if MODE == 'CLIENT'
-  export ^
-  export o
-  eval = js.global\eval
-  GRID_W = 50
-  GRID_H = 40
-
-  SVG =
-    doc: eval "(function() { return SVG(document.createElement('svg')); })",
-    G: eval "(function() { return new SVG.G(); })",
-  setmetatable SVG, __call: => @doc!
-
-  o = do
-    mkobj = eval "(function () { return {}; })"
-    (tbl) ->
-      with obj = mkobj!
-        for k,v in pairs(tbl)
-          obj[k] = v
-
-  class Diagram
-    new: (f) =>
-      @svg = SVG!
-      @arrows = SVG.G!
-      @width, @height = 0, 0
-      @y = 0
-
-      f @
-
-    txtattr = o {
-      fill: 'white',
-      'font-size': '14px',
-      'text-anchor': 'middle',
-    }
-    block: (color, label, h=1) =>
-      @svg\add with SVG.G!
-        with \rect GRID_W, h * GRID_H
-          \attr o fill: color
-        if label
-          with \plain label
-            \move GRID_W/2, 0
-            \attr txtattr
-
-        \move @width * GRID_W, (@y + h) * -GRID_H
-      @y += h
-      if @y > @height
-        @height = @y
-
-    arrattr = o {
-      fill: 'white',
-      'font-size': '18px',
-      'text-anchor': 'middle',
-    }
-    arrow: (char, x, y) =>
-      with @arrows\plain char
-        \attr arrattr
-        \move (x + 1) * GRID_W, (y - 0.5) * -GRID_H - 11
-
-    -- inout: (x=@width, y=@y) => @arrow '⇋', x, y      -- U+21CB
-    -- inn:   (x=@width, y=@y) => @arrow '↼', x, y+0.25 -- U+21BC
-    -- out:   (x=@width, y=@y) => @arrow '⇁', x, y-0.25 -- U+21C1
-    inout: (x=@width, y=@y) => @arrow '⇆', x, y      -- U+21C6
-    inn:   (x=@width, y=@y) => @arrow '←', x, y+0.25 -- U+2190
-    out:   (x=@width, y=@y) => @arrow '→', x, y-0.25 -- U+2192
-
-    mind: (label='mind', ...) => @block '#fac710', label, ...
-    phys: (label='phys', ...) => @block '#8fd13f', label, ...
-    digi: (label='digi', ...) => @block '#9510ac', label, ...
-
-    next: =>
-      @y = 0
-      @width += 1
-
-    finish: =>
-      return if @node
-      @svg\add @arrows
-
-      @width += 1
-      w, h = @width * GRID_W, @height * GRID_H
-
-      l = GRID_W / 6.5
-      @svg\add with @svg\line 0, -GRID_H, w, -GRID_H
-        \stroke o width: 2, color: '#ffffff', dasharray: "#{l}, #{l}"
-
-      @svg\size w, h
-      @svg\viewbox 0, -h, w, h
-      @node = @svg.node
-
-addlabel = (label, diagram) ->
-  with div style: { display: 'inline-block', margin: '20px', 'text-align': 'center' }
-    \append diagram
-    \append div label
-
-figures = do
-  style =
-    display: 'flex'
-    'align-items': 'flex-end'
-    'justify-content': 'space-evenly'
-  (...) -> div { :style, ... }
-
-sources = do
-  short = => "#{@id} #{@year}"
-  long = => @names, " (#{@year}): ", (i @title), ", #{@published}"
-  {
-    {
-      id: 'Milgram',
-      title: 'Augmented Reality: A class of displays on the reality-virtuality continuum',
-      published: 'in SPIE Vol. 2351',
-      names: 'P. Milgram, H. Takemura, A. Utsumi, F. Kishino',
-      year: 1994
-      :long, :short,
-    },
-    {
-      id: 'Marsh',
-      title: 'Nested Immersion: Describing and Classifying Augmented Virtual Reality',
-      published: 'IEEE Virtual Reality Conference 2015',
-      names: 'W. Marsh, F. Mérienne',
-      year: 2015
-      :long, :short,
-    },
-    {
-      id: 'Billinghurst',
-      title: 'The MagicBook: a transitional AR interface',
-      published: 'in Computer & Graphics 25',
-      names: 'M. Billinghurst, H. Kato, I. Poupyrev',
-      year: 2001,
-      :long, :short,
-    },
-    {
-      id: 'Matrix',
-       title: 'The Matrix',
-       year: 1999,
-       names: 'L. Wachowski, A. Wachowski',
-       long: => @names, " (#{@year}): ", (i @title), " (movie)"
-       short: => tostring @year
-    },
-    {
-      id: 'Naam',
-      title: 'Nexus',
-      published: 'Angry Robot (novel)',
-      names: 'R. Naam',
-      year: 2012,
-      :long, :short,
-    }
-  }
-
-ref = do
-  fmt = (id) ->
-
-    local src
-    for _src in *sources
-      if _src.id == id
-        src = _src
-        break
-
-    if src
-      a { src\short!, href: "##{src.id}" }
-    else
-      span id
-
-  ref = (...) ->
-    refs = { ... }
-    with span "(", fmt refs[1]
-      for i=2, #refs
-        \append ", "
-        \append fmt refs[i]
-      \append ")"
-
-references = ->
-  with ol!
-    for src in *sources
-      \append li { id: src.id, src\long! }
-
-sect = (label) ->
-  with section style: 'page-break-inside': 'avoid'
-    \append h2 label
-
-append with article style: { margin: 'auto', 'max-width': '750px' }
-  \append div 'Sol Bekic', style: 'text-align': 'right'
-
-  \append h1 {
-    style: { 'text-align': 'center', 'font-size': '2em' },
-    "Reality Stacks",
-    div "a Taxonomy for Multi-Reality Experiences", style: 'font-size': '0.6em'
-  }
-
-  \append with sect "Abstract"
-    \append p "With the development of mixed-reality experiences and the corresponding interface devices
-      multiple frameworks for classification of these experiences have been proposed. However these past
-      attempts have mostly been developed alongside and with the intent of capturing specific projects ",
-      (ref 'Marsh', 'Billinghurst'), " or are nevertheless very focused on existing methods and technologies ",
-      (ref 'Milgram'), ". The existing taxonomies also all assume physical reality as a fixpoint and constant and are
-      thereby not suited to describe many fictional mixed-reality environments and altered states of consciousness.
-      In this paper we describe a new model for describing such experiences and examplify it's use with currently
-      existing as well as idealized  technologies from popular culture."
-
-  \append with sect "Terminology"
-    \append p "We propose the following terms and definitions that will be used extensively for the remainder of the paper:"
-    for definition in *{
-      { "layer of reality": "a closed system consisting of a world model and a set of rules or dynamics operating on and
-        constraining said model." },
-      { "world model": "describes a world state containing objects, agents and/or concepts on an arbitrary abstraction level." },
-      '------',
-      { "reality stack": "structure consisting of all layers of reality encoding an agent's interaction with his environment
-        in their world model at a given moment, as well as all layers supporting these respectively." },
-      '------',
-      { "physical reality": "layer of reality defined by physical matter and the physical laws acting upon it.
-        While the emergent phenomena of micro- and macro physics as well as layers of social existence etc. may be seen
-        as separate layers, for the purpose of this paper we will group these together under the term of physical reality." },
-      { "mental reality": "layer of reality perceived and processed by the brain of a human agent." },
-      { "digital reality": "layer of reality created and simulated by a digital system, e.g. a virtual reality game." },
-      { "phys, mind, digi": "abbreviations for physical, mental and digital reality respectively." },
-    }
-      if 'string' == type definition
-        \append hr!
-        continue
-      \append with div style: { 'margin-left': '2rem' }
-        term = next definition
-        \append span term, style: {
-          display: 'inline-block',
-          'margin-left': '-2rem',
-          'font-weight': 'bold',
-          'min-width': '140px'
-        }
-        \append span definition[term]
-
-  \append with sect "Introduction"
-    \append p "We identify two different types of relationships between layers in multi-reality environments.
-      The first is layer nesting. Layer nesting describes how some layers are contained in other layers; i.e. they exist
-      within and can be represented fully by the parent layer's world model and the child layer's rules emerge natively from
-      the parent layer's dynamics. Layer nesting is visualized on the vertical axis in the following diagrams.
-      For each layer of reality on the bottom of the diagram the nested parent layers can be found by tracing a line upwards
-      to the top of the diagram. Following a materialistic point of view, physical reality therefore must completely encompass
-      the top of each diagram."
-
-    \append p "The second type of relationship describes the information flow between a subject and the layers of reality
-      the subject is immersed in. In a multi-reality experience the subject has access to multiple layers of reality and
-      their corresponding world models simultaneously.", br!,
-      "Depending on the specific experience, different types of and directions for information exchange
-      can exist between these layers and the subject's internal representation of the experience.
-      For the sake of this paper we distinguish only between ", (i "input"), " and ", (i "output"), " data flow (from the
-      perspective of the subject); categorized loosely as information the subject receives from the environment
-      (", (i "input"), ", e.g. visual stimuli) and actions the subject can take to influence the state of the world model
-      (", (i "output"), ", e.g. motor actions) respectively."
-
-    \append p "In the following diagrams, information flow is visualized horizontally, in the region below the dashed line
-      at the bottom of the diagram. The subject's internal mental model and layer of reality are placed on the bottom left
-      side of the diagram.
-      The layers of reality that the subject experiences directly and that mirror it's internal representations are placed
-      on the far right. There may be multiple layers of reality sharing this space, visualized as a vertical stack of
-      layers. Since the subject must necessarily have a complete internal model of the multi-reality experience around
-      him to feel immersed, the subject's mental layer of reality must span the full height of all the layers visible
-      on the right side of the diagram.", br!,
-      "Information flow itself is now visualized concretely using arrows that cross layer boundaries in the lower part of
-      the diagram as described above. Arrows pointing leftwards denote ", (i "input"), " flow, whilst arrows pointing
-      rightwards denote ", (i "output"), "-directed information flow. In some cases information doesn't flow directly
-      between the layers the subject is directly aware of and the subject's internal representation and instead
-      traverses ", (i "intermediate layers"), " first."
-
-    \append p "Before we take a look at some reality stacks corresponding to current VR and AR technology,
-      we can take a look at waking life as a baseline stack. To illustrate the format of the diagram we will compare it
-      to the stack corresponding to a dreaming state:"
-
-    \append with figures!
-      \append addlabel "Waking Life", Diagram =>
-        @mind!
-        @inout!
-        @phys!
-
-        @next!
-        @phys '', 2
-        @finish!
-
-      \append addlabel "Dreaming", Diagram =>
-        @mind!
-        @phys!
-        @finish!
-
-    \append p "In both cases, the top of the diagram is fully occupied by the physical layer of reality, colored in green.
-      This is due to the fact that, according to the materialistic theory of mind, human consciousness owes its existance
-      to the physical and chemical dynamics of neurons in our brains. Therefore our mental reality must be considered
-      fully embedded in the physical reality, and consequently it may only appear underneath it in the diagram."
-
-    \append p "During waking life, we concern ourselves mostly with the physical reality surrounding us.
-      For this reason the physical reality is placed in the lower right corner of the diagram as the layer holding the
-      external world model relevant to the subject. Information flows in both directions between the physical world model
-      and the subject's mental model, as denoted by the two white arrows: Information about the state of the world model
-      enter the subjects mind via the senses (top arrow, pointing leftwards), and choices the subject makes inside of and
-      based on his mental model can feed back into the physical layer through movements (lower arrow, pointing rightwards)."
-
-    \append p "In the dreaming state on the other hand, the subject is unaware of the physical layer of reality, though
-      the mind remains embedded inside it. When dreaming, subjects' mental models don't depend on external models, hence
-      the mental layer of reality must be the only layer along the bottom of the diagram."
-
-  \append with sect "Current Technologies"
-    \append p "Since recent technological advancements have enabled the development of VR and AR consumer devices,
-      AR and VR have been established as the potential next frontier of digital entertainment.", br!,
-      "As the names imply, the notion of reality is at the core of both technologies.
-      In the following section we will take a look at the respective stacks of both experience types:"
-
-    \append with figures!
-      \append addlabel "VR", Diagram =>
-        @mind!
-        @phys!
-        @inout nil, 1
-
-        @next!
-        @phys '', 2
-        @inout nil, 1
-
-        @next!
-        @digi!
-        @phys ''
-        @finish!
-
-
-      \append addlabel "AR", Diagram =>
-        @mind!
-        @inout nil, 1.25
-        @inn nil, 0.5
-        @phys!
-
-        @next!
-        @phys '', 2
-        @inn nil, .5
-
-        @next!
-        @digi nil, .5
-        @phys '', 1.5
-        @finish!
-
-    \append p "In both cases we find the physical layer of reality as an ", (i "intermediate layer"), " between the mental
-      and digital layers. Actions taken by the subject have to be acted out physically (corresponding to the
-      information traversing the barrier between mental and physical reality) before they can be again digitized using
-      the various tracking and input technologies (which in turn carry the information across the boundary of the physical
-      and digital spaces)."
-
-    \append p "The difference between AR and VR lies in the fact that in AR the subject experiences a mixture of the
-      digital and physical world models. This can be seen in the diagram, where we find that right of the diagram origin
-      and the mental model, the diagram splits and terminates in both layers: while information reaches the subject both
-      from the digital reality through the physical one, as well as directly from the physical reality, the subject only
-      directly manipulates state in the physical reality."
-
-    \append p "The data conversions necessary at layer boundaries incur at the least losses in quality and accuracy of
-      information for purely technical reasons. However ", (i "intermediate layers"), " come at a cost larger than just
-      an additional step of conversion:
-      For information to flow through a layer, it must be encodable within that layer’s world model.
-      This means that the 'weakest link' in a given reality stack determines the upper bound of information possible to
-      encode within said stack and thereby limits the overall expressivity of the stack.", br!,
-      "As a practical example we can consider creating an hypothetical VR application that allows users to traverse a
-      large virtual space by flying. While the human mind is perfectly capable of imagining to fly and control the motion
-      appropriately, it is extremely hard to devise and implement a satisfying setup and control scheme because the
-      physical body of the user needs to be taken into account and it, unlike the corresponding representations in the
-      mental and digital world models, cannot float around freely."
-
-  \append with sect "Future Developments"
-    \append p "In the previous section we found that the presence of the physical layer in the information path of
-      VR and AR stacks limits the experience as a whole. It follows that the removal of that indirection should be
-      an obvious goal for future developments:"
-
-    \append figures addlabel "holy grail of VR: 'The Matrix'", Diagram =>
-      @mind!
-      @inout!
-      @phys!
-
-      @next!
-      @digi!
-      @phys ''
-      @finish!
-
-    \append p "In the action movie 'The Matrix' ", (ref 'Matrix'), ", users of the titular VR environment interface with it
-      by plugging cables into implanted sockets that connect the simulation directly to their central nervous system.", br!,
-      "While these cables and implanted devices are physical devices, they don't constitute the presence of the 
-      physical layer of reality in the information path because while they do transmit information, the information
-      remains in either the encoding of the mental model (neural firing patterns) or the encoding of the digital model
-      (e.g. a numeric encoding of a player character's movement in digital space) and the conversion is made directly
-      between those two - the data never assumes the native encoding of the physical layer (e.g. as a physical motion)."
-
-    \append p "While we are currently far from being able to read arbitrary high-level information from the brain
-      or to synthesize sensual input in human perception by bypassing the sensory organs, brain-computer interfaces (BCI)
-      are a very active area of research with high hopes for comparable achievements in the near future."
-
-    \append p "Applying this same step of removing the physical layer of reality from AR, we end up with something similar
-      to the nano-particle drug in ", (i "Nexus"), " ", (ref 'Naam'), ".  However this does not grant the user a similar
-      amount of control over his experience as the holy grail of VR does, since the user and the physical part of the
-      environment remain bound by the physical layer of reality's laws.", br!,
-      "Instead the holy grail of AR is reached with the creation of a god machine that can manipulate the state of the
-      physical world according to the user's wishes. In this way the digital and physical realities become unified and
-      fully 'augmented'."
-
-    \append with figures!
-      \append addlabel "'Nexus'", Diagram =>
-        @mind!
-        @inout nil, 0.75
-        @inout nil, 1.25
-        @phys!
-
-        @next!
-        @digi nil, .5
-        @phys '', 1.5
-        @finish!
-
-      \append addlabel "holy grail of AR: 'Deus Machina'", Diagram =>
-        col = '#92807c'
-
-        @mind!
-        @inout!
-        @block col, ''
-
-        @next!
-        @block col, '', 2
-        @svg\plain('phys + digi')\attr(o fill: 'white', 'font-size': '14px')\move 6, -2 * GRID_H
-        @finish!
-
-    \append p "Despite the similarities of VR and AR, the two can be considered polar opposites, as becomes evident when
-      we compare their respective utopian implementations: they share the goal of allowing us to experience realities
-      different from the one we naturally inhabit, but while VR seeks to accomplish this by creating a new, nested reality
-      inside ours, thus giving us full control over it.
-      AR, on the other hand, is instead an attempt to retrofit our specific needs directly into the very reality we exist
-      in.", br!,
-      "This is in direct contrast with the popular notion of the 'reality-virtuality continuum' ", (ref 'Milgram'), ":
-      the reality-virtuality continuum places common reality and VR (virtuality) as the two extreme poles, while AR
-      is represented as an intermediate state between the two. Here however we propose to view instead AR and VR as the
-      respective poles and find instead reality at the centerpoint, where the two opposing influences 'cancel out'."
-
-  \append with sect "Conclusion and Further Work"
-    \append p "In this paper we have proposed a taxonomy and visualization style for multi-reality experiences, as well
-      as demonstrated it's flexibility by applying them as examples. Through the application of the proposed theory,
-      we have also gained a new and contrasting view on preceding work such as the reality-virtuality-continuum.
-      We have also found that the taxonomy can be used outside the research field of media studies and its use may extend
-      as far as philosophy of consciousness (see Appendix below)."
-
-    \append p "Further research could enhance the proposed theory with better and more concrete definitions.
-      In the future, the proposed taxonomy might be used to create a more extensive and complete classification
-      of reality stacks and to analyse the relationships between them."
-
-  \append with sect 'References'
-    \append references!
-
-  \append with sect "Appendix: Relation to Theories of Mind"
-    \append p "This paper starts from a deeply materialistic point of view that borders on microphysicalism.
-      However it should be noted that the diagram style introduced above lends itself also to display other
-      philosophical theories of mind. As an example, the following graphics show a typical VR stack as interpreted by
-      Materialism, Cartesian Dualism and Solipsism respectively:"
-
-    \append with figures!
-      \append addlabel "VR in Materialism", Diagram =>
-        @mind!
-        @inout nil, 1
-        @phys!
-
-        @next!
-        @phys '', 2
-        @inout nil, 1
-
-        @next!
-        @digi!
-        @phys ''
-
-        @finish!
-
-      \append addlabel "VR in Solipsism", Diagram =>
-        @mind nil, 2
-        @inout nil, 1
-
-        @next!
-        @digi!
-        @mind ''
-        @finish!
-
-      \append addlabel "VR in Cartesian Dualism", Diagram =>
-        @mind nil, 2
-        @inout nil, 1
-        @next!
-
-        @phys nil, 2
-        @inout nil, 1
-        @next!
-
-        @digi!
-        @phys ''
-        @finish!
-
-    \append p "However these philosophical theories of minds also constitute reality stacks by themselves and as such can
-      be compared directly:"
-
-    \append with figures!
-      \append addlabel "Materialism", Diagram =>
-        @mind!
-        @inout!
-        @phys!
-
-        @next!
-        @phys '', 2
-        @finish!
-
-      \append addlabel "Solipsism", Diagram =>
-        @mind!
-        @finish!
-
-      \append addlabel "Cartesian Dualism", Diagram =>
-        @mind!
-        @inout!
-        @next!
-
-        @phys!
-        @finish!
-
-_content
diff --git a/root/articles/text$moonscript -> fn -> mmm$dom.moon b/root/articles/text$moonscript -> fn -> mmm$dom.moon
deleted file mode 100644
index aec02d9..0000000
--- a/root/articles/text$moonscript -> fn -> mmm$dom.moon
+++ /dev/null
@@ -1,10 +0,0 @@
-import div, h3, ul, li from require 'mmm.dom'
-import link_to from (require 'mmm.mmmfs.util') require 'mmm.dom'
-
-=>
-  div {
-    h3 link_to @
-    ul for child in *@children
-      desc = child\gett 'description: mmm/dom'
-      li (link_to child), ': ', desc
-  }
diff --git a/root/articles/title: text$plain b/root/articles/title: text$plain
deleted file mode 100644
index c45a444..0000000
--- a/root/articles/title: text$plain
+++ /dev/null
@@ -1 +0,0 @@
-articles and papers