mmmfs cleanup

30 files changed, 199 insertions, 217 deletions

diff --git a/root/articles/mmmfs/abstract/text$markdown.md b/root/articles/mmmfs/abstract/text$markdown.md
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/root/articles/mmmfs/abstract/text$markdown.md
diff --git a/root/articles/mmmfs/evaluation/text$markdown.md b/root/articles/mmmfs/evaluation/text$markdown.md
new file mode 100644
index 0000000..87404cd
--- /dev/null
+++ b/root/articles/mmmfs/evaluation/text$markdown.md
@@ -0,0 +1,74 @@
+Drawbacks & Future Work
+-----------------------
+
+There are multiple limitations in the proposed system that have become obvious in developing and working with the system.
+Some of these have been anticipated for some time and concrete research directions for solutions are apparent,
+while others may be intrinsic limitations in the approach taken.
+
+### global set of converts
+In the current system, there exists only a single, global set of *converts* that can be potentially applied
+to facets anywhere in the system.
+Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
+For example if a fileder conatining 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 yet more propblems and works against the principle of
+compatibility 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.
+
+### 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 become a limitation of the user experience now:
+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 of, and the customizability of the system.
+
+This is particularily relevant for the global set of *converts*, and the layout used to render the web view, 
+which 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.
+
+### superficial type system
+The currently used type system based on strings and pattern matching has been largely satisfactory,
+but has proven problematic for satisfying 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.
+
+### type-coercion alienates
+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.
+It remains to be seen whether this can be mitigated with careful UX and UI design.
+
+### discrepancy between viewing/interacting and editing of content
+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 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 at all.
+Similarily, when viewing output that is generated by code (e.g. `text/moonscript -> mmm/dom`),
+the code itself is not visible to the user when interacting with the viewable representation,
+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.
+As a result, the experiences of interacting with the system at large is still a very different experience than 
+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.
diff --git a/root/articles/mmmfs/empty/title: text$plain b/root/articles/mmmfs/examples/empty/title: text$plain
index 911f98b..911f98b 100644
--- a/root/articles/mmmfs/empty/title: text$plain
+++ b/root/articles/mmmfs/examples/empty/title: text$plain
diff --git a/root/articles/mmmfs/gallery/actual_image/image$png.png b/root/articles/mmmfs/examples/gallery/actual_image/image$png.png
index b499413..b499413 100644
--- a/root/articles/mmmfs/gallery/actual_image/image$png.png
+++ b/root/articles/mmmfs/examples/gallery/actual_image/image$png.png
diff --git a/root/articles/mmmfs/gallery/actual_image/preview: image$png.png b/root/articles/mmmfs/examples/gallery/actual_image/preview: image$png.png
index f9dbfad..f9dbfad 100644
--- a/root/articles/mmmfs/gallery/actual_image/preview: image$png.png
+++ b/root/articles/mmmfs/examples/gallery/actual_image/preview: image$png.png
diff --git a/root/articles/mmmfs/gallery/link_to_image/URL -> image$png b/root/articles/mmmfs/examples/gallery/link_to_image/URL -> image$png
index 7cf76ff..7cf76ff 100644
--- a/root/articles/mmmfs/gallery/link_to_image/URL -> image$png
+++ b/root/articles/mmmfs/examples/gallery/link_to_image/URL -> image$png
diff --git a/root/articles/mmmfs/gallery/link_to_image/preview: URL -> image$png b/root/articles/mmmfs/examples/gallery/link_to_image/preview: URL -> image$png
index 2b2233b..2b2233b 100644
--- a/root/articles/mmmfs/gallery/link_to_image/preview: URL -> image$png
+++ b/root/articles/mmmfs/examples/gallery/link_to_image/preview: URL -> image$png
diff --git a/root/articles/mmmfs/gallery/preview: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/gallery/preview: text$moonscript -> fn -> mmm$dom.moon
index 5285629..5285629 100644
--- a/root/articles/mmmfs/gallery/preview: text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/examples/gallery/preview: text$moonscript -> fn -> mmm$dom.moon
diff --git a/root/articles/mmmfs/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon b/root/articles/mmmfs/examples/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon
index 0178ac2..0178ac2 100644
--- a/root/articles/mmmfs/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon
+++ b/root/articles/mmmfs/examples/gallery/slideshow: text$moonscript -> fn -> mmm$component.moon
diff --git a/root/articles/mmmfs/gallery/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/gallery/text$moonscript -> fn -> mmm$dom.moon
index 9bdac54..9bdac54 100644
--- a/root/articles/mmmfs/gallery/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/examples/gallery/text$moonscript -> fn -> mmm$dom.moon
diff --git a/root/articles/mmmfs/gallery/title: text$plain b/root/articles/mmmfs/examples/gallery/title: text$plain
index ad74eec..ad74eec 100644
--- a/root/articles/mmmfs/gallery/title: text$plain
+++ b/root/articles/mmmfs/examples/gallery/title: text$plain
diff --git a/root/articles/mmmfs/image/URL -> image$png b/root/articles/mmmfs/examples/image/URL -> image$png
index c586722..c586722 100644
--- a/root/articles/mmmfs/image/URL -> image$png
+++ b/root/articles/mmmfs/examples/image/URL -> image$png
diff --git a/root/articles/mmmfs/image/preview: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/image/preview: text$moonscript -> fn -> mmm$dom.moon
index 6c431d0..6c431d0 100644
--- a/root/articles/mmmfs/image/preview: text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/examples/image/preview: text$moonscript -> fn -> mmm$dom.moon
diff --git a/root/articles/mmmfs/image/title: text$plain b/root/articles/mmmfs/examples/image/title: text$plain
index 60a556f..60a556f 100644
--- a/root/articles/mmmfs/image/title: text$plain
+++ b/root/articles/mmmfs/examples/image/title: text$plain
diff --git a/root/articles/mmmfs/language_support/javascript/text$javascript -> mmm$dom.js b/root/articles/mmmfs/examples/language_support/javascript/text$javascript -> mmm$dom.js
index de56531..de56531 100644
--- a/root/articles/mmmfs/language_support/javascript/text$javascript -> mmm$dom.js
+++ b/root/articles/mmmfs/examples/language_support/javascript/text$javascript -> mmm$dom.js
diff --git a/root/articles/mmmfs/language_support/javascript/title: text$plain b/root/articles/mmmfs/examples/language_support/javascript/title: text$plain
index 581fbc7..581fbc7 100644
--- a/root/articles/mmmfs/language_support/javascript/title: text$plain
+++ b/root/articles/mmmfs/examples/language_support/javascript/title: text$plain
diff --git a/root/articles/mmmfs/language_support/lua/text$lua -> mmm$dom.lua b/root/articles/mmmfs/examples/language_support/lua/text$lua -> mmm$dom.lua
index 62e79f1..62e79f1 100644
--- a/root/articles/mmmfs/language_support/lua/text$lua -> mmm$dom.lua
+++ b/root/articles/mmmfs/examples/language_support/lua/text$lua -> mmm$dom.lua
diff --git a/root/articles/mmmfs/language_support/lua/title: text$plain b/root/articles/mmmfs/examples/language_support/lua/title: text$plain
index 0f9d550..0f9d550 100644
--- a/root/articles/mmmfs/language_support/lua/title: text$plain
+++ b/root/articles/mmmfs/examples/language_support/lua/title: text$plain
diff --git a/root/articles/mmmfs/language_support/moonscript/text$moonscript -> mmm$dom.moon b/root/articles/mmmfs/examples/language_support/moonscript/text$moonscript -> mmm$dom.moon
index 5cc50e6..5cc50e6 100644
--- a/root/articles/mmmfs/language_support/moonscript/text$moonscript -> mmm$dom.moon
+++ b/root/articles/mmmfs/examples/language_support/moonscript/text$moonscript -> mmm$dom.moon
diff --git a/root/articles/mmmfs/language_support/moonscript/title: text$plain b/root/articles/mmmfs/examples/language_support/moonscript/title: text$plain
index f8871ac..f8871ac 100644
--- a/root/articles/mmmfs/language_support/moonscript/title: text$plain
+++ b/root/articles/mmmfs/examples/language_support/moonscript/title: text$plain
diff --git a/root/articles/mmmfs/language_support/preview: text$markdown b/root/articles/mmmfs/examples/language_support/preview: text$markdown
index d6c2845..d6c2845 100644
--- a/root/articles/mmmfs/language_support/preview: text$markdown
+++ b/root/articles/mmmfs/examples/language_support/preview: text$markdown
diff --git a/root/articles/mmmfs/language_support/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/language_support/text$moonscript -> fn -> mmm$dom.moon
index 4ae0679..4ae0679 100644
--- a/root/articles/mmmfs/language_support/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/examples/language_support/text$moonscript -> fn -> mmm$dom.moon
diff --git a/root/articles/mmmfs/language_support/title: text$plain b/root/articles/mmmfs/examples/language_support/title: text$plain
index ae06474..ae06474 100644
--- a/root/articles/mmmfs/language_support/title: text$plain
+++ b/root/articles/mmmfs/examples/language_support/title: text$plain
diff --git a/root/articles/mmmfs/markdown/preview: text$markdown.md b/root/articles/mmmfs/examples/markdown/preview: text$markdown.md
index 4b38ef2..4b38ef2 100644
--- a/root/articles/mmmfs/markdown/preview: text$markdown.md
+++ b/root/articles/mmmfs/examples/markdown/preview: text$markdown.md
diff --git a/root/articles/mmmfs/markdown/title: text$plain b/root/articles/mmmfs/examples/markdown/title: text$plain
index 319068d..319068d 100644
--- a/root/articles/mmmfs/markdown/title: text$plain
+++ b/root/articles/mmmfs/examples/markdown/title: text$plain
diff --git a/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
new file mode 100644
index 0000000..ca9078c
--- /dev/null
+++ b/root/articles/mmmfs/examples/text$moonscript -> fn -> mmm$dom.moon
@@ -0,0 +1,32 @@
+-- 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 from 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',
+      },
+    }
+
+  div for child in *@children
+    preview child
diff --git a/root/articles/mmmfs/framework/text$markdown.md b/root/articles/mmmfs/framework/text$markdown.md
new file mode 100644
index 0000000..cc059ad
--- /dev/null
+++ b/root/articles/mmmfs/framework/text$markdown.md
@@ -0,0 +1,15 @@
+Based on this, a modern data storage and processing ecosystem should enable transclusion of both content and behaviours
+between contexts.
+Content should be able to be transcluded and referenced 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.
+Behaviours should be able to be transcluded and reused to facilitate the creation of ad-hoc sytems 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.
+
+The system should enable the quick creation of ad-hoc software.
+
+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 behaviours 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.
+
+The system needs to be browsable and understandable by users.
diff --git a/root/articles/mmmfs/mmmfs/text$markdown.md b/root/articles/mmmfs/mmmfs/text$markdown.md
index 3ab6dee..214a720 100644
--- a/root/articles/mmmfs/mmmfs/text$markdown.md
+++ b/root/articles/mmmfs/mmmfs/text$markdown.md
@@ -5,25 +5,24 @@ This is accomplished using two major components, the *Type System and Coercion E
 
 # The Fileder Unified Data Model
 The Fileder Model is the underlying unified data storage model.
-Like almost all current data storage and access models it is based fundamentally on the concept of a hierarchical tree-structure.
+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*),
+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, browser, listed and viewed by both),
 *files* are, from the system perspective, mostly opaque and inert blocks of data.
-Some metadata is associated with them (filesize, access permissions),
+
+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 is determined loosely based on multiple heuristics based on the system and context, notably:
+but determined loosely based on multiple heuristics depending on the system and context.
+Some notable mechanism are:
 - Suffixes in the name are often used to indicate what kind of data a file should contain.
   However there is no standardization over this, and often a suffix is used for multiple incompatible versions of a file-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.
-  However, since not all file-formats use magic constants, and since the location and value of the magic constants varies between constants,
-  files can often (considered to) be valid in multiple formats at the same time.
-  [TODO: quote: "Abusing file formats; or, Corkami, the Novella", Ange Albertini, PoC||GTFO 7]
 - on UNIX systems files to be executed are checked by a variety of methods to determine which format would fit.
   for script files, the "shebang" (`#!`) can be used to specify the program that should parse this file in the first line of the file.
   [@TODO: src: https://stackoverflow.com/questions/23295724/how-does-linux-execute-a-file]
@@ -31,6 +30,16 @@ but is determined loosely based on multiple heuristics based on the system and c
 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 labelled as 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 (e.g. making unclear the difference between changing a file extension
+and converting a file between formats [TODO: quote below]), but can also pose a serious security risk.
+It is for example possible, under some circumstances,
+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
+(the file may in fact be valid in both formats).
+[TODO: quote: "Abusing file formats; or, Corkami, the Novella", Ange Albertini, PoC||GTFO 7]
+
 Users renaming extensions:
   https://askubuntu.com/questions/166602/why-is-it-possible-to-convert-a-file-just-by-renaming-its-extension
   https://www.quora.com/What-happens-when-you-rename-a-jpg-to-a-png-file
@@ -38,7 +47,6 @@ Users renaming extensions:
 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 is 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*, *factes* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*,
diff --git a/root/articles/mmmfs/problem-statement/text$markdown.md b/root/articles/mmmfs/problem-statement/text$markdown.md
index d992e6e..78dbd76 100644
--- a/root/articles/mmmfs/problem-statement/text$markdown.md
+++ b/root/articles/mmmfs/problem-statement/text$markdown.md
@@ -1,6 +1,58 @@
 # motivation
+The application-centric computing paradigm common today is harmful to users,
+because it leaves behind "intert" data as D. Cragg calls it:
+
+[Cragg 2016]
+D. Cragg coins the term "inert data" 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 and depend soley on online tools that require a stable network connection
+and a modern browser, and that could be modified, removed or otherwise negatively impacted at any moment.
+
+This issue is worsened by the fact that the a lot of software we use today is deployed through the cloud computing and SaaS paradigms,
+which are far less reliable than earlier means of distributing software:
+Software that runs in the cloud is subject to outages due to network problems,
+pricing or availability changes etc. at the whim of the company providing it, as well as ISPs involved in the distribution.
+Cloud software, as well as subscription-model software with online-verification mechanisms are additionally subject
+to license changes, updates modifiying, restricting or simply removing past functionality etc.
+Additionally, many cloud software solutions and ecosystems store the users' data in the cloud,
+where they are subject to foreign laws and privacy concerns are intransparently handled by the companies.
+Should the company, for any reason, be unable or unwanting to continue servicing a customer,
+the data may be irrecoverably lost (or access prevented).
+
+However this lack of control over data access is not the only problem the application-centric approach induces:
+Another consequence is that interoperability between applications and data formats is hindered.
+Because applications are incentivised to keep customers, they make use of network effects to keep customers locked-in.
+As a result applications tend to accrete features rather then modularise and delegate to other software [P Chiusano].
+
+This leads to massively complex file formats,
+such as for example the .docx format commonly used for storing mostly
+textual data enriched with images and videos on occasion.
+The docx format is in fact an archive that can contain many virtual files internally,
+such as the images and videos referenced before.
+However this is completely unknown to the 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.
+
+In fact all of this is unnecessary, since the image had been stored in a compatible format on disk in the first place:
+The system was simply unaware of this because the word document had to be archived into a single file
+for ease of use by the word processor, and this single file is opaque to the system.
+
+Data rarely really fits the metaphora of files very well,
+and even when it does it is rarely exposed to the user that way:
+The 'Contacts' app on a mobile phone or laptop for example does not store each contacts's information
+in a separate 'file' (as the metaphora may have initially suggested),
+but rather keeps this database hidden away from the user.
+Consequently, access to the information contained in the database is only enabled through the contacts applications GUI.
+
+--
 
-The state of sof
 According to some researchers in the field of Human-Computer-Interaction, the state of computing is rather dire.
 
 It seems that a huge majority of daily computer users have silently accepted
@@ -11,12 +63,6 @@ and surrendered it to the relatively small group of 'programmers' curating their
 - Services are worse
 
 
-[Cragg 2016]
-D. Cragg coins the term "inert data" 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 and depend soley on online tools that require a stable network connection
-and a modern browser, and that could be modified, removed or otherwise negatively impacted at any moment.
-
 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,
diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
index a712d2a..eac77c6 100644
--- a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
+++ b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
@@ -4,10 +4,10 @@
 -- resolves to a value of type mmm/dom
 =>
   html = require 'mmm.dom'
-  import article, h1, h2, h3, p, div, a, sup, ol, li, span, code, pre, br from html
+  import article, h1, h2, h3, section, p, div, a, sup, ol, li, span, code, pre, br from html
   import moon from (require 'mmm.highlighting').languages
 
-  article with _this = {}
+  article with _this = style: { margin: 'auto', 'max-width': '750px' }
     append = (a) -> table.insert _this, a
 
     footnote, getnotes = do
@@ -32,214 +32,21 @@
     append h1 'mmmfs', style: { 'margin-bottom': 0 }
     append p "a file and operating system to live in", style: { 'margin-top': 0, 'padding-bottom': '0.2em', 'border-bottom': '1px solid black' }
 
-
-    append p "mmmfs tries to change all this. In mmmfs, files can contain other files and so the collage document
-      becomes a container for the collected images and texts just as a regular directory would. This way the individual
-      files remain accessible and can be modified whenever necessary, while the collage document can be edited to
-      change the order, sizes and spatial arrangement of it's content if this is wanted, for example."
-
-    append p "The mmmfs file-type system also allows storing types of information that have become impractical to use
-      with current filesystems simply because noone has cared to make suitable applications for them. It is not common
-      practice, for example, to store direct links to online content on the disk for example. In mmmfs, a link to a
-      picture can be stored wherever an actual picture is expected for example, the system will take care of retrieving
-      the real picture as necessary."
-
-    -- @TODO: motivation / outline problem + need
-    -- * applications don't let users *do* things (http://pchiusano.github.io/2013-05-22/future-of-software.html)
-    -- * applications are just (collections of) files - most users don't know this (anymore)
-    -- * users should know their system and how to move around in it
-    -- * filesystem trees are only *okay* for organizing information:
-    --   - users sooner or later choose something smarter because:
-    --  * filesystems work the same in every folder, even though the context can be very different
-    --  * appliances put their complex, structured data into opaque blocks
-    --    * the FS should be able to solve the structure issue
-    --    * the benefit is interoperability: edit the image of your report
-    --    * in image editor while the document editor automatically refreshes
-    -- * file formats dont mean much to users, they are meant for applications - let applications take care of converting them
-    -- * report.doc, report.pdf, report_orignal.pdf, report_old.doc, report2.doc....
-
-    append p do
-      fileder = footnote "fileder: file + folder. 'node', 'table' etc. are too general to be used all over."
-
-      -- @TODO: mention:
-      -- can store anything - text, an image, a link to a website or video,
-      -- a program and anything else you can think of.
-      "in mmmfs, directories, files and applications are all kind of the same thing, or something like that.
-      Listen, I don't really know yet either. The idea is that there is only one type of 'thing' -
-      a fileder", fileder, ". A fileder can store multiple variants and metadata of its content,
-      such as a markdown text and a rendered HTML version of the same document.
-      It could also store a script that transforms the markdown version into HTML and is executed on demand,
-      automatically."
-
-    append p "Fileders can also have other fileders as their children (just like directories do in a normal
-      filesystem). You can make a fileder view query these children and display them however you want.
-      A 'Pictures' fileder, for example, could contain a script within itself that renders all the picture files
-      you put into it as little previews and lets you click on them to view the full image."
-
-    append p "This means the 'Pictures' fileder can also have an alternate slideshow mode, with fullscreen view and
-      everything (some of this is built, check out the gallery example below), or one that displays geotagged images
-      on a world map, if you really want that.  Maybe you could build a music folder that contains links to youtube
-      videos, spotify tracks and just plain mp3 files, and the folder knows how to play them all.", br!, "
-      In this way fileders fulfil the purpose of 'Applications' too."
-
-    -- @TODO: BUT doesn't have to be only for one type of file:
-    -- @TODO: rework
-    -- making a multi-media collage representing your thoughts and mental organization of a topic
-    append p "A fileder is also responsible for how it's children are sorted, filtered and interacted with.
-      For example you should be able to create a fileder that is essentially a 'word document' equivalent: it can
-      contain images, websites, links and of course text as children and let you reorder, layout and edit them
-      whenever you open the fileder."
-
-    append p "Sounds cool, no? Here's some examples of things a fileder can be or embed:"
-
     -- render a preview block
-    preview = (child) ->
+    do_section = (child) ->
       -- get 'title' as 'text/plain' (error if no value or conversion possible)
-      title = child\gett 'title', 'text/plain'
+      title = (child\get 'title: text/plain') or child\gett 'name: alpha'
 
       -- get 'preview' as a DOM description (nil if no value or conversion possible)
-      content = child\get 'preview', 'mmm/dom'
+      content = (child\get 'preview: mmm/dom') or child\get 'mmm/dom'
 
-      div {
+      section {
         h3 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',
-        },
       }
 
-    append div for child in *@children
-      preview child
-
-    append h2 "details"
-    -- @TODO s/parts: dimensions, aspects?
-    -- @TODO: first mention both facets & children; then go into detail
-    -- @TODO: main content
-    append do
-      name = html.i 'name'
-      type = html.i 'type'
-
-      p "Fileders are made up of two main parts. The first is the list of ", (html.i 'facets'), ",
-      which are values identified by a ", name, " and ", type, ". These values are queried using strings like ",
-      (code 'title: text/plain'), " or ", (code 'mmm/dom'), ", which describe both the ", name,
-      " of a facet (", (moon '"title"'), " and ", (moon '""'), ", the unnamed/main facet) and the ", type,
-      " of a facet. Facet types can be something resembling a MIME-type or a more complex structure
-      (see ", (html.i "type chains"), " below). A fileder can have multiple facets of different types
-      set that share a ", name, ". In this case the overlapping facets are considered equivalent and the one
-      with the most appropriate ", type, " is selected, depending on the query.
-      The unnamed facet is considered a fileder's 'main content', i.e. what you are interested in when viewing it."
-
-    append p "The second part of a fileder is the list of it's children, which are fileders itself.
-      The children are stored in an ordered list and currently identified by their ", (code 'name: alpha'),
-      " facet for UI and navigation purposes only (not sure if this is a good idea tbh)."
-
-    append do
-      mmmdom = code ('mmm/dom'), footnote span (code 'mmm/dom'), " is a polymorphic content type;
-        on the server it is just an HTML string (like ", (code 'text/html'), "),
-        but on the client it is a JS DOM Element instance."
-
-      p "What you are viewing right now is the main facet of the root fileder.
-        The facet is queried as ", mmmdom, ", a website fragment (DOM node). This website fragment
-        is then added to the page in the main content area, where you are most likely reading it right now."
-
-      p "Anyway, this node is set up as a very generic sort of index thing and just lists its children-fileders' 
-        alongside this text part you are reading.", br!, "For each child it displays the ", (code 'title: text/plain'),
-        " and shows the ", (code 'preview: mmm/dom'), " facet (if set)."
-
-    append h3 "converts"
-    append p "So far I have always listed facets as they are being queried, but a main feature of mmmfs is
-      type conversion. This means that you generally ask for content in whichever format suits your application,
-      and rely on the type resolution mechanism to make that happen."
-
-    append pre moon [[
--- render a preview block
-preview = (title, content) -> div {
-  h3 title, style: { ... },
-  content or span '(no renderable content)', style: { ... },
-  style: { ... }
-}
-
-append div for child in *@children
--- 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'
-
-preview title, content
-    ]]
-
-    append p "Here the code that renders these previews. You can see it ", (html.i "asks"), " for the
-      facets ", (code 'title: text/plain'), ' and ', (code 'preview: mmm/dom'), "), but the values don't actually have to
-      be ", (html.i "defined"), " as these types.
-      For example, the markdown child below only provides ", (code 'preview'), " as ", (code 'text/markdown'), ":"
-
-    append pre moon [[
-Fileder {
-  'title: text/plain': "I'm not even five lines of markdown but i render myself!",
-  'preview: text/markdown': "See I have like
-
-  - a list of things
-  - (two things)
-
-  and some bold **text** and `code tags` with me.",
-}
-    ]]
-
-    append p "Then, globally, there are some conversion paths specified; such as one that maps from ",
-      (code 'text/markdown'), " to ", (code 'mmm/dom'), ":"
-
-    append pre moon [[
-{
-  inp: 'text/markdown',
-  out: 'mmm/dom',
-  transform: (md) ->
-    -- polymorphic client/serverside implementation here,
-    -- uses lua-discount on the server, marked.js on the client
-}
-    ]]
-
-    append h3 "type chains"
-    append p "In addition, a facet type can be encoded using multiple types in a ", (code 'type chain'), ".
-      For example the root node you are viewing currently is actually defined as ", (code 'fn -> mmm/dom'), ",
-      meaning it's value is a pre moon function returing a regular ", (code 'mmm/dom'), " value."
-
-    append p "Both value chains and 'sideways' converts are resolved using the same mechanism,
-      so this page is being rendered just using ", (moon "append root\\get 'mmm/dom'"), " as well.
-      The convert that resolves the moon type is defined as follows:"
-
-    append pre moon [[
-{
-  inp: 'fn -> (.+)',
-  out: '%1',
-  transform: (val, fileder) -> val fileder
-}
-    ]]
-
-    append p "The example with the image is curious as well. In mmmfs, you might want to save a link to an image,
-      without ever saving the actual image on your hard drive (or wherever the data may ever be stored - it is
-      quite transient currently). The image Fileder below has it's main (unnamed) value tagged as ",
-      (code 'URL -> image/png'), " - a png image, encoded as an URL. When accessed as ", (code 'image/png'), "
-      the URL should be resolved, and the binary data provided in it's place (yeah right - I haven't build that yet)."
-
-    append p "However, if a script is aware of URLs and knows a better way to handle them, then it can ask for and
-      use the URL directly instead.
-      This is what the image demo does in order to pass the URL to an ", (code 'img'), " tag's ", (code 'src'), " attribute:"
-
-    append pre moon [[
-Fileder {
-  'title: text/plain': "Hey I'm like a link to picture or smth",
-  'URL -> image/png': 'https://picsum.photos/200?random',
-  'preview: fn -> mmm/dom': =>
-    import img from require 'mmm.dom'
-    img src: @gett 'URL -> image/png' -- look for main content with 'URL to png' type
-}
-    ]]
+    for child in *@children
+      append child\gett 'mmm/dom'
+      -- do_section child
 
     append getnotes!