adds creation of install dir creation for linux binary

.docs.old/Makefile

@@ -1,44 +0,0 @@
-.PHONY: article website preview
-ARTICLE := Zenroom_Cryptolang_Whitepaper
-DEST := pub
-
-all: api website
-
-# api output is website/docs/lua
-api:
-	make -C ldoc
-
-# output is website/site
-# download js from our CI
-# import wiki pages
-# import changelog
-website:
-	@if ! [ -r website/docs/js/zenroom.js -o -r website/docs/js/zenroom.wasm ]; then curl https://sdk.dyne.org:4443/view/zenroom/job/zenroom-web/lastSuccessfulBuild/artifact/build/web/zenroom.wasm https://sdk.dyne.org:4443/view/zenroom/job/zenroom-web/lastSuccessfulBuild/artifact/build/web/zenroom.js https://sdk.dyne.org:4443/view/zenroom/job/zenroom-web/lastSuccessfulBuild/artifact/build/web/zenroom.data -o website/docs/js/zenroom.wasm -o website/docs/js/zenroom.js -o website/docs/js/zenroom.data; fi
-	@mkdir -p website/docs/encrypt && cp -v website/docs/js/zenroom.data website/docs/encrypt/
-	@mkdir -p website/docs/wiki
-	@cp -v wiki/Build.md website/docs/wiki/how-to-build.md
-	@cp -v wiki/Execute.md website/docs/wiki/how-to-exec.md
-	@cp -v wiki/Embed.md website/docs/wiki/how-to-embed.md
-	@cp -v ../ChangeLog.md website/docs/changelog.md
-	@cp -v zencode_diagram.png website/docs/img
-	@cp -v ../test/zencode_coconut/*.zen website/docs/examples/
-	@cp -v ../test/zencode_simple/*.zen website/docs/examples/
-	@cp -v ../test/zencode_simple/*.keys website/docs/examples/
-	@cp -v ../test/zencode_simple/*.data website/docs/examples/
-	@cp -v ../examples/*.keys ../examples/*.data ../examples/*.lua website/docs/examples/
-	@cd website && mkdocs build
-
-map:
-	./parse_zencode.sh | json_pp > zencode_utterances.json
-
-preview:
-	cd website && ./mkdocs-dyne-theme/.preview
-
-deploy: api website
-	cd website && ./mkdocs-dyne-theme/.deploy
-
-clean:
-	@rm -rf website/docs/lua
-	@rm -rf website/docs/wiki
-	@rm -rf website/site
-	@echo "Zenroom website cleaned up"

.docs.old/README.txt

@@ -1,10 +0,0 @@
-To build do: make (GNU make)
-
-requires: python3, lua, ldoc, zsh, json2yaml, mermaid-cli (mmdc)
-
-To preview do: make preview
-
-To list Zencode utterances from actual code: make map
-
-To deploy on github pages: make deploy (needs ssh key)
-

.docs.old/Zencode_paper-Feb2020/Makefile

@@ -1,9 +0,0 @@
-
-all:
-	latex Roio_Zencode
-	bibtex Roio_Zencode
-	latex Roio_Zencode
-	pdflatex Roio_Zencode
-
-clean:
-	rm -f *.dvi *.blg *.bbl *.aux *.log

.docs.old/Zencode_paper-Feb2020/Roio_Zencode.bib

@@ -1,90 +0,0 @@
-
-@book{sassen1996a,
-  title = {Losing {{Control}}? {{Sovereignty}} in an {{Age}} of {{Globalization}}},
-  publisher = {{Columbia University Press}},
-  author = {Sassen, Saskia},
-  year = {1996}
-}
-
-@article{monico2014,
-  title = {Premesse per Una Costituzione Ibrida.: La Macchina, La Bambina Automatica e Il Bosco},
-  journal = {Aut/Aut, La condizione postumana},
-  author = {Monico, Francesco},
-  year = {2014},
-  publisher = {{Il Saggiatore}}
-}
-
-@article{pelizza2017a,
-  title = {Mining {{Governance Mechanisms}}. {{Innovation}} Policy, Practice and Theory Facing Algorithmic Decision-Making},
-  journal = {Handbook of Cyber-Development, Cyber-Democracy, and Cyber-Defense},
-  author = {Pelizza, A. and Kuhlmann, S.},
-  year = {2017},
-  publisher = {{Springer, Berlin}}
-}
-
-@article{ascott2004,
-  title = {Planetary {{Technoetics}}: {{Art}}, {{Technology}} and {{Consciousness}}},
-  volume = {37},
-  issn = {1530-9282},
-  number = {2},
-  journal = {Leonardo},
-  author = {Ascott, Roy},
-  month = apr,
-  year = {2004},
-  pages = {111--116},
-  publisher = {{MIT Press - Journals}}
-}
-
-@article{diakopoulos2016a,
-  title = {Accountability in Algorithmic Decision Making},
-  volume = {59},
-  issn = {0001-0782},
-  number = {2},
-  journal = {Commun. ACM},
-  author = {Diakopoulos, Nicholas},
-  month = jan,
-  year = {2016},
-  pages = {56--62},
-  publisher = {{Association for Computing Machinery (ACM)}}
-}
-
-@book{nevejan2007,
-  title = {Presence and the {{Design}} of {{Trust}}},
-  author = {Nevejan, Caroline Irma Maria and others},
-  year = {2007}
-}
-
-
-@article{DBLP:conf/secdev/MomotBHP16,
-  title = {The {{Seven Turrets}} of {{Babel}}: {{A Taxonomy}} of {{LangSec Errors}} and {{How}} to {{Expunge Them}}},
-  booktitle = {{{IEEE Cybersecurity Development}}, {{SecDev}} 2016, {{Boston}}, {{MA}}, {{USA}}, {{November}} 3-4, 2016},
-  doi = {10.1109/SecDev.2016.019},
-  author = {Momot, Falcon and Bratus, Sergey and Hallberg, Sven M. and Patterson, Meredith L.},
-  year = {2016},
-  pages = {45-52},
-  biburl = {http://dblp.org/rec/bib/conf/secdev/MomotBHP16},
-  bibsource = {dblp computer science bibliography, http://dblp.org}
-}
-
-
-
-@article{freeman2013exploit,
-  title = {Exploit \& {{Fix Android \"Master Key}}"; {{Android Bug Superior}} to {{Master Key}}; {{Yet Another Android Master Key Bug}}},
-  author = {Freeman, Jay},
-  year = {2013}
-}
-
-
-@article{costin2017lua,
-  title = {Lua Code: Security Overview and Practical Approaches to Static Analysis},
-  author = {Costin, Andrei},
-  year = {2017}
-}
-
-@book{wynne2012,
-  title = {The {{Cucumber Book}}: {{Behavior}}-{{Driven Development}} for {{Testers}} and {{Developers}}},
-  author = {Wynne, A},
-  year = {2012},
-  organization = {{The Pragmatic Bookshelf}}
-}
-

.docs.old/Zencode_paper-Feb2020/Roio_Zencode.tex

@@ -1,506 +0,0 @@
-%%%%%%%%%%%%%%%%%%%% author.tex %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-% sample root file for your "contribution" to a proceedings volume
-%
-% Use this file as a template for your own input.
-%
-%%%%%%%%%%%%%%%% Springer %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-
-\documentclass{svproc}
-%
-% RECOMMENDED %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-%
-
-% to typeset URLs, URIs, and DOIs
-\usepackage{url}
-\usepackage{csquotes}
-\usepackage{cite}
-\def\UrlFont{\rmfamily}
-
-\begin{document}
-\mainmatter              % start of a contribution
-%
-\title{Zencode DSL: human language smart contracts}
-%
-\titlerunning{Zencode}
-% abbreviated title (for running head)
-%                                     also used for the TOC unless
-%                                     \toctitle is used
-%
-\author{Denis Roio\inst{1}}
-%
-\authorrunning{Denis Roio} % abbreviated author list (for running head)
-%
-%%%% list of authors for the TOC (use if author list has to be modified)
-\tocauthor{Denis Roio}
-%
-\institute{Dyne.org foundation, Amsterdam,\\
-\email{jaromil@dyne.org},\\ WWW home page:
-\texttt{https://dyne.org}}
-
-\maketitle              % typeset the title of the contribution
-
-\begin{abstract}
-% 70 to 150 words
-
-  This paper presents a theoretical framework and a software solution
-  to facilitate technological sovereignty and data commons management.
-
-  The goal is to improve people's awareness of how their data is
-  processed by algorithms, as well facilitate developers to write
-  applications that follow privacy by design principles.
-
-  The main requirement is that of distributed computing: Zencode must
-  be capable of processing un/trusted code to execute advanced
-  cryptographic functions, to be with any blockchain implementation as
-  an interpreter of smart contracts.
-
-  Zencode is language to write portable scripts executed inside an
-  isolated environment (the Zenroom VM) that can be ported to any
-  platform, embedded in any language and made inter-operable with any
-  blockchain.
-
-  The Zencode implementation is inspired by research on
-  language-theoretical security, adopts Lua as direct-syntax parser
-  to build a non-Turing complete domain-specific language (DSL)
-  enforcing coarse-grained computations and recognition of data before
-  processing.
-
-% We would like to encourage you to list your keywords within
-% the abstract section using the \keywords{...} command.
-\keywords{blockchain, language, smart-contracts, dsl, langsec}
-\end{abstract}
-%
-\section{Introduction}
-%
-Since DECODE project's inception, developing the Zencode language and
-releasing the Zenroom VM interpreter has been an extremely motivating
-ambition, as it concretely provides a solution for the
-techno-political implications illustrated by the AlgoSov.org
-observatory and researched in my Ph.D thesis on "Algorithmic
-Sovereignty".
-
-I begin this paper illustrating the techno-political motivations for
-the development of Zenroom in the context of the DECODE project, an
-European H2020 grant (nr. 732546) coordinated by colleague
-Dr. Francesca Bria as its principal investigator.
-
-I'll then proceed sharing my considerations on the state of the art of
-language design and security of execution in trust-less
-environments. The safe execution of untrusted code is required by most
-distributed ledger technologies (also commonly referred to as
-blockchain); it is as well a desirable feature for the reliability of
-cryptographic data manipulation for general use (certification,
-authentication and more advanced uses contemplated in Zenroom).
-
-At last this paper consists a brief introduction of the Zencode DSL
-design and points to the Zenroom VM interpreter implementation to
-execute safely and efficiently simplified smart-rules describing
-cryptographic operation and data transformations using human readable
-language.
-
-%
-\subsection{For the awareness of algorithms}
-%
-
-The goal of the Zenroom VM and the Zencode language is ultimately that
-of realizing a simple, non-technical, human-readable language for
-smart-rules that are actually executed in a verifiable and provable
-manner within a controlled execution environment.
-
-To articulate the importance of this quest and the relevance of the
-results presented, which I believe to be unique in the landscape of
-blockchain smart-contract languages, is important to remind us of the
-condition in which most people find themselves when participating in
-the regime of truth that is built by algorithms.
-
-As the demand and production of well-connected vessels for the digital
-dimension has boomed, machine-readable code today functions as a
-literature informing the architecture in which human interactions
-happens and decisions are taken. The "telematic condition" is realized
-by an integrated data-work continuously engaging the observer as a
-participant. Such a "Gesamtdatenwerk" \cite{ascott2004} may seem
-an abstract architecture, yet it can be deeply binding under legal,
-ethical and moral circumstances.
-
-The comprehension of algorithms, the awareness of the way decisions
-are formulated, the implications of their execution, is not just a
-technical condition, but a political one, for which access to
-information cannot be just considered a feature, but a civil right
-\cite{pelizza2017a}. It is important to understand this in
-relation to the "classical" application of algorithms executed in a
-centralized manner, but even more in relation to distributed computing
-scenarios posed by blockchain technologies, which theorize a future in
-which rules and contracts are executed irrevocably and without
-requiring any human agency.
-
-The legal implications with regards to standing rights and liabilities
-are out of the scope here, while the focus is on ways humans, even
-when lacking technical literacy, can be made aware of what an
-algorithm does. Is it possible to establish the ground for a shared
-language that informs digital architects about their choices and
-inhabitants about the digital territory? Going past assumptions about
-the strong role algorithms have in governance and accountability
-\cite{diakopoulos2016a}, how can we inform digital citizens about
-their condition?  When describing the virtualization of economic
-activity in the global context, Saskia Sassen describes the need we
-are observing as that of an analytical vocabulary:
-
-\blockquote{The third component in the new geography of power is the
-  growing importance of electronic space. There is much to be said on
-  this issue. Here, I can isolate one particular matter: the
-  distinctive challenge that the virtualization of a growing number of
-  economic activities presents not only to the existing state
-  regulatory apparatus, but also to private-sector institutions
-  increasingly dependent on the new technologies. Taken to its
-  extreme, this may signal a control crisis in the making, one for
-  which we lack an analytical vocabulary. \cite{sassen1996a} }
-
-The analysis of legal texts and regulations here shifts into an
-entirely new domain; it has to refer to conditions that only
-algorithms can help build or destroy. Thus, referring to this
-theoretical framework, the research and development of a free and open
-source language that is intelligible to humans becomes of crucial
-importance and, from an ethical standing point, DECODE as many other
-projects in the same space cannot be exempted from addressing it.
-
-When we consider algorithms as contracts regulating relationships
-(between humans, between humans and nature and, nowadays more
-increasingly, between different contexts of nature itself) then we
-should adopt a representation that is close to how the human mind
-works and that is directly connected to the language adopted. Since
-algorithms are the systemic product of complex relationships between
-contracts and relevant choices made by standing actors
-\cite{monico2014}, the ability to verify which algorithms are in place
-for a certain result to be visualized becomes very important and
-should be embedded in every application: to understand and communicate
-what algorithms and to describe and experiment their repercussions on
-reality.
-
-For a deeper exploration of the techno-political implications raised
-by this document please refer to DECODE's blog-post on Algorithmic
-Sovereignty which also contains a series of historical examples of
-critical situations that help to understand the urgency we are facing.
-
-DECODE goes in the direction of following a technical and scienifical
-restearch path and call for a new form of municipal rationality that
-contemplates technological sovereignty, citizen participation and
-ownership.
-
-This narrative is echoing through world's biggest municipal
-administrations as we speak: a stance against the colonization of
-dense settlements by complex technical systems that are far from the
-reach of citizen's political control. The "Manifesto in favour of
-technological sovereignty and digital rights for cities" is now being
-considered as a standard guideline for ethics in governance by many
-cities of the world.
-
-This whitepaper is then also a call for action to fellow programmers
-out there: we need to write code that is understandable by other
-humans and by animals, plants, all the living world we inoculate with
-our sensors and manipulate through automation. The term "smart" should
-really mean understandable, accessible, open and trustworthy
-\cite{nevejan2007}; then smart-contracts should be expressed in a
-language that most humans can understand. Good code is not what is
-skillfully crafted or most efficient, but what can be read by others,
-studied, changed, adapted.
-
-Let's adopt intuitive name-spaces that can be easily matched with
-reality or simple metaphors, let's make sure that what we write is
-close to what we mean. Common understanding of algorithms is
-necessary, because their governance is an inter-disciplinary exercise
-and cannot be left in the hands of a technical elite.
-
-%
-\section{Language Security}
-%
-
-This section will establish the underpinnings of the Zencode language,
-starting from its most theoretical assumptions, to conclude with
-specific requirements. In order to do so, I will concentrate on the
-recent corpus developed by research on "language-theoretic security"
-(LangSec). Here below we include a brief explanation condensed from
-the information material of the LangSec.org project hosted at
-IEEE. This research benefits from being informed by the experience of
-the exploit development community: exploitation is a practical
-exploration of the space of unanticipated state, its prevention or
-containment.
-
-\blockquote{In a nutshell [...] LangSec is the idea that many security
-  issues can be avoided by applying a standard process to input
-  processing and protocol design: the acceptable input to a program
-  should be well-defined (i.e., via a grammar), as simple as possible
-  (on the Chomsky scale of syntactic complexity), and fully validated
-  before use (by a dedicated parser of appropriate but not excessive
-  power in the Chomsky hierarchy of
-  automata). \cite{DBLP:conf/secdev/MomotBHP16} }
-
-LangSec is a design and programming philosophy that focuses on
-formally correct and verifiable input handling throughout all phases
-of the software development lifecycle. In doing so, it offers a
-practical method of assurance of software free from broad and
-currently dominant classes of bugs and vulnerabilities related to
-incorrect parsing and interpretation of messages between software
-components (packets, protocol messages, file formats, function
-parameters, etc.).
-
-This design and programming paradigm begins with a description of
-valid inputs to a program as a formal language (such as a
-grammar). The purpose of such a disciplined specification is to
-cleanly separate the input-handling code and processing code. A
-LangSec-compliant design properly transforms input-handling code into
-a recognizer for the input language; this recognizer rejects
-non-conforming inputs and transforms conforming inputs to structured
-data (such as an object or a tree structure, ready for type- or
-value-based pattern matching). The processing code can then access the
-structured data (but not the raw inputs or parsers temporary data
-artifacts) under a set of assumptions regarding the accepted inputs
-that are enforced by the recognizer.
-
-This approach leads to several advantages:
-\begin{enumerate}
-\item produce verifiable recognizers, free of typical classes of ad-hoc parsing bugs
-\item produce verifiable, composable implementations of distributed systems that ensure equivalent parsing of messages by all components and eliminate exploitable differences in message interpretation by the elements of a distributed system
-\item mitigate the common risks of ungoverned development by
-  explicitly exposing the processing dependencies on the parsed input.
-\end{enumerate}
-
-As a design philosophy, LangSec focuses on a particular choice of
-verification trade-offs: namely, correctness and computational
-equivalence of input processors.
-
-\subsection{Ad-hoc notions of input validity}
-
-Formal verification of input handlers is impossible without formal
-language-theoretic specification of their inputs, whether these inputs
-are packets, messages, protocol units, or file formats. Therefore,
-design of an input-handling program must start with such a formal
-specification.  Once specified, the input language should be reduced
-to the least complex class requiring the least computational power to
-recognize. Considering the tendency of hand-coded programs to admit
-extra state and computation paths, computational power susceptible to
-crafted inputs should be minimized whenever possible. Whenever the
-input language is allowed to achieve Turing-complete power, input
-validation becomes undecidable; such situations should be avoided.
-
-\subsection{Parser differentials}
-
-Mutual misinterpretation between system components. Verifiable
-composition is impossible without the means of establishing parsing
-equivalence between different components of a distributed
-system. Different interpretation of messages or data streams by
-components breaks any assumptions that components adhere to a shared
-specification and so introduces inconsistent state and unanticipated
-computation \cite{DBLP:conf/secdev/MomotBHP16}. In addition, it breaks
-any security schemes in which equivalent parsing of messages is a
-formal requirement, such as the contents of a certificate or of a
-signed message being interpreted identically, for example a X.509
-Certificate Signing Request as seen by a Certificate Authority vs. the
-signed certificates as seen by the clients or signed app package
-contents as seen by the signature verifier versus the same content as
-seen by the installer (as in the recent Android Master Key bug
-\cite{freeman2013exploit}. An input language specification stronger
-than deterministic context-free makes the problem of establishing
-parser equivalence undecidable. Such input languages and systems whose
-trustworthiness is predicated on the component parser equivalence
-should be avoided. Logical programming using Prolog for instance, or
-languages like Scheme derived from LISP, or OCaml or Erlang would
-match then our requirements, but they aren't as usable as desired. As
-a partial solution to this problem the Zencode language parser (and
-all its components and eventually linked shared libraries) should be
-small, portable, self-contained and clearly versioned with a
-verifiable hash.
-
-\subsection{Mixing of input recognition and processing}
-
-Mixing of basic input validation ("sanity checks") and logically
-subsequent processing steps that belong only after the integrity of
-the entire message has been established makes validation hard or
-impossible. As a practical consequence, unanticipated reachable state
-exposed by such premature optimization explodes. This explosion makes
-principled analysis of the possible computation paths
-untenable. LangSec-style separation of the recognizer and processor
-code creates a natural partitioning that allows for simpler
-specification-based verification and management of code. In such
-designs, effective elimination of exploit-enabling implicit data flows
-can be achieved by simple systems memory isolation primitives.
-
-\subsection{Language specification drift}
-
-A common practice encouraged by rapid software development is the
-unconstrained addition of new features to software components and
-their corresponding reflection in input language
-specifications. Expressing complex ideas in hastily written code is a
-hallmark of such development practices. In essence, adding new input
-feature requirements to an already underspecified input language
-compounds the explosion of state and computational paths.
-
-%
-\section{The Zencode Language}
-%
-
-This section describes the salient implementation details of the
-Zencode DSL, the smart-rule language for DECODE, tailored on its
-use-cases and based on the Zenroom controlled execution environment
-(VM).
-
-This section consists of three parts, each one explaining:
-\begin{itemize}
-\item the language model inherited from BDD / Cucumber
-\item the data validation model based on schema validation
-\item the memory model for safe computation
-\end{itemize}
-
-\subsection{Syntax-Directed Translation}
-
-Lua is an interpreted, cross-platform, embeddable, performant and
-low-footprint language. Lua's popularity is on the rise in the last
-couple of years \cite{costin2017lua}. Simple design and efficient
-usage of resources combined with its performance make it attractive
-for production web applications, even to big organizations such as
-Wikipedia, CloudFlare and GitHub. In addition to this, Lua is one of
-the preferred choices for programming embedded and IoT devices. This
-context allows an assumption of a large and growing Lua codebase yet
-to be assessed. This growing Lua codebase could be potentially driving
-production servers and an extremely large number of devices, some
-perhaps with mission-critical function for example in automotive or
-home-automation domains.
-
-Lua stability has been extensively tested through a number of public
-applications including the adoption by the gaming industry for
-untrusted language processing in "World of Warcraft" scripting. It is
-ideal for implementing an external DSL using C99 as a host language.
-
-\subsection{Behaviour Driven Development}
-
-In Behaviour Driven Development (BDD), the important role of software
-integration and unit tests is extended to serve both the purposes of
-designing the human-machine interaction flow (user journey in UX
-terms) and of laying down a common ground for interaction between
-designers and stakeholders. In this Agile software development
-methodology the software testing suite is based on natural language
-units that grant a common understanding for all participants and
-observers.
-
-I'm very grateful to my friend and colleague Puria Nafisi Azizi for
-this brilliant intuition: adopting BDD for developing Zencode and
-implement a human-friendly language that does not depends on the
-underlying cryptographic implementation, allowing to share simple
-knowledge on how to include crypto scenarios components in different
-applications as well how to update them..
-
-For our implementation of Zencode, definable as a dialect of BDD, the
-first step has been that of mapping series of interconnected cascading
-sentences of operations to the actual source code describing their
-execution to the Zenroom VM; this implementation has to be done
-manually with knowledge of Lua scripting and of the higher level
-functions that grant communication with the Zenroom VM.
-
-Zencode then becomes a "textual frontend" that is easy to embed in
-graphical applications and whose purpose is to wire expressions and
-executions by means of utterances expressed in human language.
-
-Referring to the Cucumber implementation of BDD, arguably the most
-popular in use by the industry to day and factual standard
-\cite{wynne2012}, the grammar of utterances is very simple and
-definable as a "cascading" flow indeed, since the fixed sequence of
-lines can follow only one fixed order:
-
-\enquote{Given .. and* .. When .. and* .. Then print ..}
-
-This sequence is fixed and in simple terms consists of:
-
-\begin{enumerate}
-\item an read-only initialisation of states "Given (and)"
-\item an read-write scenario based transformation of states "When (and)"
-\item a write-only publishing phase of final states "Then (and)".
-\end{enumerate}
-
-The Zenroom implementation simply defines fixed sequences of strings, mapping them to cryptographic functions, allowing the presence of variables that are expected to be arguments for the functions. These variables can then be changed by participants (frontend developers or application operators) as they are marked by inclusion a repeating sequence of two adjacent single quotes ('  ').
-
-The underlying parser is based on a finite state machine controlling
-the change of states and capable of executing security operations:
-data validation checks and memory wiping.
-
-Zencode acts upon a positive, unique and non-flexible match of the
-first word of each new line, checks it complies with the current
-parser machine state and then proceeds parsing the whole phrase minus
-the variables, saving a pointer to the corresponding function if found
-along with the contents of variables if any.
-
-As a result, one (or more, synonyms are supported) non-repeating line
-of parsed Zencode utterance is easy to translate across different
-spoken languages and corresponds to a declared function allowing the
-execution of Lua commands inside the Zenroom VM.
-
-The current implementation addresses specific scenarios useful to the
-pilots in DECODE, while contemplating future extensions. Scenarios
-available:
-
-\begin{itemize}
-\item Simple symmetric transformations of cipher-text by means of HASH and KDF transformations
-\item Diffie-Hellman asymmetric key encryption (AES-GCM)
-\item Zero-Knowledge proof and blind-signing of credentials for unlinkable selective attribute revelations
-\end{itemize}
-
-Documentation, examples and an interactive online webassembly demo
-are all available online on the website dev.zenroom.org.
-
-\subsection{Declarative Schema Validation}
-
-In order to make the processing of Zencode more robust, all data used
-as input and output for its computations is validated according to
-predefined schemas. This makes the Zencode DSL a declarative language
-in which data recognition is operated before processing.
-
-The data schemas are added on a per-usecase basis: they refer to
-specific cryptographic implementations as they are added in
-Zencode. Careful evaluation regarding their addition is made to
-realize if old schemas can be extended to include new requirements.
-
-Schemas are expressed in a simple format using Lua scripting syntax
-and consist of:
-\begin{itemize}
-\item an importer from JSON data structures containing hex or base64 encoded complex data types
-\item an exporter of complex structured data types to big numbers encoded using hex or base64 and other common encoding formats
-\end{itemize}
-
-Every data structure processed in Zencode enters as a JSON or CBOR
-string input (IN), it is decoded and parsed, then checked for
-cryptographic validity (for instance checking point-on-curve) and
-stored in its validated data type (ACK) and at last is encoded back
-from defined data types to JSON or CBOR output string using encoding
-methods (OUT).
-
-This creates three cascading sections in the HEAP of Zenroom and each
-section corresponds to the language steps in Zencode:
-
-\begin{enumerate}
-\item Given (IN)
-\item When (ACK)
-\item Then (OUT)
-\end{enumerate}
-
-Providing a rigid structure to context-specific (or pilot-specific)
-implementations of Zencode scenarios: the parser should always operate
-data recognition in the Given/IN phase, operate transformations in the
-When/ACK phase and finally render output in the Then/OUT phase. This
-flow is locked with recurring HEAP checks to insure that different
-areas of memory are not accessed by the wrong section of Zencode, as
-well thatn the When/ACK phase is operated only on decoded memory and
-verified schemas.
-
-\section{Conclusion}
-
-This brief paper serves as an introduction to the motivation and
-design choices behind the Zencode DSL and, only partially, to the
-Zenroom VM. The production-ready implementation of Zencode should be
-seen as complementary to this paper and is publicly available under
-Affero General Public License v3 from the website Zenroom.org.
-
-% ---- Bibliography ----
-%
-\bibliography{Roio_Zencode}{}
-\bibliographystyle{plain}
-\end{document}

.docs.old/Zencode_paper-Feb2020/aliascnt.sty

@@ -1,88 +0,0 @@
-%%
-%% This is file `aliascnt.sty',
-%% generated with the docstrip utility.
-%%
-%% The original source files were:
-%%
-%% aliascnt.dtx  (with options: `package')
-%% 
-%% This is a generated file.
-%% 
-%% Project: aliascnt
-%% Version: 2009/09/08 v1.3
-%% 
-%% Copyright (C) 2006, 2009 by
-%%    Heiko Oberdiek <heiko.oberdiek at googlemail.com>
-%% 
-%% This work may be distributed and/or modified under the
-%% conditions of the LaTeX Project Public License, either
-%% version 1.3c of this license or (at your option) any later
-%% version. This version of this license is in
-%%    http://www.latex-project.org/lppl/lppl-1-3c.txt
-%% and the latest version of this license is in
-%%    http://www.latex-project.org/lppl.txt
-%% and version 1.3 or later is part of all distributions of
-%% LaTeX version 2005/12/01 or later.
-%% 
-%% This work has the LPPL maintenance status "maintained".
-%% 
-%% This Current Maintainer of this work is Heiko Oberdiek.
-%% 
-%% This work consists of the main source file aliascnt.dtx
-%% and the derived files
-%%    aliascnt.sty, aliascnt.pdf, aliascnt.ins, aliascnt.drv.
-%% 
-\NeedsTeXFormat{LaTeX2e}
-\ProvidesPackage{aliascnt}%
-  [2009/09/08 v1.3 Alias counter (HO)]%
-\newcommand*{\newaliascnt}[2]{%
-  \begingroup
-    \def\AC@glet##1{%
-      \global\expandafter\let\csname##1#1\expandafter\endcsname
-        \csname##1#2\endcsname
-    }%
-    \@ifundefined{c@#2}{%
-      \@nocounterr{#2}%
-    }{%
-      \expandafter\@ifdefinable\csname c@#1\endcsname{%
-        \AC@glet{c@}%
-        \AC@glet{the}%
-        \AC@glet{theH}%
-        \AC@glet{p@}%
-        \expandafter\gdef\csname AC@cnt@#1\endcsname{#2}%
-        \expandafter\gdef\csname cl@#1\expandafter\endcsname
-        \expandafter{\csname cl@#2\endcsname}%
-      }%
-    }%
-  \endgroup
-}
-\newcommand*{\aliascntresetthe}[1]{%
-  \@ifundefined{AC@cnt@#1}{%
-    \PackageError{aliascnt}{%
-      `#1' is not an alias counter%
-    }\@ehc
-  }{%
-    \expandafter\let\csname the#1\expandafter\endcsname
-      \csname the\csname AC@cnt@#1\endcsname\endcsname
-  }%
-}
-\newcommand*{\AC@findrootcnt}[1]{%
-  \@ifundefined{AC@cnt@#1}{%
-    #1%
-  }{%
-    \expandafter\AC@findrootcnt\csname AC@cnt@#1\endcsname
-  }%
-}
-\def\AC@patch#1{%
-  \expandafter\let\csname AC@org@#1reset\expandafter\endcsname
-    \csname @#1reset\endcsname
-  \expandafter\def\csname @#1reset\endcsname##1##2{%
-    \csname AC@org@#1reset\endcsname{##1}{\AC@findrootcnt{##2}}%
-  }%
-}
-\RequirePackage{remreset}
-\AC@patch{addto}
-\AC@patch{removefrom}
-\endinput
-%%
-%% End of file `aliascnt.sty'.

.docs.old/Zencode_paper-Feb2020/remreset.sty

@@ -1,39 +0,0 @@
-
-% remreset package
-%%%%%%%%%%%%%%%%%%
-
-% Copyright 1997 David carlisle
-% This file may be distributed under the terms of the LPPL.
-% See 00readme.txt for details.
-
-% 1997/09/28  David Carlisle
-
-% LaTeX includes a command \@addtoreset that is used to declare that
-% a counter should be reset every time a second counter is incremented.
-
-% For example the book class has a line
-% \@addtoreset{footnote}{chapter}
-% So that the footnote counter is reset each chapter.
-
-% If you wish to bas a new class on book, but without this counter
-% being reset, then standard LaTeX gives no simple mechanism to do
-% this.
-
-% This package defines |\@removefromreset| which just undoes the effect
-% of \@addtorest. So for example a class file may be defined by
-
-% \LoadClass{book}
-% \@removefromreset{footnote}{chapter}
-
-
-\def\@removefromreset#1#2{{%
-  \expandafter\let\csname c@#1\endcsname\@removefromreset
-  \def\@elt##1{%
-    \expandafter\ifx\csname c@##1\endcsname\@removefromreset
-    \else
-      \noexpand\@elt{##1}%
-    \fi}%
-  \expandafter\xdef\csname cl@#2\endcsname{%
-    \csname cl@#2\endcsname}}}
-
-

.docs.old/article/config.zsh

@@ -1,34 +0,0 @@
-# Writedown
-# generic configuration defaults for rendered files
-
-WRITEDOWN_TITLE="Zenroom Cryptolang Whitepaper"
-WRITEDOWN_AUTHOR="Denis Roio, Dyne.org"
-WRITEDOWN_AFFILIATION="Dyne.org Foundation"
-# WRITEDOWN_DATE="Wednesday 18 October 2017"
-WRITEDOWN_TAGS="[blockchain, smart, contract, rules, langsec, DSL]"
-
-# number for each section
-WRITEDOWN_NRSEC=yes
-# table of contents
-WRITEDOWN_TOC=yes
-# bibliographic citation style (see writedown/citstyle)
-WRITEDOWN_CITSTYLE=harvard-kings-college-london
-# font size
-WRITEDOWN_FONTSIZE=11pt
-# bibtex file for bibliographic sources
-WRITEDOWN_BIB=views/references.bib
-# latex template (header and footer)
-WRITEDOWN_LATEX_TEMPLATE=views/template.tex
-
-# different formats as supported by pandoc.
-# to activate uncomment and fill, then use dash (-) as first argument
-# i.e: ./writedown/render -
-# WRITEDOWN_OUTPUT_FORMAT=epub
-# WRITEDOWN_OUTPUT_EXTENSION=epub
-
-# default pandoc base command
-# WRITEDOWN_PANDOC="pandoc --smart --standalone -f markdown
-
-# Experimental features are commented below
-
-# WRITEDOWN_ZOTERO="no"

.docs.old/article/views/abstract.txt

@@ -1,6 +0,0 @@
-
-This document explains the nature of the Zenroom software component for the DECODE Project. It establishes guidelines and requirements for the implementation of an execution engine for a new domain specific language.
-
-DECODE's language is an external DSL implemented using a Syntax-Directed Translation. Its Semantic Model leads to coarse-grained tasks to be executed by the nodes on the peer to peer network.
-
-This is a living document and its latest version can be found on zenroom.dyne.org.

.docs.old/article/views/decode_language_patterns.md

@@ -1,255 +0,0 @@
-
-# Introduction
-
-The main way to communicate with a DECODE node and operate its functions is via a language, rather than an API. All read and write operations affecting entitlements and accessing attributes can be expressed in a smart-rule language, which we intend to design and develop to become a robust open standard for authorisation around personal data. The DECODE smart-rule language will aim to naturally avoid complex constructions and define sets of transformations that can be then easily represented with visual metaphors; in terms of programming language it will be deterministic and side effect-free in order to better prove its correctness.
-
-At this stage of the research, this document is split in 3 sections:
-
-1. a brief "state of the art" analysis, considering existing blockchain-based languages and in particular the most popular "Solidity" supported by the Ethereum virtual machine.
-
-2. a brief enumeration of the characteristics of this implementation and an abstraction from it, to individuate the fundamental features a smart-rule language should have in the context of permissionless, distributed computing.
-
-3. a set of technical recommendations for the development of smart-rules in DECODE
-
-This document is not speculative, but is companion to an actual implementation being developed during the course of DECODE's project: the ["zenroom" (link)](https://decodeproject.github.io/lua-zenroom/).
-
-
-## A new memory model
-
-In computing science the concepts of HEAP and STACK are well known and represent the different areas of memory in which a single computer can store code, address it while executing it and store data on which the code can read and write. With the advent of "virtual machines" (abstract computing machines like JVM or BEAM, not virtualised operating systems) the implementation of logic behind the HEAP and STACK became more abstract and not anymore bound to a specific hardware architecture, therefore leaving more space for the portability of code and creative memory management practices (like garbage collection). It is also thanks to the use of virtual machines that high level languages became closer to the way humans think, rather than the way machines work, benefitting creativity, awareness and auditability [@mccartney2002rethinking]. This is an important vector of innovation for the language implementation in DECODE, since it is desirable for this project to implement a language that is close to the way humans think.
-
-With the advent of distributed computing technology and blockchain implementations there is a growing necessity to conceive the HEAP and STACK differently [@DBLP:conf/ipps/PizkaR02], mostly because there are many more different conditions for memory bound to its persistence, read/write speed, mutability, distribution etc.
-
-The underpinning of this document, elaborated on the term "blockchain language", is that a new "distributed ledger", as collective and immutable memory space, can be addressed with code running on different machines.
-
-A "blockchain language" then is a language designed to interact with a "distributed ledger".  A distributed ledger is a log of "signed events" whose authenticity can be verified by any node being part of the network; taking part of a network can be regulated by permissions (in a so called "permissioned blockchain") or completely open to any participant complying to the protocol (so called "permissionless blockchain").
-
-This document intentionally leaves aside considerations about the consensus algorithm of a blockchain-based network, which are very specific issues concerning the implementation of a blockchain and are covered by other research tasks in DECODE. While assuming an ideal condition for fault tolerance will be provided by other research tasks in DECODE, this research will continue focusing on the function that the distributed ledger has for the distributed computation of a language, assuming the most interesting case of a permissionless blockchain (an open network) since that is the most ambitious research goal for DECODE as stated for the development of Chainspace [@al2017chainspace].
-
-
-
-# 1. Blockchain languages
-
-This section is a brief exploration of the main language implementations working on blockchains. Far from being an exhaustive overview, it highlights the characteristics of these implementations and most importantly the approach followed in building virtual machines that are based on assembler-like operation codes and languages that compile to these.
-
-The conclusion of this section is that the blockchain languages so far existing are designed with a product-oriented mindset, starting from the implementation of a virtual machine that can process OP_CODEs. Higher level languages build upon it, parsing higher level syntactics and semantics and compiling them into a series of OP_CODEs. This is the natural way most languages like ASM, C and C++ have evolved through the years.
-
-Arguably, a task-oriented mindset should be assumed when re-designing a new blockchain language for DECODE: that would be the equivalent of a human-centered research and design process. The opportunity for innovating the field lies in abandoning the OP_CODE approach and instead build an External Domain Specific Language [@fowler2010domain] using an existing grammar to do the Syntax-Directed Translation. The Semantic Model can be then a coarse-grained implementation that can sync computations with blockchain-based deterministic conditionals. 
-
-## Bitcoin's SCRIPT
-
-Starting with the "SCRIPT" implementation in Bitcoin [@nakamoto2008bitcoin] and ending with the Ethereum Virtual Machine implementation, it is clear that blockchain technologies were developed with the concept of "distributed computation" in mind. The scenario is that of a network of computers that, at any point in time, can execute the same code on a part of the distributed ledger and that execution would yield to the same results, making the computation completely deterministic.
-
-The distributed computation is made by blockchain nodes that act as sort of "virtual machines" and process "operation codes" (OP_CODE) just like a computer does. These OP_CODES in fact resemble assembler language operations. 
-
-In Bitcoin the so called SCRIPT implementation had an unfinished number of "OP_CODE" commands (operation codes) at the time of its popularisation and, around the 0.6 release, the feature was in large part deactivated to ensure the security of the network, since it was assessed by most developers involved that the Bitcoin implementation of SCRIPT was unfinished and represented threats to the network. Increasing the complexity of code that can be executed by nodes of an open network is always a risk, since code can contain arbitrary operations and commands that may lead to unpredictable results affecting both the single node and the whole network. The shortcomings of the SCRIPT in Bitcoin were partially addressed: its space for OP_RETURN [@roio2015d4] became the contested ground for payloads [@sward2017data] that could be interpreted by other VMs, as well the limit was partially circumvented by moving more complex logic in touch with the Bitcoin blockchain [@aron2012bitcoin], for instance using the techniques adopted by Mastercoin [@mastercoin2013willett] and "sidechains" as Counterparty [@bocek2018smart] or "pegged sidechains" [@back2014enabling] implementations. All these are implementations of VMs that run in parallel to Bitcoin, can "peg" their results on the main Bitcoin blockchain and still execute more complex operations in another space, where tokens and conditions can be created and affect different memory spaces and distributed ledgers.
-
-Languages implemented so far for this task are capable of executing single OP_CODEs: implementations are very much "machine-oriented" and focused on reproducing the behaviour of a turing-complete machine [@DBLP:conf/birthday/WegnerEB12] capable of executing generic computing tasks.
-
-
-## The Ethereum VM
-
-The Ethereum Virtual Machine is arguably the most popular implementation of a language that can be computed by a distributed and decentralised network of virtual machines that have all their own HEAP and STACK, but all share the same immutable distributed ledger on which "global" values and the code (contracts) manipulating them can be inscribed and read from.
-
-Computation in the EVM is done using a stack-based bytecode language that is like a cross between Bitcoin Script, traditional assembly and Lisp (the Lisp part being due to the recursive message-sending functionality). A program in EVM is a sequence of opcodes, like this:
-```
-PUSH1 0 CALLDATALOAD SLOAD NOT PUSH1 9 JUMPI STOP JUMPDEST PUSH1 32 CALLDATALOAD PUSH1 0 CALLDATALOAD SSTORE
-```
-The purpose of this particular contract is to serve as a name registry; anyone can send a message containing 64 bytes of data, 32 for the key and 32 for the value. The contract checks if the key has already been registered in storage, and if it has not been then the contract registers the value at that key. The address of the new contract is deterministic and calculated on the sending address and the number of times that the sending account has made a transaction before.
-
-The EVM is a simple stack-based architecture. The word size of the machine (and thus size of stack item) is 256-bit. This was chosen to fit a simple word-addressed byte array. The stack has a maximum size of 1024. The machine also has an independent storage model; this is similar in concept to the memory but rather than a byte array, it is a word- addressable word array. Unlike memory, which is volatile, storage is nonvolatile and is maintained as part of the system state. All locations in both storage and memory are well-defined initially as zero.
-
-The machine does not follow the standard von Neumann architecture. Rather than storing program code in generally-accessible memory or storage, it is stored separately in a virtual ROM that can only be interacted with via a specific instruction.  The machine can have exceptional execution for several reasons, including stack underflows and invalid instructions. Like the out-of-gas (OOG) exception, they do not leave state changes intact. Rather, the machine halts immediately and reports the issue to the execution agent (either the transaction processor or, recursively, the spawning execution environment) which will deal with it separately [@wood2014ethereum].
-
-The resulting implementation consists of a list of OP_CODEs whose execution requires a "price" to be paid (Ethereum's currency for the purpose is called "gas"). This way an incentive is created for running nodes: a fee is paid to nodes for computing the contracts and confirming the outcomes of their execution. This feature technically defines the Ethereum VM as implementing an almost Turing-complete machine since its execution is conditioned by the availability of funds for computation. This approach relies on the fact that each operation is executed at a constant unit of speed.
-
-On top of these OP_CODEs the "Solidity" language was developed as a high-level language that compiles to OP_CODE sequences. Solidity aims to make it easier for people to program "smart contracts". But it is arguable that the Solidity higher-level language, widely present in all Ethereum related literature, carries several problems: the shortcomings of its design can be indirectly related to some well-known disasters provoked by flaws in published contracts. To quickly summarise some flaws:
-
- - there is no garbage collector nor manual memory management
- - floating point numbers are not supported
- - there are known security flaws in the compiler
- - the syntax of loops and arrays is confusing
- - every type is 256bits wide, including bytes
- - there is no string manipulation support
- - functions can return only statically sized arrays
-
-To overcome the shortcomings and create some shared base of reliable implementations, programmers using Solidity currently adopt "standard" token implementation libraries with basic functions that are proven to be working reliably: known as ERC20, the standard is made for tokens to be supported across different wallets and to be reliable. Yet even with a recent update to a new version (ERC232) the typical code constructs that are known to be working are full of checks (assert calls) to insure the reliability of the calling code. For example, typical arithmetic operations need to be implemented in Solidity as:
-
-```c
-
-  function times(uint a, uint b) constant private returns (uint) {
-    uint c = a * b;
-    assert(a == 0 || c / a == b);
-    return c;
-  }
-
-  function minus(uint a, uint b) constant private returns (uint) {
-    assert(b <= a);
-    return a - b;
-  }
-
-  function plus(uint a, uint b) constant private returns (uint) {
-    uint c = a + b;
-    assert(c>=a);
-    return c;
-  }
-```
-
-It must be also noted that the EVM allows calling external contracts that can take over the control flow and make changes to data that the calling function wasn't expecting. This class of bug can take many forms and all of major bugs that led to the DAO's collapse [@o2017smart] were bugs of this sort.
-
-Despite the shortcomings, nowadays Solidity is widely used: it is the most used "blockchain language" supporting "smart-contracts" in the world.
-
-# 2. Language Security
-
-This chapter will quickly establish the underpinnings of a smart rule language in DECODE, starting from its most theoretical assumptions, to conclude with specific requirements. The chapter will concentrate on the recent corpus developed by research on language-theoretic security" (LangSec). Here below we include a brief explanation condensed from the information material of the LangSec.org project hosted at IEEE, which is informed by the collective experience of the exploit development community, since exploitation is a practical exploration of the space of unanticipated state, its prevention or containment.
-
-"In a nutshell [...] LangSec is the idea that many security issues can be avoided by applying a standard process to input processing and protocol design: the acceptable input to a program should be well-defined (i.e., via a grammar), as simple as possible (on the Chomsky scale of syntactic complexity), and fully validated before use (by a dedicated parser of appropriate but not excessive power in the Chomsky hierarchy of automata)." [@DBLP:conf/secdev/MomotBHP16]
-
-LangSec is a design and programming philosophy that focuses on formally correct and verifiable input handling throughout all phases of the software development lifecycle. In doing so, it offers a practical method of assurance of software free from broad and currently dominant classes of bugs and vulnerabilities related to incorrect parsing and interpretation of messages between software components (packets, protocol messages, file formats, function parameters, etc.).
-
-This design and programming paradigm begins with a description of valid inputs to a program as a formal language (such as a grammar). The purpose of such a disciplined specification is to cleanly separate the input-handling code and processing code. A LangSec-compliant design properly transforms input-handling code into a recognizer for the input language; this recognizer rejects non-conforming inputs and transforms conforming inputs to structured data (such as an object or a tree structure, ready for type- or value-based pattern matching). The processing code can then access the structured data (but not the raw inputs or parsers temporary data artifacts) under a set of assumptions regarding the accepted inputs that are enforced by the recognizer.
-
-This approach leads to several advantages:
-
- 1. produce verifiable recognizers, free of typical classes of ad-hoc parsing bugs
- 2. produce verifiable, composable implementations of distributed systems that ensure equivalent parsing of messages by all components and eliminate exploitable differences in message interpretation by the elements of a distributed system
- 3. mitigate the common risks of ungoverned development by explicitly exposing the processing dependencies on the parsed input.
-
-As a design philosophy, LangSec focuses on a particular choice of verification trade-offs: namely, correctness and computational equivalence of input processors.
-
-
-## Threats when developing a language
-
-As one engages the task of developing a language there are four main threats to be identified, well described in LangSec literature:
-
-### Ad-hoc notions of input validity
-
-Formal verification of input handlers is impossible without formal language-theoretic specification of their inputs, whether these inputs are packets, messages, protocol units, or file formats. Therefore, design of an input-handling program must start with such a formal specification.  Once specified, the input language should be reduced to the least complex class requiring the least computational power to recognize. Considering the tendency of hand-coded programs to admit extra state and computation paths, computational power susceptible to crafted inputs should be minimized whenever possible. Whenever the input language is allowed to achieve Turing-complete power, input validation becomes undecidable; such situations should be avoided. For example, checking 'benignness' of arbitrary Javascript or even an HTML5+CSS page is a losing proposition.
-
-### Parser differentials
-
-Mutual misinterpretation between system components. Verifiable composition is impossible without the means of establishing parsing equivalence between different components of a distributed system. Different interpretation of messages or data streams by components breaks any assumptions that components adhere to a shared specification and so introduces inconsistent state and unanticipated computation [@DBLP:conf/secdev/MomotBHP16]. In addition, it breaks any security schemes in which equivalent parsing of messages is a formal requirement, such as the contents of a certificate or of a signed message being interpreted identically, for example a X.509 Certificate Signing Request as seen by a Certificate Authority vs. the signed certificates as seen by the clients or signed app package contents as seen by the signature verifier versus the same content as seen by the installer (as in the recent Android Master Key bug [@freeman2013exploit]). An input language specification stronger than deterministic context-free makes the problem of establishing parser equivalence undecidable. Such input languages and systems whose trustworthiness is predicated on the component parser equivalence should be avoided. Logical programming using Prolog for instance, or languages like Scheme derived from LISP, or OCaml or Erlang would match then our requirements, but they aren't as usable as desired. As a partial solution to this problem the DECODE language parser (and all its components and eventually linked shared libraries) should be self-contained and clearly versioned and hashed and its hash verified before every computation. 
-
-### Mixing of input recognition and processing
-
-Mixing of basic input validation ("sanity checks") and logically subsequent processing steps that belong only after the integrity of the entire message has been established makes validation hard or impossible. As a practical consequence, unanticipated reachable state exposed by such premature optimization explodes. This explosion makes principled analysis of the possible computation paths untenable. LangSec-style separation of the recognizer and processor code creates a natural partitioning that allows for simpler specification-based verification and management of code. In such designs, effective elimination of exploit-enabling implicit data flows can be achieved by simple systems memory isolation primitives.
-
-### Language specification drift
-
-A common practice encouraged by rapid software development is the unconstrained addition of new features to software components and their corresponding reflection in input language specifications. Expressing complex ideas in hastily written code is a hallmark of such development practices. In essence, adding new input feature requirements to an already-underspecified input language compounds the explosion of state and computational paths.
-
-# 3. Smart-rules language
-
-In light of our study of blockchain languages, use-cases and privacy by design guidelines in DECODE, this section lists three functional requirements and three usability requirements influencing the design patterns for our language.
-
-The conclusion of this section is best described adopting once again the DSL terminology and the patterns established by Fowler. The DECODE smart-rule language is an external DSL implemented using a Syntax-Directed Translation. Its Semantic Model leads to coarse-grained tasks to be executed on the network, perhaps following a Dependency Network approach.
-
-A tempting alternative can be that of a Production Rule System, but this way we would hide too much the internal processes in DECODE, which should be transparent and comprehensible to anyone with a beginner knowledge of programming.
-
-An addition to this approach can be that of equipping the language with tools for constraint programming and even a context of Satisfiability Modulo Theories [@barrett2009satisfiability] to check satisfying Program Termination Proofs [@bonfante2001algorithms].
-
-
-
-
-## Functional requirements
-
-On the basis of the design considerations made in the previous chapters, here are listed the main requirements identified for the implementation of a smart-rule language in DECODE.
-
-### Deterministic
-
-This is an important feature common to all blockchain language implementations in use: that the language limits its operations to access only a fully deterministic environment. This means that, in any possible moment in time, any node can join the network and start computing contracts leading to results that are verifiable and confirmed by other nodes.
-
-In other words, the environment accessed by the language is available to all nodes, there aren't variables that are "private" to a single node and may change the result by a change of their value.
-
-The deterministic trait must be common also to the DECODE blockchain language for smart-rules, since it verifies a basic and necessary condition for blockchain based computing: that other nodes can verify and sign the results, reproducing them in their own execution environment. The computation leads to the same results that can be determined in different conditions, because all nodes have access to the same information necessary to the computation.
-
-### Trustless
-
-We define as trustless a language (also known as untrusted language) that allows the virtual machine to fence its execution, as in a "sandbox" or isolated execution environment, blocking access to unauthorised parts of the system.
-
-A language that can be run on a "permissionless" (public) blockchain is a language that can be interpreted by any node. In any moment a new node may claim the capacity to do so. This means that its parser, semantics and actions on the system must be designed to handle unknowns: any deviance and malevolent code should not affect the system.
-
-### Strict
-
-The language and the semantic model adopted by Zenroom are designed to allow the sandboxing of untrusted code and to provide security partitioning. Any process of execution is strictly limited in what it can do, first and foremost in terms of memory and computational cycles used.
-
-The objective is that any function or data passed to a Zenroom process cannot break the sandbox in ways the participants did not intend. If an error occurs the Zenroom engine will not continue further, rather exit with a meaningful error message and dispose of all the memory used via garbage collection. For sensitive data structures the use of a declarative schema validation is provided as a security guard, to allow scripts to easily recognise the data they are passing to functions.
-
-
-## Usability requirements
-
-Here are listed the requirements emerging from an analysis of priorities about the human-machine interaction scenarios emerging from DECODE.
-
-### Simple, graphical representation
-
-A visual programming environment (VPE) facilitates participants to directly re-configure the rules governing their data: this is highly desirable in DECODE, where such code must be transparent and understandable. The event-based blocks graphical metaphor seems the most desirable for the sort of processing in DECODE: it involves letting participants manipulate a series of graphical elements (blocks) that snap onto one another and that execute sequential programs.
-
-### Test environment
-
-A reliable test environment is a fundamental component for a language deployed in mission critical situations, but also for a language dealing with the distribution of its computation and wide adoption by communities of developers in different fields. Languages that improve the developer's experience when writing and testing code directly impact the quality of the code produced.
-
-For the Zenroom work is in progress to provide a testing environment designed from the start to facilitate its growth at the same pace of the language itself. Also, a more advanced framework for testing that goes beyond the simple usage of asserts and data validations is planned: while being very ambitious, the implementation of solid proof of termination mechanisms that are internal to the language should be contemplated on the long term.
-
-### First-class data
-
-This is a long-term requirement that should take into consideration the trade-off between feasibility, security and convenience. A data type is considered first-class in a programming language if instances of that type can be
-
- - the value of a variable
- - a member of an aggregate (array, list, etc.)
- - an argument (input) to a procedure
- - the value returned by a procedure
- - used without having a name (being the value of a variable)
-
-For example, numbers are first-class in every language. Text strings are first-class in many languages, but not in C, in which the relevant first-class type is “pointer to a character”.
-
-In Zenroom any important data structure needs to be validated at start and become a first-class citizen to be seamlessly processed by other scripted functions. Following a declarative and non-imperative approach, developers can concentrate on the script while at the same time producing part of the documentation needed to define its data structures and functional constraints.
-
-
-# Conclusion
-
-This document is a very dense representation of language patterns and requirements to be adopted while implementing DECODE's language. Its feasibility has been verified with an extensive survey on available tools that can be used to implement this execution engine and are compatible with the DECODE licensing model.
-
-This conclusion provides a brief list of components that can be used.
-
-## Syntax-Directed Translation
-
-Lua is an interpreted, cross-platform, embeddable, performant and low-footprint language. Lua's popularity is on the rise in the last couple of years [@costin2017lua]. Simple design and efficient usage of resources combined with its performance make it attractive for production web applications, even to big organizations such as Wikipedia, CloudFlare and GitHub. In addition to this, Lua is one of the preferred choices for programming embedded and IoT devices. This context allows an assumption of a large and growing Lua codebase yet to be assessed. This growing Lua codebase could be potentially driving production servers and an extremely large number of devices, some perhaps with mission-critical function for example in automotive or home-automation domains.
-
-Lua stability has been extensively tested through a number of public applications including the adoption by the gaming industry for untrusted language processing in "World of Warcraft" scripting. It is ideal for implementing an external DSL using C or Python as a host language.
-
-Lua is also tooled with a working VPE implementation for code visualisation in blocks, allowing the project to jump-start into an early phase of prototyping DECODE's smart-rules in a visual way and directly involving pilot participants.
-
-## Satisfiability Modulo theories
-
-Satisfiability Modulo theories (SMT) is an area of automated deduction that studies methods for checking the satisfiability of first-order formulas with respect to some logical theory of interest [@barrett2009satisfiability]. It differs from general automated deduction in that the background theory need not be finitely or even first-order axiomatizable, and specialized inference methods are used for each theory. By being theory-specific and restricting their language to certain classes of formulas (such as, typically but not exclusively, quantifier-free formulas), these specialized methods can be implemented in solvers that are more efficient in practice than general-purpose theorem provers.
-
-While SMT techniques have been traditionally used to support deductive software verification, they are now finding applications in other areas of computer science such as planning, model checking and automated test generation. Typical theories of interest in these applications include formalizations of arithmetic, arrays, bit vectors, algebraic datatypes, equality with uninterpreted functions, and various combinations of these. 
-
-Constraint-satisfaction is crucial to software and hardware verification and static program analsysis [@de2011satisfiability] among the other possible applications.
-
-DECODE will benefit from including SMT capabilities into the design at an early stage: even if not immediately exploited, their inclusion will keep the horizons for language development open while permitting its application in mission critical roles. The best implementation to start from in this experimentation seems to be the free and open source software "Yices SMT Solver" published by the Computer Science Laboratory of the Stanford Research Institute (SRI International).
-
-<!--
-## Ontology
-
-Considering the overall project schedule and the advancement of other deliverables at current stage in the DECODE project, it is an ill-advised choice to indicate that this document may include an ontology. The scheduled deliverable D3.5 still mentions the publication of an "initial ontology and smart-rules" and it is a more realistic estimation of delivery for this topic. Meanwhile this document represents a complete overview on smart-rule language requirements.
-
--->
-
-<!--
-SDT
-http://minikanren.org/
-http://www.gecode.org/
-https://github.com/handsomecheung/miniKanren.lua
-https://github.com/SRI-CSL/yices2
-
-
-python:
-https://wiki.python.org/moin/SandboxedPython
-https://github.com/dsagal/pynbox
-https://github.com/RealTimeWeb/blockpy
-
-
-
-
--->

.docs.old/article/views/index.txt

@@ -1 +0,0 @@
-decode_language_patterns.md

.docs.old/article/views/references.bib

@@ -1,261 +0,0 @@
-
-@article{roio2015d4,
-  title={Design of Social Digital Currency},
-  author={Roio, Denis and Sachy, Marco and Lucarelli, Stefano and Lietaer, Bernard and Bria, Francesca},
-  year={2015},
-  publisher={EU-FP7/D-CENT}
-}
-
-
-@article{sward2017data,
-  title={Data Insertion in Bitcoin's Blockchain},
-  author={Sward, Andrew and OP\_0, Vecna and Stonedahl, Forrest},
-  year={2017}
-}
-
-
-@InProceedings{DBLP:conf/birthday/WegnerEB12,
-  author	   = {Peter Wegner and Eugene Eberbach and Mark Burgin},
-  title		   = {Computational Completeness of Interaction Machines
-                  and Turing Machines},
-  year		   = 2012,
-  booktitle	   = {Turing-100 - The Alan Turing Centenary, Manchester,
-                  UK, June 22-25, 2012},
-  pages		   = {405-414},
-  url		   = {http://www.easychair.org/publications/paper/106520},
-  crossref	   = {DBLP:conf/birthday/2012turing},
-  timestamp	   = {Tue, 25 Jul 2017 11:35:36 +0200},
-  biburl	   = {http://dblp.org/rec/bib/conf/birthday/WegnerEB12},
-  bibsource	   = {dblp computer science bibliography, http://dblp.org}
-}
-
-@proceedings{DBLP:conf/birthday/2012turing,
-  editor    = {Andrei Voronkov},
-  title     = {Turing-100 - The Alan Turing Centenary, Manchester, UK, June 22-25,
-               2012},
-  series    = {EPiC Series in Computing},
-  volume    = {10},
-  publisher = {EasyChair},
-  year      = {2012},
-  url       = {http://www.easychair.org/publications/?page=1900403647},
-  timestamp = {Thu, 16 Jun 2016 17:11:03 +0200},
-  biburl    = {http://dblp.org/rec/bib/conf/birthday/2012turing},
-  bibsource = {dblp computer science bibliography, http://dblp.org}
-}
-
-@InProceedings{DBLP:conf/ipps/PizkaR02,
-  author	   = {Markus Pizka and Christian Rehn},
-  title		   = {Heaps and Stacks in Distributed Shared Memory},
-  year		   = 2002,
-  booktitle	   = {16th International Parallel and Distributed
-                  Processing Symposium {(IPDPS} 2002), 15-19 April
-                  2002, Fort Lauderdale, FL, USA, CD-ROM/Abstracts
-                  Proceedings},
-  doi		   = {10.1109/IPDPS.2002.1016494},
-  url		   = {https://doi.org/10.1109/IPDPS.2002.1016494},
-  crossref	   = {DBLP:conf/ipps/2002},
-  timestamp	   = {Wed, 24 May 2017 08:28:14 +0200},
-  biburl	   = {http://dblp.org/rec/bib/conf/ipps/PizkaR02},
-  bibsource	   = {dblp computer science bibliography, http://dblp.org}
-}
-
-@proceedings{DBLP:conf/ipps/2002,
-  title     = {16th International Parallel and Distributed Processing Symposium {(IPDPS}
-               2002), 15-19 April 2002, Fort Lauderdale, FL, USA, CD-ROM/Abstracts
-               Proceedings},
-  publisher = {{IEEE} Computer Society},
-  year      = {2002},
-  url       = {http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7926},
-  isbn      = {0-7695-1573-8},
-  timestamp = {Fri, 01 Aug 2014 14:26:10 +0200},
-  biburl    = {http://dblp.org/rec/bib/conf/ipps/2002},
-  bibsource = {dblp computer science bibliography, http://dblp.org}}
-
-@article{al2017chainspace,
-  title={Chainspace: A Sharded Smart Contracts Platform},
-  author={Al-Bassam, Mustafa and Sonnino, Alberto and Bano, Shehar and Hrycyszyn, Dave and Danezis, George},
-  journal={arXiv preprint arXiv:1708.03778},
-  year={2017}
-}
-
-@InProceedings{DBLP:conf/sp/WoodH15,
-  author	   = {Kerry N. Wood and Richard E. Harang},
-  title		   = {Grammatical Inference and Language Frameworks for
-                  {LANGSEC}},
-  year		   = 2015,
-  booktitle	   = {2015 {IEEE} Symposium on Security and Privacy
-                  Workshops, {SPW} 2015, San Jose, CA, USA, May 21-22,
-                  2015},
-  pages		   = {88-98},
-  doi		   = {10.1109/SPW.2015.17},
-  url		   = {https://doi.org/10.1109/SPW.2015.17},
-  crossref	   = {DBLP:conf/sp/2015w},
-  timestamp	   = {Fri, 26 May 2017 00:50:07 +0200},
-  biburl	   = {http://dblp.org/rec/bib/conf/sp/WoodH15},
-  bibsource	   = {dblp computer science bibliography, http://dblp.org}
-}
-
-@proceedings{DBLP:conf/sp/2015w,
-  title     = {2015 {IEEE} Symposium on Security and Privacy Workshops, {SPW} 2015,
-               San Jose, CA, USA, May 21-22, 2015},
-  publisher = {{IEEE} Computer Society},
-  year      = {2015},
-  url       = {http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7160794},
-  isbn      = {978-1-4799-9933-0},
-  timestamp = {Tue, 10 May 2016 13:48:24 +0200},
-  biburl    = {http://dblp.org/rec/bib/conf/sp/2015w},
-  bibsource = {dblp computer science bibliography, http://dblp.org}
-}
-
-@InProceedings{DBLP:conf/secdev/MomotBHP16,
-  author	   = {Falcon Momot and Sergey Bratus and Sven M. Hallberg
-                  and Meredith L. Patterson},
-  title		   = {The Seven Turrets of Babel: {A} Taxonomy of LangSec
-                  Errors and How to Expunge Them},
-  year		   = 2016,
-  booktitle	   = {{IEEE} Cybersecurity Development, SecDev 2016,
-                  Boston, MA, USA, November 3-4, 2016},
-  pages		   = {45-52},
-  doi		   = {10.1109/SecDev.2016.019},
-  url		   = {https://doi.org/10.1109/SecDev.2016.019},
-  crossref	   = {DBLP:conf/secdev/2016},
-  timestamp	   = {Fri, 17 Nov 2017 10:29:37 +0100},
-  biburl	   = {http://dblp.org/rec/bib/conf/secdev/MomotBHP16},
-  bibsource	   = {dblp computer science bibliography, http://dblp.org}
-}
-
-@proceedings{DBLP:conf/secdev/2016,
-  title     = {{IEEE} Cybersecurity Development, SecDev 2016, Boston, MA, USA, November
-               3-4, 2016},
-  publisher = {{IEEE}},
-  year      = {2016},
-  url       = {http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7838558},
-  isbn      = {978-1-5090-5589-0},
-  timestamp = {Fri, 17 Nov 2017 10:29:37 +0100},
-  biburl    = {http://dblp.org/rec/bib/conf/secdev/2016},
-  bibsource = {dblp computer science bibliography, http://dblp.org}
-}
-
-@article{costin2017lua,
-  title={Lua code: security overview and practical approaches to static analysis},
-  author={Costin, Andrei},
-  year={2017}
-}
-
-@article{wood2014ethereum,
-  title={Ethereum: A secure decentralised generalised transaction ledger},
-  author={Wood, Gavin},
-  journal={Ethereum Project Yellow Paper},
-  volume={151},
-  year={2014}
-}
-
-@Article{nakamoto2008bitcoin,
-	author = {Nakamoto, Satoshi},
-	title = {{Bitcoin: A peer-to-peer electronic cash system}},
-	journal = {{Consulted}},
-	volume = {{1}},
-	pages = {2012},
-	year = {2008},
-}
-
-@Article{aron2012bitcoin,
-	Publisher = {{Elsevier}},
-	author = {Aron, Jacob},
-	title = {{BitCoin software finds new life}},
-	journal = {{New Scientist}},
-	volume = {{213}},
-	number = {{2847}},
-	pages = {20},
-	year = {2012},
-}
-
-@article{mastercoin2013willett,
-	url = {{https://github.com/mastercoin-MSC/spec}},
-	author = {J. R. Willett},
-	title = {{MasterCoin Complete Specification}},
-	year = {2013},
-}
-
-@article{back2014enabling,
-  title={Enabling blockchain innovations with pegged sidechains},
-  author={Back, Adam and Corallo, Matt and Dashjr, Luke and Friedenbach, Mark and Maxwell, Gregory and Miller, Andrew and Poelstra, Andrew and Tim{\'o}n, Jorge and Wuille, Pieter},
-  journal={URL: http://www. opensciencereview. com/papers/123/enablingblockchain-innovations-with-pegged-sidechains},
-  year={2014}
-}
-
-@incollection{bocek2018smart,
-  title={Smart Contracts--Blockchains in the Wings},
-  author={Bocek, Thomas and Stiller, Burkhard},
-  booktitle={Digital Marketplaces Unleashed},
-  pages={169--184},
-  year={2018},
-  publisher={Springer}
-}
-
-@book{fowler2010domain,
-  title={Domain-specific languages},
-  author={Fowler, Martin},
-  year={2010},
-  publisher={Pearson Education}
-}
-
-@article{barrett2009satisfiability,
-  title={Satisfiability Modulo Theories.},
-  author={Barrett, Clark W and Sebastiani, Roberto and Seshia, Sanjit A and Tinelli, Cesare},
-  journal={Handbook of satisfiability},
-  volume={185},
-  pages={825--885},
-  year={2009}
-}
-
-@article{de2011satisfiability,
-  title={Satisfiability modulo theories: introduction and applications},
-  author={De Moura, Leonardo and Bj{\o}rner, Nikolaj},
-  journal={Communications of the ACM},
-  volume={54},
-  number={9},
-  pages={69--77},
-  year={2011},
-  publisher={ACM}
-}
-
-@article{o2017smart,
-  title={Smart Contracts-Dumb Idea},
-  author={O'Hara, Kieron},
-  journal={IEEE Internet Computing},
-  volume={21},
-  number={2},
-  pages={97--101},
-  year={2017},
-  publisher={IEEE}
-}
-
-
-@misc{freeman2013exploit,
-  title={Exploit \& Fix Android \"Master Key"; Android Bug Superior to Master Key; Yet Another Android Master Key Bug},
-  author={Freeman, Jay},
-  year={2013}
-}
-
-@article{bonfante2001algorithms,
-  title={Algorithms with polynomial interpretation termination proof},
-  author={Bonfante, Guillaume and Cichon, Adam and Marion, J-Y and Touzet, H{\'e}l{\`e}ne},
-  journal={Journal of Functional Programming},
-  volume={11},
-  number={1},
-  pages={33--53},
-  year={2001},
-  publisher={Cambridge University Press}
-}
-
-@article{mccartney2002rethinking,
-  title={Rethinking the computer music language: SuperCollider},
-  author={McCartney, James},
-  journal={Computer Music Journal},
-  volume={26},
-  number={4},
-  pages={61--68},
-  year={2002},
-  publisher={MIT Press}
-}

.docs.old/article/views/template.tex

@@ -1,177 +0,0 @@
-\documentclass[a4paper]{extarticle}
-\usepackage{lmodern}
-$if(fontsize)$
-\usepackage[$fontsize$]{extsizes}
-$endif$
-\usepackage{fullpage}
-\usepackage{longtable}
-\usepackage{booktabs}
-\usepackage{amssymb,amsmath}
-\usepackage{ifxetex,ifluatex}
-\usepackage{fixltx2e} % provides \textsubscript
-\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
-  \usepackage[T1]{fontenc}
-  \usepackage[utf8x]{inputenc}
-\else % if luatex or xelatex
-  \ifxetex
-    \usepackage{mathspec}
-  \else
-    \usepackage{fontspec}
-  \fi
-  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
-\fi
-% use upquote if available, for straight quotes in verbatim environments
-\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
-% use microtype if available
-\IfFileExists{microtype.sty}{%
-\usepackage{microtype}
-\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
-}{}
-\usepackage{hyperref}
-\hypersetup{unicode=true,
-            pdftitle={$title$},
-            pdfauthor={$author$},
-            $if(keywords)$
-            pdfkeywords={$for(keywords)$$keywords$$sep$; $endfor$},
-            $endif$
-            pdfborder={0 0 0},
-            breaklinks=true}
-\urlstyle{same}  % don't use monospace font for urls
-\usepackage{xcolor}
-$if(listings)$
-\usepackage{listings}
-\lstset{
-    basicstyle=\ttfamily,
-%    numbers=left,
-    numberstyle=\footnotesize,
-    stepnumber=2,
-    numbersep=5pt,
-    backgroundcolor=\color{black!10},
-    showspaces=false,
-    showstringspaces=false,
-    showtabs=false,
-    tabsize=2,
-    captionpos=b,
-    breaklines=true,
-    breakatwhitespace=true,
-    breakautoindent=true,
-    linewidth=\textwidth
-}
-$endif$
-\usepackage{color}
-\usepackage{fancyvrb}
-\newcommand{\VerbBar}{|}
-\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
-\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
-% Add ',fontsize=\small' for more characters per line
-\newenvironment{Shaded}{}{}
-\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{{#1}}}}
-\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{{#1}}}
-\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{{#1}}}
-\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{{#1}}}
-\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{{#1}}}
-\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{{#1}}}
-\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
-\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
-\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
-\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{{#1}}}
-\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{{#1}}}
-\newcommand{\ImportTok}[1]{{#1}}
-\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{{#1}}}}
-\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{{#1}}}}
-\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
-\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
-\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{{#1}}}
-\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{{#1}}}
-\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{{#1}}}
-\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{{#1}}}}
-\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{{#1}}}
-\newcommand{\BuiltInTok}[1]{{#1}}
-\newcommand{\ExtensionTok}[1]{{#1}}
-\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{{#1}}}
-\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{{#1}}}
-\newcommand{\RegionMarkerTok}[1]{{#1}}
-\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
-\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{{#1}}}}}
-\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{{#1}}}}
-\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{{#1}}}}
-\newcommand{\NormalTok}[1]{{#1}}
-\usepackage{graphicx,grffile}
-\makeatletter
-\def\maxwidth{\ifdim\Gin@nat@width>\linewidth\linewidth\else\Gin@nat@width\fi}
-\def\maxheight{\ifdim\Gin@nat@height>\textheight\textheight\else\Gin@nat@height\fi}
-\makeatother
-% Scale images if necessary, so that they will not overflow the page
-% margins by default, and it is still possible to overwrite the defaults
-% using explicit options in \includegraphics[width, height, ...]{}
-\setkeys{Gin}{width=\maxwidth,height=\maxheight,keepaspectratio}
-\IfFileExists{parskip.sty}{%
-\usepackage{parskip}
-}{% else
-\setlength{\parindent}{0pt}
-\setlength{\parskip}{6pt plus 2pt minus 1pt}
-}
-
-% previously included by writedown in options.sty
-\setlength{\parindent}{1.25em}
-\setlength{\parskip}{.2em}
-\usepackage{etoolbox}
-\AtBeginEnvironment{quote}{\parskip 1em}
-
-\setlength{\emergencystretch}{3em}  % prevent overfull lines
-\providecommand{\tightlist}{%
-  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
-\setcounter{secnumdepth}{0}
-% Redefines (sub)paragraphs to behave more like sections
-\ifx\paragraph\undefined\else
-\let\oldparagraph\paragraph
-\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
-\fi
-\ifx\subparagraph\undefined\else
-\let\oldsubparagraph\subparagraph
-\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
-\fi
-% END OF CONFIG    ------------------------------------------
-
-% START OF CONTENT ------------------------------------------
-
-\title{$title$}
-$if(subtitle)$
-\providecommand{\subtitle}[1]{}
-\subtitle{$subtitle$}
-$endif$
-$if(author)$
-\author{$for(author)$$author$$sep$ \and $endfor$}
-$endif$
-$if(institute)$
-\providecommand{\institute}[1]{}
-\institute{$for(institute)$$institute$$sep$ \and $endfor$}
-$endif$
-\date{$date$}
-$if(logo)$
-\logo{\includegraphics{$logo$}}
-$endif$
-
-\begin{document}
-
-\maketitle
-
-\begin{abstract}
-$abstract$
-\end{abstract}
-
-\providecommand{\keywords}[1]{\textbf{\textit{Keywords---}} #1}
-$if(keywords)$
-    \keywords{$for(keywords)$$keywords$$sep$; $endfor$}
-$endif$
-
-\pagebreak[4]
-{
-\setcounter{tocdepth}{3}
-\tableofcontents
-}
-\pagebreak[4]
-
-$body$
-
-\end{document}

.docs.old/completions.lua

@@ -1,23 +0,0 @@
--- introspective script to compile a list of completion terms
-
-local modules = { 
-   ["OCTET"] = OCTET, ["octet"] = OCTET.new(8),
-   ["ECDH"] = ECDH, ["ecdh"] = ECDH.new(),
---   ["ECP"] = ECP, ["ecp"] = ECP.new(ECP.generator()),
-   ["BIG"] = BIG, ["big"] = BIG.new(1),
---   ["RNG"] = RNG, ["rng"] = RNG.new(),
-   ["HASH"] = HASH, ["hash"] = HASH.new() }
-for n,m in pairs(modules) do
-   if type(m)=='table' then
-	  for k,v in pairs(m) do 
-		 if type(v)~='table' and string.sub(k,1,1)~='_' then
-			print(n.."."..k)
-		 end
-	  end
-   else
-	  for s,f in pairs(getmetatable(m)) do
-		 if(string.sub(s,1,2)~='__') then print(":"..s) end
-	  end
-   end
-end
--- for k,v in pairs(octet) do print(":"..k) end

.docs.old/config.zsh

@@ -1,55 +0,0 @@
-
-# WEBNOMAD CONFIGURATION
-TITLE="Zenroom - Crypto Language Execution"
-
-DESCRIPTION="Zenroom is a small and portable virtual machine for cryptographic operations running on Windows, OSX, GNU/Linux, BSD and as Javascript and Webassembly inside modern browsers."
-
-KEYWORDS="crypto, blockchain, language, LUA, VM, free, open source"
-
-# representative image, 1200x627 pixels is full column banner, 400 is half
-# exact size indicated above is important to avoid resizes server-side
-IMAGE="https://zenroom.dyne.org/img/InputLanguages.jpg"
-
-# list of types: http://ogp.me/#types
-TYPE="website"
-
-# What is the root of this website url, after the domain
-# full url includes http and no trailing slash i.e. http://www.dyne.org
-# leave blank if relative, or just subdir i.e /blog
-WEB_ROOT="https://zenroom.dyne.org"
-
-# A twitter handler is necessary to activate open-graph compatible
-# information that works also with twitter.
-TWITTER="@DyneOrg"
-
-#
-# Anything below is safe to leave untouched
-#
-
-# Comment to disable Bootstrap
-BOOTSTRAP=1
-
-FONTAWESOME=1
-
-# What file extension to use for html files
-EXTENSION=".html"
-
-# What is the url for files in case indexing is used
-# this can be different from WEB_ROOT in order to serve
-# files from a position different from the web pages
-# FILES_ROOT=""
- 
-# Uncomment for Flowtype
-FLOWTYPE=1
-# What is the size ratio of text with respect to the width
-# of its container element. This is better than setting the
-# text size in an absolute way (we use Flowtype)
-FONT_RATIO=35
-
-# Cleanup EXIF information from jpeg images (requires jhead)
-# i.e: location, camera type, time of shot, editors used
-EXIF_CLEAN=1
-# Add a comment to EXIF in jpeg images (requires jhead)
-EXIF_COMMENT="Image from Zenroom.Dyne.org"
-# Automatically rotate the image according to EXIF information
-# EXIF_ROTATE=1

.docs.old/ldoc/Makefile

@@ -1,10 +0,0 @@
-
-all: wiki
-	@mkdir -p ../pub/api
-	ldoc -X .
-
-
-## select wiki pages
-wiki:
-	pandoc -f markdown -t html ../wiki/Syntax.md > Syntax
-	pandoc -f markdown -t html ../wiki/StateMachine.md > StateMachine

.docs.old/ldoc/config.ld

@@ -1,49 +0,0 @@
-project='Zenroom'
-title='Zenroom LUA'
-description='Documentation of Lua scripting in Zenroom'