Merge branch 'tru-fs' into inspect-mode

16 files changed, 820 insertions, 862 deletions

diff --git a/root/articles/init.moon b/root/articles/init.moon
deleted file mode 100644
index 4cab81b..0000000
--- a/root/articles/init.moon
+++ /dev/null
@@ -1,27 +0,0 @@
-import div, h3, ul, li, a from require 'mmm.dom'
-import define_fileders from require 'mmm.mmmfs'
-Fileder = define_fileders ...
-require = relative ...
-
-Fileder {
-  'name: alpha': 'articles',
-  'title: text/plain': 'articles and papers',
-  'fn -> mmm/dom': (path) => div {
-      h3 @gett 'title: text/plain', style: { 'margin-bottom': '-.5em' },
-      ul for child in *@children
-        name = child\gett 'name: alpha'
-        desc = child\gett 'description: text/plain'
-        li {
-          a name, {
-            href: child.path,
-            onclick: (e) =>
-              e\preventDefault!
-              BROWSER\navigate child.path
-          },
-          ': ', desc
-        }
-    }
-
-  require '.mmmfs'
-  require '.realities'
-}
diff --git a/root/articles/mmmfs/description: text$plain b/root/articles/mmmfs/description: text$plain
new file mode 100644
index 0000000..1322f1d
--- /dev/null
+++ b/root/articles/mmmfs/description: text$plain
@@ -0,0 +1 @@
+a file, operating and content-management system to live in (powers this site)
diff --git a/root/articles/mmmfs/empty/title: text$plain b/root/articles/mmmfs/empty/title: text$plain
new file mode 100644
index 0000000..911f98b
--- /dev/null
+++ b/root/articles/mmmfs/empty/title: text$plain
@@ -0,0 +1 @@
+Hey I'm an almost empty Fileder.
diff --git a/root/articles/mmmfs/image/URL -> image$png b/root/articles/mmmfs/image/URL -> image$png
new file mode 100644
index 0000000..c586722
--- /dev/null
+++ b/root/articles/mmmfs/image/URL -> image$png
@@ -0,0 +1 @@
+https://picsum.photos/200?random
diff --git a/root/articles/mmmfs/image/preview: text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/image/preview: text$moonscript -> fn -> mmm$dom.moon
new file mode 100644
index 0000000..6c431d0
--- /dev/null
+++ b/root/articles/mmmfs/image/preview: text$moonscript -> fn -> mmm$dom.moon
@@ -0,0 +1,5 @@
+import img from require 'mmm.dom'
+
+-- look for main content with 'URL to png' type
+-- and wrap in an mmm/dom image tag
+=> img src: @gett 'URL -> image/png'
diff --git a/root/articles/mmmfs/image/title: text$plain b/root/articles/mmmfs/image/title: text$plain
new file mode 100644
index 0000000..60a556f
--- /dev/null
+++ b/root/articles/mmmfs/image/title: text$plain
@@ -0,0 +1 @@
+Hey I'm like a link to a picture or smth
diff --git a/root/articles/mmmfs/init.moon b/root/articles/mmmfs/init.moon
deleted file mode 100644
index 8227a70..0000000
--- a/root/articles/mmmfs/init.moon
+++ /dev/null
@@ -1,285 +0,0 @@
-import define_fileders from require 'mmm.mmmfs'
-Fileder = define_fileders ...
-require = relative ...
-
-Fileder {
-  'name: alpha': 'mmmfs',
-  'description: text/plain': 'a file, operating and content-management system to live in (powers this site)',
-
-  -- 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
-  'fn -> mmm/dom': () =>
-    html = require 'mmm.dom'
-    import article, h1, h2, h3, p, div, a, sup, ol, li, span, code, pre, br from html
-
-    moon = if MODE == 'SERVER'
-      (str) -> code (str\match '^ *(..-) *$'), class: 'hljs'
-    else
-      (str) ->
-        result = window.hljs\highlight 'moonscript', (str\match '^ *(..-) *$'), true
-        with code class: 'hljs'
-          .innerHTML = result.value
-
-    article with  _this = {}
-      append = (a) -> table.insert _this, a
-
-      footnote, getnotes = do
-        local *
-        notes = {}
-
-        id = (i) -> "footnote-#{i}"
-
-        footnote = (stuff) ->
-          i = #notes + 1
-          notes[i] = stuff
-          sup a "[#{i}]", style: { 'text-decoration': 'none' }, href: '#' .. id i
-
-        footnote, ->
-          args = for i, note in ipairs notes
-            li (span (tostring i), id: id i), ': ', note
-          notes = {}
-          table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' }
-          ol table.unpack args
-
-      append h1 'mmmfs', style: { 'margin-bottom': 0 }
-      -- @TODO: s/filesystem/a way of organizing files/g
-      append p "a file and operating system to live in", style: { 'margin-top': 0, 'margin-bottom': '1em' }
-
-      -- @TODO: motivation / outline problem + need
-      -- @TODO: quote http://pchiusano.github.io/2013-05-22/future-of-software.html on Applications
-
-      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) ->
-        -- 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 {
-          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 properties & 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 'properties'), ",
-        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 property (", (moon '"title"'), " and ", (moon '""'), ", the unnamed/main property) and the ", type,
-        " of a property. Property types can be something resembling a MIME-type or a more complex structure
-        (see ", (html.i "type chains"), " below). A fileder can have multiple properties of different types
-        set that share a ", name, ". In this case the overlapping properties are considered equivalent and the one
-        with the most appropriate ", type, " is selected, depending on the query.
-        The unnamed property 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'),
-        " property for UI and navigation purposes only (not sure if this is a good idea tbh)."
-
---      append do
---        github = footnote a 's-ol/mmm', href: 'https://github.com/s-ol/mmm/tree/master/app/mmmfs'
---          "Oh and also everything is on github and stuff", github,
---          " if you care about that."
-
-      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 property of the root fileder.
-          The property 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'), " property (if set)."
-
-      append h3 "converts"
-      append p "So far I have always listed properties 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
-        properties ", (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 property 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
-}
-      ]]
-
-      append getnotes!
-
-  'text/markdown': "this is a markdown version or something.
-
-There's no content here so switch back to the real one!
-(Assuming there is a switching UI by the time you are reading this, which I assume since you are reading this at all.
-If you are reading this in the source, then c'mon, just scroll past and give me a break.)
-
-(the switching UI has now been built.)"
-
-  Fileder {
-    'name: alpha': 'empty',
-    'title: text/plain': "Hey I'm an ad-hoc child with no content at all",
-  }
-
-  Fileder {
-    'name: alpha': 'image',
-    'title: text/plain': "Hey I'm like a link to picture or smth",
-
-    -- main content is image/png, to be interpreted by URL to access
-    'URL -> image/png': 'https://picsum.photos/200?random',
-
-    -- preview is a lua/moonscript function that neturns an mmm/dom value
-    '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
-  }
-
-  Fileder {
-    'name: alpha': 'markdown',
-    'title: text/plain': "I'm not even five lines of markdown but i render myself!",
-
-    -- preview can be rendered using global convert
-    'preview: text/markdown': "See I have like
-
-- a list of things
-- (two things)
-
-and some bold **text** and `code tags` with me.",
-  }
-
-  require '.gallery',
-}
diff --git a/root/articles/mmmfs/markdown/text$markdown.md b/root/articles/mmmfs/markdown/text$markdown.md
new file mode 100644
index 0000000..4b38ef2
--- /dev/null
+++ b/root/articles/mmmfs/markdown/text$markdown.md
@@ -0,0 +1,6 @@
+See I have like
+
+- a list of things
+- (two things)
+
+and some bold **text** and `code tags` with me.
diff --git a/root/articles/mmmfs/markdown/title: text$plain b/root/articles/mmmfs/markdown/title: text$plain
new file mode 100644
index 0000000..319068d
--- /dev/null
+++ b/root/articles/mmmfs/markdown/title: text$plain
@@ -0,0 +1 @@
+  I'm not even five lines of markdown but i render myself!
diff --git a/root/articles/mmmfs/text$markdown.md b/root/articles/mmmfs/text$markdown.md
new file mode 100644
index 0000000..1c1b4f9
--- /dev/null
+++ b/root/articles/mmmfs/text$markdown.md
@@ -0,0 +1,7 @@
+## this is a markdown version or something.
+
+There's no content here so switch back to the real one!
+(Assuming there is a switching UI by the time you are reading this, which I assume since you are reading this at all.
+If you are reading this in the source, then c'mon, just scroll past and give me a break.)
+
+(the switching UI has now been built.)
diff --git a/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
new file mode 100644
index 0000000..5d454a1
--- /dev/null
+++ b/root/articles/mmmfs/text$moonscript -> fn -> mmm$dom.moon
@@ -0,0 +1,235 @@
+-- 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, h2, h3, p, div, a, sup, ol, li, span, code, pre, br from html
+
+  moon = if MODE == 'SERVER'
+    (str) -> code (str\match '^ *(..-) *$'), class: 'hljs'
+  else
+    (str) ->
+      result = window.hljs\highlight 'moonscript', (str\match '^ *(..-) *$'), true
+      with code class: 'hljs'
+        .innerHTML = result.value
+
+  article with _this = {}
+    append = (a) -> table.insert _this, a
+
+    footnote, getnotes = do
+      local *
+      notes = {}
+
+      id = (i) -> "footnote-#{i}"
+
+      footnote = (stuff) ->
+        i = #notes + 1
+        notes[i] = stuff
+        sup a "[#{i}]", style: { 'text-decoration': 'none' }, href: '#' .. id i
+
+      footnote, ->
+        args = for i, note in ipairs notes
+          li (span (tostring i), id: id i), ': ', note
+        notes = {}
+        table.insert args, style: { 'list-style': 'none', 'font-size': '0.8em' }
+        ol table.unpack args
+
+    append h1 'mmmfs', style: { 'margin-bottom': 0 }
+    -- @TODO: s/filesystem/a way of organizing files/g
+    append p "a file and operating system to live in", style: { 'margin-top': 0, 'margin-bottom': '1em' }
+
+    -- @TODO: motivation / outline problem + need
+    -- @TODO: quote http://pchiusano.github.io/2013-05-22/future-of-software.html on Applications
+
+    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) ->
+      -- 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 {
+        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 properties & 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 'properties'), ",
+      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 property (", (moon '"title"'), " and ", (moon '""'), ", the unnamed/main property) and the ", type,
+      " of a property. Property types can be something resembling a MIME-type or a more complex structure
+      (see ", (html.i "type chains"), " below). A fileder can have multiple properties of different types
+      set that share a ", name, ". In this case the overlapping properties are considered equivalent and the one
+      with the most appropriate ", type, " is selected, depending on the query.
+      The unnamed property 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'),
+      " property for UI and navigation purposes only (not sure if this is a good idea tbh)."
+
+--      append do
+--        github = footnote a 's-ol/mmm', href: 'https://github.com/s-ol/mmm/tree/master/app/mmmfs'
+--          "Oh and also everything is on github and stuff", github,
+--          " if you care about that."
+
+    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 property of the root fileder.
+        The property 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'), " property (if set)."
+
+    append h3 "converts"
+    append p "So far I have always listed properties 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
+      properties ", (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 property 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
+}
+    ]]
+
+    append getnotes!
diff --git a/root/articles/realities.moon b/root/articles/realities.moon
deleted file mode 100644
index 1d8c9fa..0000000
--- a/root/articles/realities.moon
+++ /dev/null
@@ -1,550 +0,0 @@
-import define_fileders from require 'mmm.mmmfs'
-Fileder = define_fileders ...
-
-Fileder {
-  'name: alpha': 'realities'
-  'description: text/plain': 'exploring the nesting relationships of virtual and other realities'
-  'fn -> mmm/component': =>
-    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=\"application/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/realities/description: text$plain b/root/articles/realities/description: text$plain
new file mode 100644
index 0000000..c7a0891
--- /dev/null
+++ b/root/articles/realities/description: text$plain
@@ -0,0 +1 @@
+exploring the nesting relationships of virtual and other realities
diff --git a/root/articles/realities/text$moonscript -> mmm$dom.moon b/root/articles/realities/text$moonscript -> mmm$dom.moon
new file mode 100644
index 0000000..7689dbb
--- /dev/null
+++ b/root/articles/realities/text$moonscript -> mmm$dom.moon
@@ -0,0 +1,542 @@
+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=\"application/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 b/root/articles/text$moonscript -> fn -> mmm$dom
new file mode 100644
index 0000000..1c04309
--- /dev/null
+++ b/root/articles/text$moonscript -> fn -> mmm$dom
@@ -0,0 +1,18 @@
+import div, h3, ul, li, a from require 'mmm.dom'
+
+=>
+  div {
+    h3 @gett 'title: text/plain', style: { 'margin-bottom': '-.5em' },
+    ul for child in *@children
+      name = child\gett 'name: alpha'
+      desc = child\gett 'description: text/plain'
+      li {
+        a name, {
+          href: child.path,
+          onclick: (e) =>
+            e\preventDefault!
+            BROWSER\navigate child.path
+        },
+        ': ', desc
+      }
+  }
diff --git a/root/articles/title: text$plain b/root/articles/title: text$plain
new file mode 100644
index 0000000..c45a444
--- /dev/null
+++ b/root/articles/title: text$plain
@@ -0,0 +1 @@
+articles and papers