├── GLOSSARY.md ├── LICENSE ├── README.md ├── VISION.md └── accepted ├── 001-docs.md ├── 002-node-authentication-authn.md ├── 003-workload.md └── 010-database.md /GLOSSARY.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | Below find the official glossary of architectural terms of the project. 4 | 5 | ### Aurae 6 | 7 | * Aurae is the name of the project. 8 | * Aurae Node is the set of services that provide an Aurae service that exist as 9 | a single fault domain. 10 | * auraed is the name of the Aurae Daemon process, not including backing services. 11 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Architecture 2 | 3 | Design Docs and Decisions. Where the magic happens. 4 | 5 | --- 6 | 7 | See the [whitepaper](https://docs.google.com/document/d/1dA591eipsgWeAlaSwbYNQtAQaES243IIqXPAfKhJSjU/edit#heading=h.vknhjb3d4yfc). 8 | -------------------------------------------------------------------------------- /VISION.md: -------------------------------------------------------------------------------- 1 | # Aurae Vision 2 | 3 | The Aurae Project intends to make the right path, the easy path for application teams. 4 | 5 | I started not by asking what the industry was doing that seemed to be working, but rather asking the industry what they would chose to do again if given the chance to start over. 6 | My findings were surprising as I uncovered common themes. 7 | 8 | ### Guiding Principles 9 | 10 | Simplicity and opinions were the words I found myself repeating. I have taken these concepts and formed a number of actionable guiding principles. 11 | 12 | #### Opinionated Defaults, With Optional Replacements 13 | 14 | The Aurae standard library is a reflection of things people do, not things computers need. 15 | A problem with Kubernetes is that its flexibility became it's dysfunction. The system was vastly flexible, and vastly unopionated. 16 | Forming and holding an opinion on the implementation detail in Kubernetes became an unwritten ritual in building every aspect of a platform. 17 | 18 | Aurae reverses this paradigm. Aurae will form and maintain an opinion on what it considers to be sane, reasonable, and secure default opinions. 19 | These opinions, like all aspects of Aurae, will be modular and extensible. 20 | 21 | Each subsystem of Aurae will come with a default implementation that is completely replacable. 22 | 23 | #### Less is More 24 | 25 | When in doubt, simplify. 26 | 27 | Hold a thoughtful and validated opinion. The project prefers pleasant surprises in favor of counter productive magic. 28 | We never let a feature get in the way of usefulness. 29 | 30 | We prefer a single function with a powerful paradigm in favor of extension and modularity. Be thoughtful, but do not let thoughts stand between the user and elegance. 31 | 32 | #### Organic Libraries 33 | 34 | We prefer organic libraries over mechanistic structure. Expose what people need, however keep the core well structured. 35 | As the needs of the project grows we must carefully consider our APIs and do our best to prevent ourselves from re-creating POSIX and confusing systemcalls. 36 | 37 | #### Dialtone Security 38 | 39 | Aurae is designed to be a Distributed Operating System and act as a responsible `PID 1/init`. 40 | 41 | Security is something we should not compromise on. If Aurae is online, it must be default secure, and easy to keep secure by making doing the right thing either built-in, or straight forward and well documented. 42 | 43 | Every organization's threat model and appetite for risk is unique. Aurae is designed to mitigate risk through its architecture and implementation decisions. 44 | 45 | Decisions in Aurae are simple and transparent, allowing you to examine and understand the risk of Aurae and how it integrates with workloads under its control. 46 | -------------------------------------------------------------------------------- /accepted/001-docs.md: -------------------------------------------------------------------------------- 1 | # Design / Feature 2 | 3 | This feature will accomplish **feature** because **reason**. 4 | 5 | ### Outcomes 6 | 7 | - The outcome of this will be to allow **feature** to exist. 8 | - The outcome of **feature** will unlock **capability**. 9 | 10 | ### Goals 11 | 12 | - All **technology** will use **decision**. 13 | 14 | 15 | ### Decisions 16 | 17 | - The project will use **specific technology** to solve **specific problem** 18 | 19 | ### Notes 20 | 21 | - Context and notes 22 | 23 | 24 | ### Authors 25 | 26 | - [@kris-nova](https://github.com/kris-nova) 27 | -------------------------------------------------------------------------------- /accepted/002-node-authentication-authn.md: -------------------------------------------------------------------------------- 1 | # Proposal 002: Node Authentication 2 | 3 | This feature will add **Node Authentication**: 4 | 5 | This proposal only considers **identity** in the context of **membership**, not 6 | authorization. 7 | 8 | A summary of the authentication pattern is as follows: 9 | 10 | * An aurae node is a self-contained runtime environment. 11 | * An operator is an entity that controls an aurae node. 12 | * The aurae node acts as an automated agent for the operator. 13 | * The operator may choose to link the node to an OIDC identity through a 14 | successful challenge. 15 | 16 | ### Proposal 17 | All authentication with the aurae daemon will use "SSH Certificates". SSH 18 | Certificates are standard SSH keys that are also signed by an x509 certificate. 19 | 20 | Both server and client will be required to use signed SSH certificates. 21 | 22 | #### Bootstrapping in Detached Mode 23 | In detached mode, a CA will be generated by auraed. During initialization, a 24 | URL may be specified containing known SSH keys for bootstrapping purposes. The 25 | URL must be an encrypted endpoint with the URL's certificate chain verifiable 26 | using a CA in the client's keystore. 27 | 28 | A common candidate will be GitHub's keys URL. 29 | 30 | E.g. https://github.com/taniwha3.keys 31 | 32 | The operator may connect to auraed using the preconfigured SSH key and 33 | establish a new set of SSH Certificate credentials. 34 | 35 | Regardless of where the certificate is signed, the SSH-key component must be 36 | generated at the client or by an authorized device. The aurae daemon shall not 37 | generate client SSH keys, but may be involved with signing keys. 38 | 39 | ### Example Use Cases 40 | 41 | #### Detached Mode 42 | At its simplest, the operator should be able to instantiate auraed without any 43 | federation capabilities. This is useful for small one-off nodes, development, 44 | and air-gapped environments. A set of keys will be generated automatically for 45 | the node, but will not automatically be correlated with any external identity. 46 | 47 | ```mermaid 48 | sequenceDiagram 49 | activate Operator 50 | activate OS 51 | activate GitHub 52 | Operator->>OS: install auraed 53 | Operator->>OS: configure bootstrap URL 54 | Operator->>OS: run auraed 55 | OS->>auraed: auraed 56 | activate auraed 57 | OS-->>Operator: report aurae status 58 | auraed->>GitHub: fetch bootstrap ssh keys 59 | note over auraed: generate CA 60 | note over auraed: generate workload certificate 61 | note over auraed: enable one-time bootstrapping 62 | note over Operator: create SSH key 63 | Operator->>auraed: public SSH key 64 | note over auraed: sign the public SSH key 65 | auraed-->>Operator: signed certificate chain 66 | Operator-->>auraed: reconnect with new key 67 | deactivate auraed 68 | deactivate GitHub 69 | deactivate Operator 70 | deactivate OS 71 | ``` 72 | 73 | #### Federated mode 74 | The aurae deaemon may be correlated with an external identity by signing the 75 | SSH using PKI. 76 | 77 | ```mermaid 78 | sequenceDiagram 79 | activate Operator 80 | activate OS 81 | Operator->>OS: install auraed 82 | Operator->>OS: install Public CA certificate 83 | Operator->>OS: install Workload certificate 84 | Operator->>OS: run auraed 85 | OS->>auraed: auraed 86 | activate auraed 87 | OS-->>Operator: report aurae status 88 | Operator-->>auraed: connect in SSH Certificate Mode 89 | deactivate auraed 90 | deactivate Operator 91 | deactivate OS 92 | ``` 93 | 94 | 95 | 96 | #### Example metadata for a signed SSH key 97 | 98 | ``` 99 | Signing CA: RSA SHA256:zw3paTCfI3WFo9TfGuOZ75m0cQUK4g9MrwJZkrnwzR8 (using rsa-sha2-512) 100 | Key ID: "certid" 101 | Serial: 0 102 | Valid: forever 103 | Principals: (none) 104 | Critical Options: (none) 105 | Extensions: 106 | permit-X11-forwarding 107 | permit-agent-forwarding 108 | permit-port-forwarding 109 | permit-pty 110 | permit-user-rc 111 | ``` 112 | 113 | #### Relevant OpenSSH Configuraiton Parameters: 114 | ``` 115 | sshd_config: 116 | TrustedUserCAKeys 117 | HostKey 118 | HostCertificate 119 | 120 | known_hosts: 121 | @cert-authority 122 | ``` 123 | 124 | ### Outcomes 125 | 126 | The outcome of this will allow for: 127 | * An operator to authenticate themself to a node. 128 | * A node to authenticate itself to an operator. 129 | * A node may be registered to an OIDC identity, provable to any observer. 130 | 131 | 132 | ### Goals 133 | 134 | - Implement SSH Certificate authentication in auraed. 135 | 136 | ### Decisions 137 | 138 | - Aurae Daemon will use SSH Certificate Signing for all management 139 | authentication 140 | - An initial bootstrap may be used to establish SSH Certificate Signing 141 | when running in detached mode. 142 | 143 | ### Notes 144 | 145 | * At time of writing, it is not clear which entities 146 | will be observers capable of validating an OIDC identity. 147 | 148 | 149 | ### Authors 150 | 151 | - [@kris-nova](https://github.com/kris-nova) 152 | - [@tani](https://github.com/taniwha3) 153 | - [@orzen](https://github.com/orzen) 154 | -------------------------------------------------------------------------------- /accepted/003-workload.md: -------------------------------------------------------------------------------- 1 | # Workloads 2 | 3 | This architecture document calls out a proposal for how workloads should be managed and ran within aurae. 4 | 5 | ### Pods 6 | 7 | I am convinced that the best way to represent a workload with Aurae is to continue to use the Kubernetes **Pod** terminology. 8 | However unlike Kubernetes, Aurae Pods will be composed of the most fundamental runtime unit: a process, or a "proc". 9 | 10 | Pods are designed to be as isolated as possible by default. Aurae and subsequent Pods will be designed with the assumption that all other Pods in the system will be owned by unknown application owners. 11 | In other words, pods are multi-tenant by default. 12 | 13 | ### Process Types 14 | 15 | A process can be one of the following types: 16 | 17 | | Proc Type | Description | 18 | |------------- |------------------------------------------------------------------------------------------------ | 19 | | Exec | A system executable process, such as a binary or command line program. | 20 | | Container | A system container running in a cgroup namespace, such as a docker container. | 21 | | WAMR | A lightweight WASM runtime, such as a NodeJS application | 22 | 23 | More on [WAMR](https://github.com/bytecodealliance/wasm-micro-runtime). 24 | 25 | 26 | ## Subsystems 27 | 28 | This proposal begins to form the first 2 subsystems of Aurae: 29 | 30 | - Runtime 31 | - Observe 32 | 33 | Each subsystem will have independent access control at the function level. 34 | 35 | 36 | ### Example: Single Container Pod 37 | 38 | This script would replace a traditional `nginx.yaml` style manifest. 39 | 40 | ```typescript 41 | 42 | about(); 43 | 44 | let aurae = connect(); 45 | let runtime = aurae.runtime(); 46 | let observe = aurae.observe(); 47 | 48 | // Define a container 49 | let nginx = container("nginx-container-001"); 50 | nginx.image("nginx:latest"); 51 | nginx.expose(80); 52 | nginx.env("key", "val"); 53 | 54 | // Add to a Pod 55 | let ingress = pod("ingress-001"); 56 | ingress.add(nginx); 57 | 58 | // Run the pod 59 | runtime.run(ingress); 60 | 61 | // Tail the logs 62 | observe.logs(ingress); 63 | 64 | ``` 65 | 66 | ### Example: A Group of Executables 67 | 68 | Group together a set of system executables that run alongside a container in the same cgroup namespace. 69 | 70 | ```typescript 71 | 72 | about(); 73 | 74 | let aurae = connect(); 75 | let runtime = aurae.runtime(); 76 | let observe = aurae.observe(); 77 | 78 | // Define 1st executable 79 | let execA = exec("my-daemon"); 80 | execA.cmd("/bin/daemon"); 81 | execA.flag("--verbose", "true"); 82 | execA.arg("--daemon"); 83 | execA.arg("--watch"); 84 | 85 | let execB = exec("my-util"); 86 | execB.cmd("/bin/util"); 87 | 88 | // Add to a Pod 89 | let sysUtil = pod("system-util-001"); 90 | sysUtil.add(execA); 91 | sysUtil.add(execB); 92 | 93 | 94 | // Run the pod 95 | runtime.run(sysUtil); 96 | 97 | // Tail the logs 98 | observe.logs(sysUtil); 99 | 100 | ``` 101 | 102 | ### Authors 103 | 104 | - [@kris-nova](https://github.com/kris-nova) 105 | -------------------------------------------------------------------------------- /accepted/010-database.md: -------------------------------------------------------------------------------- 1 | # SQLite for Auraed 2 | 3 | This feature will accomplish **data persistency after reboots/restarts/failure** because **auraed is a systems daemon built for humans who often make mistakes**. 4 | 5 | ### Outcomes 6 | 7 | - Allow **persistent records** to exist after a daemon crash, failure. 8 | - Allow **persistent records** to exist atomicaly after a gRPC request return. 9 | - There will be a deliberate coupling between the gRPC server and the data layer/model. 10 | - Allow **encryption at rest** which can be unlocked using the `/etc/aurae/pki/server.key` (or a cryptographic hash) server key for the database. 11 | - Allow **joining** and **connecting** records and schemas. For example we should have a collection of `VirtualMachine` records, which need to be mapped to `NIC` records. 12 | - Allow **for a single database file** which can easily be backed up, recovered, and snapshotted for disaster recovery. 13 | - Alow **embedding** the database directly into the `auraed` daemon such that another server/client relationship does not need to be maintained, or such that auraed will scheduele the database directly. 14 | 15 | ### Goals 16 | 17 | - All **auraed** daemons will ship with this **database**. 18 | - All **auraed** daemons will have an upgrade/migration strategy of the data **in scope** for the entire project 19 | - All **aurae project** components will adhere to a version number that is indicitive of the data stored in this database and semver. 20 | - It will be impossible to recover a system without a key. 21 | - It will be impossible to access or mutate data without a key. 22 | 23 | ### Decisions 24 | 25 | - The project will use **SQLite** to serve as the most fundamental **storage layer**. 26 | - The project will encrypt the **SQLite** database according to the requirements above. 27 | - The project will reject any classes of database on a system other than a single "TEST" database which is managed by the source code. 28 | - There will be no concept of "dev" or "prod" data. 29 | - The project will attempt to couple the API definitions to the database schema. 30 | - The project will attempt to decouple an ORM on top of the core database. 31 | - The project will use **[SeaQL sea-orm](https://github.com/SeaQL/sea-orm)** for the ORM layer. 32 | 33 | ### Notes 34 | 35 | - The ORM layer is a low priority decision, that if implemented correctly should be relatively trivial to change. 36 | - The SQLite decision is a higher stakes decision, which is still relatively low-risk as it can be moved to another SQL compatible backend in the future. 37 | - The schema will need to be maintained in API alongside the protobuf definitions. Ideally we can come up with a way of cleanly mapping these without risk. 38 | 39 | ### Authors 40 | 41 | - [@kris-nova](https://github.com/kris-nova) 42 | --------------------------------------------------------------------------------