From 3dda316d1dc2d7c1572dae56cbc7185ff2b48c2d Mon Sep 17 00:00:00 2001 From: <> Date: Tue, 3 Jan 2023 20:41:58 +0000 Subject: [PATCH] Update documentation --- 404.html | 2 +- categories/index.html | 2 +- index.html | 2 +- ....a6e7ed4e82869b814f0c150b1a996998.min.json | 1 + linkmap | 60 +++++++++---------- requirements/index.html | 2 +- requirements/overview/index.html | 2 +- .../candidates/carnot/FAQ/index.html | 2 +- .../candidates/carnot/overview/index.html | 2 +- roadmap/consensus/candidates/claro/index.html | 2 +- .../consensus/development/overview/index.html | 2 +- .../development/prototypes/index.html | 2 +- roadmap/consensus/overview/index.html | 2 +- roadmap/consensus/theory/overview/index.html | 2 +- .../consensus/theory/snow-family/index.html | 2 +- roadmap/index.html | 2 +- .../carnot-waku-specification/index.html | 2 +- roadmap/networking/overview/index.html | 2 +- .../status-network-agents/index.html | 2 +- .../status-waku-kurtosis/index.html | 2 +- roadmap/page/2/index.html | 2 +- roadmap/virtual-machines/overview/index.html | 6 +- .../distributed-systems-researcher/index.html | 2 +- roles/index.html | 2 +- roles/rust-developer/index.html | 2 +- .../index.html | 2 +- sitemap.xml | 10 ++-- tags/Carnot/index.html | 2 +- tags/candidate/index.html | 2 +- tags/claro/index.html | 2 +- tags/consensus/index.html | 2 +- tags/development/index.html | 2 +- tags/engineering/index.html | 2 +- tags/index.html | 2 +- tags/networking/index.html | 2 +- tags/overview/index.html | 2 +- tags/requirements/index.html | 2 +- tags/role/index.html | 2 +- tags/rust/index.html | 2 +- tags/scalability/index.html | 2 +- tags/snow/index.html | 2 +- tags/status/index.html | 2 +- tags/theory/index.html | 2 +- tags/virtual-machines/index.html | 2 +- tags/waku/index.html | 2 +- tags/zero-knowledge/index.html | 2 +- 46 files changed, 81 insertions(+), 80 deletions(-) create mode 100644 indices/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json diff --git a/404.html b/404.html index f5ae7412c..458509070 100644 --- a/404.html +++ b/404.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/categories/index.html b/categories/index.html index 4abba7dbd..73de182e1 100644 --- a/categories/index.html +++ b/categories/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/index.html b/index.html index b63de129e..847484b62 100644 --- a/index.html +++ b/index.html @@ -103,7 +103,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/indices/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json b/indices/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json new file mode 100644 index 000000000..1a91d0493 --- /dev/null +++ b/indices/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json @@ -0,0 +1 @@ +{"/":{"title":"Nomos Technical Roadmap","content":"This site attempts to inform the previous, current, and future work required to fulfill the requirements of the Nomos Project [LINK TO NOMOS LANDING PAGE HERE], a complete tech stack that provides infrastructure for the self-sovereign network state. To learn more about the motivation, please visit the [Logos Collective Site](https://logos.co).\n\n## Navigation\n- [Network Requirements](requirements/overview.md)\n- Research and Development Roadmap\n\t- [Networking](roadmap/networking/overview.md)\n\t- [Consensus](roadmap/consensus/overview.md)\n\t- [Virtual Machines](roadmap/virtual-machines/overview.md)\n\t- Economics\n\t- Data Model\n\t- Applications / Wallets\n- Specifications\n- [Open Roles](tags/role)\n\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95":{"title":"CJK + Latex Support (测试)","content":"\n## Chinese, Japanese, Korean Support\n几乎在我们意识到之前，我们已经离开了地面。\n\n우리가 그것을 알기도 전에 우리는 땅을 떠났습니다.\n\n私たちがそれを知るほぼ前に、私たちは地面を離れていました。\n\n## Latex\n\nBlock math works with two dollar signs `$$...$$`\n\n$$f(x) = \\int_{-\\infty}^\\infty\n f\\hat(\\xi),e^{2 \\pi i \\xi x}\n \\,d\\xi$$\n\t\nInline math also works with single dollar signs `$...$`. For example, Euler's identity but inline: $e^{i\\pi} = 0$\n\nAligned equations work quite well:\n\n$$\n\\begin{aligned}\na \u0026= b + c \\\\ \u0026= e + f \\\\\n\\end{aligned}\n$$\n\nAnd matrices\n\n$$\n\\begin{bmatrix}\n1 \u0026 2 \u0026 3 \\\\\na \u0026 b \u0026 c\n\\end{bmatrix}\n$$\n\n## RTL\nMore information on configuring RTL languages like Arabic in the [config](config.md) page.\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/callouts":{"title":"Callouts","content":"\n## Callout support\n\nQuartz supports the same Admonition-callout syntax as Obsidian.\n\nThis includes\n- 12 Distinct callout types (each with several aliases)\n- Collapsable callouts\n\nSee [documentation on supported types and syntax here](https://help.obsidian.md/How+to/Use+callouts#Types).\n\n## Showcase\n\n\u003e [!EXAMPLE] Examples\n\u003e\n\u003e Aliases: example\n\n\u003e [!note] Notes\n\u003e\n\u003e Aliases: note\n\n\u003e [!abstract] Summaries \n\u003e\n\u003e Aliases: abstract, summary, tldr\n\n\u003e [!info] Info \n\u003e\n\u003e Aliases: info, todo\n\n\u003e [!tip] Hint \n\u003e\n\u003e Aliases: tip, hint, important\n\n\u003e [!success] Success \n\u003e\n\u003e Aliases: success, check, done\n\n\u003e [!question] Question \n\u003e\n\u003e Aliases: question, help, faq\n\n\u003e [!warning] Warning \n\u003e\n\u003e Aliases: warning, caution, attention\n\n\u003e [!failure] Failure \n\u003e\n\u003e Aliases: failure, fail, missing\n\n\u003e [!danger] Error\n\u003e\n\u003e Aliases: danger, error\n\n\u003e [!bug] Bug\n\u003e\n\u003e Aliases: bug\n\n\u003e [!quote] Quote\n\u003e\n\u003e Aliases: quote, cite\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/config":{"title":"Configuration","content":"\n## Configuration\nQuartz is designed to be extremely configurable. You can find the bulk of the configuration scattered throughout the repository depending on how in-depth you'd like to get.\n\nThe majority of configuration can be found under `data/config.yaml`. An annotated example configuration is shown below.\n\n```yaml {title=\"data/config.yaml\"}\n# The name to display in the footer\nname: Jacky Zhao\n\n# whether to globally show the table of contents on each page\n# this can be turned off on a per-page basis by adding this to the\n# front-matter of that note\nenableToc: true\n\n# whether to by-default open or close the table of contents on each page\nopenToc: false\n\n# whether to display on-hover link preview cards\nenableLinkPreview: true\n\n# whether to render titles for code blocks\nenableCodeBlockTitle: true \n\n# whether to render copy buttons for code blocks\nenableCodeBlockCopy: true \n\n# whether to render callouts\nenableCallouts: true\n\n# whether to try to process Latex\nenableLatex: true\n\n# whether to enable single-page-app style rendering\n# this prevents flashes of unstyled content and improves\n# smoothness of Quartz. More info in issue #109 on GitHub\nenableSPA: true\n\n# whether to render a footer\nenableFooter: true\n\n# whether backlinks of pages should show the context in which\n# they were mentioned\nenableContextualBacklinks: true\n\n# whether to show a section of recent notes on the home page\nenableRecentNotes: false\n\n# whether to display an 'edit' button next to the last edited field\n# that links to github\nenableGitHubEdit: true\nGitHubLink: https://github.com/jackyzha0/quartz/tree/hugo/content\n\n# whether to use Operand to power semantic search\n# IMPORTANT: replace this API key with your own if you plan on using\n# Operand search!\nenableSemanticSearch: false\noperandApiKey: \"REPLACE-WITH-YOUR-OPERAND-API-KEY\"\n\n# page description used for SEO\ndescription:\n Host your second brain and digital garden for free. Quartz features extremely fast full-text search,\n Wikilink support, backlinks, local graph, tags, and link previews.\n\n# title of the home page (also for SEO)\npage_title:\n \"🪴 Quartz 3.2\"\n\n# links to show in the footer\nlinks:\n - link_name: Twitter\n link: https://twitter.com/_jzhao\n - link_name: Github\n link: https://github.com/jackyzha0\n```\n\n### Code Block Titles\nTo add code block titles with Quartz:\n\n1. Ensure that code block titles are enabled in Quartz's configuration:\n\n ```yaml {title=\"data/config.yaml\", linenos=false}\n enableCodeBlockTitle: true\n ```\n\n2. Add the `title` attribute to the desired [code block\n fence](https://gohugo.io/content-management/syntax-highlighting/#highlighting-in-code-fences):\n\n ```markdown {linenos=false}\n ```yaml {title=\"data/config.yaml\"}\n enableCodeBlockTitle: true # example from step 1\n ```\n ```\n\n**Note** that if `{title=\u003cmy-title\u003e}` is included, and code block titles are not\nenabled, no errors will occur, and the title attribute will be ignored.\n\n### HTML Favicons\nIf you would like to customize the favicons of your Quartz-based website, you \ncan add them to the `data/config.yaml` file. The **default** without any set \n`favicon` key is:\n\n```html {title=\"layouts/partials/head.html\", linenostart=15}\n\u003clink rel=\"shortcut icon\" href=\"icon.png\" type=\"image/png\"\u003e\n```\n\nThe default can be overridden by defining a value to the `favicon` key in your \n`data/config.yaml` file. For example, here is a `List[Dictionary]` example format, which is\nequivalent to the default:\n\n```yaml {title=\"data/config.yaml\", linenos=false}\nfavicon:\n - { rel: \"shortcut icon\", href: \"icon.png\", type: \"image/png\" }\n# - { ... } # Repeat for each additional favicon you want to add\n```\n\nIn this format, the keys are identical to their HTML representations.\n\nIf you plan to add multiple favicons generated by a website (see list below), it\nmay be easier to define it as HTML. Here is an example which appends the \n**Apple touch icon** to Quartz's default favicon:\n\n```yaml {title=\"data/config.yaml\", linenos=false}\nfavicon: |\n \u003clink rel=\"shortcut icon\" href=\"icon.png\" type=\"image/png\"\u003e\n \u003clink rel=\"apple-touch-icon\" sizes=\"180x180\" href=\"/apple-touch-icon.png\"\u003e\n```\n\nThis second favicon will now be used as a web page icon when someone adds your \nwebpage to the home screen of their Apple device. If you are interested in more \ninformation about the current and past standards of favicons, you can read \n[this article](https://www.emergeinteractive.com/insights/detail/the-essentials-of-favicons/).\n\n**Note** that all generated favicon paths, defined by the `href` \nattribute, are relative to the `static/` directory.\n\n### Graph View\nTo customize the Interactive Graph view, you can poke around `data/graphConfig.yaml`.\n\n```yaml {title=\"data/graphConfig.yaml\"}\n# if true, a Global Graph will be shown on home page with full width, no backlink.\n# A different set of Local Graphs will be shown on sub pages.\n# if false, Local Graph will be default on every page as usual\nenableGlobalGraph: false\n\n### Local Graph ###\nlocalGraph:\n # whether automatically generate a legend\n enableLegend: false\n \n # whether to allow dragging nodes in the graph\n enableDrag: true\n \n # whether to allow zooming and panning the graph\n enableZoom: true\n \n # how many neighbours of the current node to show (-1 is all nodes)\n depth: 1\n \n # initial zoom factor of the graph\n scale: 1.2\n \n # how strongly nodes should repel each other\n repelForce: 2\n\n # how strongly should nodes be attracted to the center of gravity\n centerForce: 1\n\n # what the default link length should be\n linkDistance: 1\n \n # how big the node labels should be\n fontSize: 0.6\n \n # scale at which to start fading the labes on nodes\n opacityScale: 3\n\n### Global Graph ###\nglobalGraph:\n\t# same settings as above\n\n### For all graphs ###\n# colour specific nodes path off of their path\npaths:\n - /moc: \"#4388cc\"\n```\n\n\n## Styling\nWant to go even more in-depth? You can add custom CSS styling and change existing colours through editing `assets/styles/custom.scss`. If you'd like to target specific parts of the site, you can add ids and classes to the HTML partials in `/layouts/partials`. \n\n### Partials\nPartials are what dictate what gets rendered to the page. Want to change how pages are styled and structured? You can edit the appropriate layout in `/layouts`.\n\nFor example, the structure of the home page can be edited through `/layouts/index.html`. To customize the footer, you can edit `/layouts/partials/footer.html`\n\nMore info about partials on [Hugo's website.](https://gohugo.io/templates/partials/)\n\nStill having problems? Checkout our [FAQ and Troubleshooting guide](troubleshooting.md).\n\n## Language Support\n[CJK + Latex Support (测试)](CJK%20+%20Latex%20Support%20(测试).md) comes out of the box with Quartz.\n\nWant to support languages that read from right-to-left (like Arabic)? Hugo (and by proxy, Quartz) supports this natively.\n\nFollow the steps [Hugo provides here](https://gohugo.io/content-management/multilingual/#configure-languages) and modify your `config.toml`\n\nFor example:\n\n```toml\ndefaultContentLanguage = 'ar'\n[languages]\n [languages.ar]\n languagedirection = 'rtl'\n title = 'مدونتي'\n weight = 1\n```\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/custom-Domain":{"title":"Custom Domain","content":"\n### Registrar\nThis step is only applicable if you are using a **custom domain**! If you are using a `\u003cYOUR-USERNAME\u003e.github.io` domain, you can skip this step.\n\nFor this last bit to take effect, you also need to create a CNAME record with the DNS provider you register your domain with (i.e. NameCheap, Google Domains).\n\nGitHub has some [documentation on this](https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site), but the tldr; is to\n\n1. Go to your forked repository (`github.com/\u003cYOUR-GITHUB-USERNAME\u003e/quartz`) settings page and go to the Pages tab. Under \"Custom domain\", type your custom domain, then click **Save**.\n2. Go to your DNS Provider and create a CNAME record that points from your domain to `\u003cYOUR-GITHUB-USERNAME.github.io.` (yes, with the trailing period).\n\n\t![Example Configuration for Quartz](google-domains.png)*Example Configuration for Quartz*\n3. Wait 30 minutes to an hour for the network changes to kick in.\n4. Done!","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/editing":{"title":"Editing Content in Quartz","content":"\n## Editing \nQuartz runs on top of [Hugo](https://gohugo.io/) so all notes are written in [Markdown](https://www.markdownguide.org/getting-started/).\n\n### Folder Structure\nHere's a rough overview of what's what.\n\n**All content in your garden can found in the `/content` folder.** To make edits, you can open any of the files and make changes directly and save it. You can organize content into any folder you'd like.\n\n**To edit the main home page, open `/content/_index.md`.**\n\nTo create a link between notes in your garden, just create a normal link using Markdown pointing to the document in question. Please note that **all links should be relative to the root `/content` path**. \n\n```markdown\nFor example, I want to link this current document to `notes/config.md`.\n[A link to the config page](notes/config.md)\n```\n\nSimilarly, you can put local images anywhere in the `/content` folder.\n\n```markdown\nExample image (source is in content/notes/images/example.png)\n![Example Image](/content/notes/images/example.png)\n```\n\nYou can also use wikilinks if that is what you are more comfortable with!\n\n### Front Matter\nHugo is picky when it comes to metadata for files. Make sure that your title is double-quoted and that you have a title defined at the top of your file like so. You can also add tags here as well.\n\n```yaml\n---\ntitle: \"Example Title\"\ntags:\n- example-tag\n---\n\nRest of your content here...\n```\n\n### Obsidian\nI recommend using [Obsidian](http://obsidian.md/) as a way to edit and grow your digital garden. It comes with a really nice editor and graphical interface to preview all of your local files.\n\nThis step is **highly recommended**.\n\n\u003e 🔗 Step 3: [How to setup your Obsidian Vault to work with Quartz](obsidian.md)\n\n## Previewing Changes\nThis step is purely optional and mostly for those who want to see the published version of their digital garden locally before opening it up to the internet. This is *highly recommended* but not required.\n\n\u003e 👀 Step 4: [Preview Quartz Changes](preview%20changes.md)\n\nFor those who like to live life more on the edge, viewing the garden through Obsidian gets you pretty close to the real thing.\n\n## Publishing Changes\nNow that you know the basics of managing your digital garden using Quartz, you can publish it to the internet!\n\n\u003e 🌍 Step 5: [Hosting Quartz online!](hosting.md)\n\nHaving problems? Checkout our [FAQ and Troubleshooting guide](troubleshooting.md).\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/hosting":{"title":"Deploying Quartz to the Web","content":"\n## Hosting on GitHub Pages\nQuartz is designed to be effortless to deploy. If you forked and cloned Quartz directly from the repository, everything should already be good to go! Follow the steps below.\n\n### Enable GitHub Actions\nBy default, GitHub disables workflows from running automatically on Forked Repostories. Head to the 'Actions' tab of your forked repository and Enable Workflows to setup deploying your Quartz site!\n\n![Enable GitHub Actions](github-actions.png)*Enable GitHub Actions*\n\n### Enable GitHub Pages\n\nHead to the 'Settings' tab of your forked repository and go to the 'Pages' tab.\n\n1. (IMPORTANT) Set the source to deploy from `master` (and not `hugo`) using `/ (root)`\n2. Set a custom domain here if you have one!\n\n![Enable GitHub Pages](github-pages.png)*Enable GitHub Pages*\n\n### Pushing Changes\nTo see your changes on the internet, we need to push it them to GitHub. Quartz is a `git` repository so updating it is the same workflow as you would follow as if it were just a regular software project.\n\n```shell\n# Navigate to Quartz folder\ncd \u003cpath-to-quartz\u003e\n\n# Commit all changes\ngit add .\ngit commit -m \"message describing changes\"\n\n# Push to GitHub to update site\ngit push origin hugo\n```\n\nNote: we specifically push to the `hugo` branch here. Our GitHub action automatically runs everytime a push to is detected to that branch and then updates the `master` branch for redeployment.\n\n### Setting up the Site\nNow let's get this site up and running. Never hosted a site before? No problem. Have a fancy custom domain you already own or want to subdomain your Quartz? That's easy too.\n\nHere, we take advantage of GitHub's free page hosting to deploy our site. Change `baseURL` in `/config.toml`. \n\nMake sure that your `baseURL` has a trailing `/`!\n\n[Reference `config.toml` here](https://github.com/jackyzha0/quartz/blob/hugo/config.toml)\n\n```toml\nbaseURL = \"https://\u003cYOUR-DOMAIN\u003e/\"\n```\n\nIf you are using this under a subdomain (e.g. `\u003cYOUR-GITHUB-USERNAME\u003e.github.io/quartz`), include the trailing `/`. **You need to do this especially if you are using GitHub!**\n\n```toml\nbaseURL = \"https://\u003cYOUR-GITHUB-USERNAME\u003e.github.io/quartz/\"\n```\n\nChange `cname` in `/.github/workflows/deploy.yaml`. Again, if you don't have a custom domain to use, you can use `\u003cYOUR-USERNAME\u003e.github.io`.\n\nPlease note that the `cname` field should *not* have any path `e.g. end with /quartz` or have a trailing `/`.\n\n[Reference `deploy.yaml` here](https://github.com/jackyzha0/quartz/blob/hugo/.github/workflows/deploy.yaml)\n\n```yaml {title=\".github/workflows/deploy.yaml\"}\n- name: Deploy \n uses: peaceiris/actions-gh-pages@v3 \n with: \n\tgithub_token: ${{ secrets.GITHUB_TOKEN }} # this can stay as is, GitHub fills this in for us!\n\tpublish_dir: ./public \n\tpublish_branch: master\n\tcname: \u003cYOUR-DOMAIN\u003e\n```\n\nHave a custom domain? [Learn how to set it up with Quartz ](custom%20Domain.md).\n\n### Ignoring Files\nOnly want to publish a subset of all of your notes? Don't worry, Quartz makes this a simple two-step process.\n\n❌ [Excluding pages from being published](ignore%20notes.md)\n\n---\n\nNow that your Quartz is live, let's figure out how to make Quartz really *yours*!\n\n\u003e Step 6: 🎨 [Customizing Quartz](config.md)\n\nHaving problems? Checkout our [FAQ and Troubleshooting guide](troubleshooting.md).\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/ignore-notes":{"title":"Ignoring Notes","content":"\n### Quartz Ignore\nEdit `ignoreFiles` in `config.toml` to include paths you'd like to exclude from being rendered.\n\n```toml\n...\nignoreFiles = [ \n \"/content/templates/*\", \n \"/content/private/*\", \n \"\u003cyour path here\u003e\"\n]\n```\n\n`ignoreFiles` supports the use of Regular Expressions (RegEx) so you can ignore patterns as well (e.g. ignoring all `.png`s by doing `\\\\.png$`).\nTo ignore a specific file, you can also add the tag `draft: true` to the frontmatter of a note.\n\n```markdown\n---\ntitle: Some Private Note\ndraft: true\n---\n...\n```\n\nMore details in [Hugo's documentation](https://gohugo.io/getting-started/configuration/#ignore-content-and-data-files-when-rendering).\n\n### Global Ignore\nHowever, just adding to the `ignoreFiles` will only prevent the page from being access through Quartz. If you want to prevent the file from being pushed to GitHub (for example if you have a public repository), you need to also add the path to the `.gitignore` file at the root of the repository.","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/obsidian":{"title":"Obsidian Vault Integration","content":"\n## Setup\nObsidian is the preferred way to use Quartz. You can either create a new Obsidian Vault or link one that your already have.\n\n### New Vault\nIf you don't have an existing Vault, [download Obsidian](https://obsidian.md/) and create a new Vault in the `/content` folder that you created and cloned during the [setup](setup.md) step.\n\n### Linking an existing Vault\nThe easiest way to use an existing Vault is to copy all of your files (directory and hierarchies intact) into the `/content` folder.\n\n## Settings\nGreat, now that you have your Obsidian linked to your Quartz, let's fix some settings so that they play well.\n\n1. Under Options \u003e Files and Links, set the New link format to always use Absolute Path in Vault.\n2. Go to Settings \u003e Files \u0026 Links \u003e Turn \"on\" automatically update internal links.\n\n![Obsidian Settings](obsidian-settings.png)*Obsidian Settings*\n\n## Templates\nInserting front matter everytime you want to create a new Note gets annoying really quickly. Luckily, Obsidian supports templates which makes inserting new content really easily.\n\n**If you decide to overwrite the `/content` folder completely, don't remove the `/content/templates` folder!**\n\nHead over to Options \u003e Core Plugins and enable the Templates plugin. Then go to Options \u003e Hotkeys and set a hotkey for 'Insert Template' (I recommend `[cmd]+T`). That way, when you create a new note, you can just press the hotkey for a new template and be ready to go!\n\n\u003e 👀 Step 4: [Preview Quartz Changes](preview%20changes.md)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/philosophy":{"title":"Quartz Philosophy","content":"\n\u003e “[One] who works with the door open gets all kinds of interruptions, but [they] also occasionally gets clues as to what the world is and what might be important.” — Richard Hamming\n\n## Why Quartz?\nHosting a public digital garden isn't easy. There are an overwhelming number of tutorials, resources, and guides for tools like [Notion](https://www.notion.so/), [Roam](https://roamresearch.com/), and [Obsidian](https://obsidian.md/), yet none of them have super easy to use *free* tools to publish that garden to the world.\n\nI've personally found that\n1. It's nice to access notes from anywhere\n2. Having a public digital garden invites open conversations\n3. It makes keeping personal notes and knowledge *playful and fun*\n\nI was really inspired by [Bianca](https://garden.bianca.digital/) and [Joel](https://joelhooks.com/digital-garden)'s digital gardens and wanted to try making my own.\n\n**The goal of Quartz is to make hosting your own public digital garden free and simple.** You don't even need your own website. Quartz does all of that for you and gives your own little corner of the internet.\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/preview-changes":{"title":"Preview Changes","content":"\nIf you'd like to preview what your Quartz site looks like before deploying it to the internet, here's exactly how to do that!\n\nNote that both of these steps need to be completed.\n\n## Install `hugo-obsidian`\nThis step will generate the list of backlinks for Hugo to parse. Ensure you have [Go](https://golang.org/doc/install) (\u003e= 1.16) installed.\n\n```bash\n# Install and link `hugo-obsidian` locally\ngo install github.com/jackyzha0/hugo-obsidian@latest\n```\n\nIf you are running into an error saying that `command not found: hugo-obsidian`, make sure you set your `GOPATH` correctly! This will allow your terminal to correctly recognize hugo-obsidian as an executable.\n\nAfterwards, start the Hugo server as shown above and your local backlinks and interactive graph should be populated!\n\n## Installing Hugo\nHugo is the static site generator that powers Quartz. [Install Hugo with \"extended\" Sass/SCSS version](https://gohugo.io/getting-started/installing/) first. Then,\n\n```bash\n# Navigate to your local Quartz folder\ncd \u003clocation-of-your-local-quartz\u003e\n\n# Start local server\nmake serve\n\n# View your site in a browser at http://localhost:1313/\n```\n\n\u003e 🌍 Step 5: [Hosting Quartz online!](hosting.md)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/search":{"title":"Search","content":"\nQuartz supports two modes of searching through content.\n\n## Full-text\nFull-text search is the default in Quartz. It produces results that *exactly* match the search query. This is easier to setup but usually produces lower quality matches.\n\n```yaml {title=\"data/config.yaml\"}\n# the default option\nenableSemanticSearch: false\n```\n\n## Natural Language\nNatural language search is powered by [Operand](https://operand.ai/). It understands language like a person does and finds results that best match user intent. In this sense, it is closer to how Google Search works.\n\nNatural language search tends to produce higher quality results than full-text search.\n\nHere's how to set it up.\n\n1. Create an Operand Account on [their website](https://operand.ai/).\n2. Go to Dashboard \u003e Settings \u003e Integrations.\n3. Follow the steps to setup the GitHub integration. Operand needs access to GitHub in order to index your digital garden properly!\n4. Head over to Dashboard \u003e Objects and press `(Cmd + K)` to open the omnibar and select 'Create Collection'.\n\t1. Set the 'Collection Label' to something that will help you remember it.\n\t2. You can leave the 'Parent Collection' field empty.\n5. Click into your newly made Collection.\n\t1. Press the 'share' button that looks like three dots connected by lines.\n\t2. Set the 'Interface Type' to `object-search` and click 'Create'.\n\t3. This will bring you to a new page with a search bar. Ignore this for now.\n6. Go back to Dashboard \u003e Settings \u003e API Keys and find your Quartz-specific Operand API key under 'Other keys'.\n\t1. Copy the key (which looks something like `0e733a7f-9b9c-48c6-9691-b54fa1c8b910`).\n\t2. Open `data/config.yaml`. Set `enableSemanticSearch` to `true` and `operandApiKey` to your copied key.\n\n```yaml {title=\"data/config.yaml\"}\n# the default option\nenableSemanticSearch: true\noperandApiKey: \"0e733a7f-9b9c-48c6-9691-b54fa1c8b910\"\n```\n7. Make a commit and push your changes to GitHub. See the [[hosting|hosting]] page if you haven't done this already.\n\t1. This step is *required* for Operand to be able to properly index your content. \n\t2. Head over to Dashboard \u003e Objects and select the collection that you made earlier\n8. Press `(Cmd + K)` to open the omnibar again and select 'Create GitHub Repo'\n\t1. Set the 'Repository Label' to `Quartz`\n\t2. Set the 'Repository Owner' to your GitHub username\n\t3. Set the 'Repository Ref' to `master`\n\t4. Set the 'Repository Name' to the name of your repository (usually just `quartz` if you forked the repository without changing the name)\n\t5. Leave 'Root Path' and 'Root URL' empty\n9. Wait for your repository to index and enjoy natural language search in Quartz! Operand refreshes the index every 2h so all you need to do is just push to GitHub to update the contents in the search.","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/setup":{"title":"Setup","content":"\n## Making your own Quartz\nSetting up Quartz requires a basic understanding of `git`. If you are unfamiliar, [this resource](https://resources.nwplus.io/2-beginner/how-to-git-github.html) is a great place to start!\n\n### Forking\n\u003e A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project.\n\nNavigate to the GitHub repository for the Quartz project:\n\n📁 [Quartz Repository](https://github.com/jackyzha0/quartz)\n\nThen, Fork the repository into your own GitHub account. If you don't have an account, you can make on for free [here](https://github.com/join). More details about forking a repo can be found on [GitHub's documentation](https://docs.github.com/en/get-started/quickstart/fork-a-repo).\n\n### Cloning\nAfter you've made a fork of the repository, you need to download the files locally onto your machine. Ensure you have `git`, then type the following command replacing `YOUR-USERNAME` with your GitHub username.\n\n```shell\ngit clone https://github.com/YOUR-USERNAME/quartz\n```\n\n## Editing\nGreat! Now you have everything you need to start editing and growing your digital garden. If you're ready to start writing content already, check out the recommended flow for editing notes in Quartz.\n\n\u003e ✏️ Step 2: [Editing Notes in Quartz](editing.md)\n\nHaving problems? Checkout our [FAQ and Troubleshooting guide](troubleshooting.md).\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/showcase":{"title":"Showcase","content":"\nWant to see what Quartz can do? Here are some cool community gardens :)\n\n- [Quartz Documentation (this site!)](https://quartz.jzhao.xyz/)\n- [Jacky Zhao's Garden](https://jzhao.xyz/)\n- [Scaling Synthesis - A hypertext research notebook](https://scalingsynthesis.com/)\n- [AWAGMI Intern Notes](https://notes.awagmi.xyz/)\n- [Shihyu's PKM](https://shihyuho.github.io/pkm/)\n- [Chloe's Garden](https://garden.chloeabrasada.online/)\n- [SlRvb's Site](https://slrvb.github.io/Site/)\n- [Course notes for Information Technology Advanced Theory](https://a2itnotes.github.io/quartz/)\n- [Brandon Boswell's Garden](https://brandonkboswell.com)\n- [Siyang's Courtyard](https://siyangsun.github.io/courtyard/)\n\nIf you want to see your own on here, submit a [Pull Request adding yourself to this file](https://github.com/jackyzha0/quartz/blob/hugo/content/notes/showcase.md)!\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/troubleshooting":{"title":"Troubleshooting and FAQ","content":"\nStill having trouble? Here are a list of common questions and problems people encounter when installing Quartz.\n\nWhile you're here, join our [Discord](https://discord.gg/cRFFHYye7t) :)\n\n### Does Quartz have Latex support?\nYes! See [CJK + Latex Support (测试)](CJK%20+%20Latex%20Support%20(测试).md) for a brief demo.\n\n### Can I use \\\u003cObsidian Plugin\\\u003e in Quartz?\nUnless it produces direct Markdown output in the file, no. There currently is no way to bundle plugin code with Quartz.\n\nThe easiest way would be to add your own HTML partial that supports the functionality you are looking for.\n\n### My GitHub pages is just showing the README and not Quartz\nMake sure you set the source to deploy from `master` (and not `hugo`) using `/ (root)`! See more in the [hosting](hosting.md) guide\n\n### Some of my pages have 'January 1, 0001' as the last modified date\nThis is a problem caused by `git` treating files as case-insensitive by default and some of your posts probably have capitalized file names. You can turn this off in your Quartz by running this command.\n\n```shell\n# in the root of your Quartz (same folder as config.toml)\ngit config core.ignorecase true\n\n# or globally (not recommended)\ngit config --global core.ignorecase true\n```\n\n### Can I publish only a subset of my pages?\nYes! Quartz makes selective publishing really easy. Heres a guide on [excluding pages from being published](ignore%20notes.md).\n\n### Can I host this myself and not on GitHub Pages?\nYes! All built files can be found under `/public` in the `master` branch. More details under [hosting](hosting.md).\n\n### `command not found: hugo-obsidian`\nMake sure you set your `GOPATH` correctly! This will allow your terminal to correctly recognize `hugo-obsidian` as an executable.\n\n```shell\n# Add the following 2 lines to your ~/.bash_profile\nexport GOPATH=/Users/$USER/go\nexport PATH=$GOPATH/bin:$PATH\n\n# In your current terminal, to reload the session\nsource ~/.bash_profile\n```\n\n### How come my notes aren't being rendered?\nYou probably forgot to include front matter in your Markdown files. You can either setup [Obsidian](obsidian.md) to do this for you or you need to manually define it. More details in [the 'how to edit' guide](editing.md).\n\n### My custom domain isn't working!\nWalk through the steps in [the hosting guide](hosting.md) again. Make sure you wait 30 min to 1 hour for changes to take effect.\n\n### How do I setup Google Analytics?\nYou can edit it in `config.toml` and either use a V3 (UA-) or V4 (G-) tag.\n\n### How do I change the content on the home page?\nTo edit the main home page, open `/content/_index.md`.\n\n### How do I change the colours?\nYou can change the theme by editing `assets/custom.scss`. More details on customization and themeing can be found in the [customization guide](config.md).\n\n### How do I add images?\nYou can put images anywhere in the `/content` folder.\n\n```markdown\nExample image (source is in content/notes/images/example.png)\n![Example Image](/content/notes/images/example.png)\n```\n\n### My Interactive Graph and Backlinks aren't up to date\nBy default, the `linkIndex.json` (which Quartz needs to generate the Interactive Graph and Backlinks) are not regenerated locally. To set that up, see the guide on [local editing](editing.md)\n\n### Can I use React/Vue/some other framework?\nNot out of the box. You could probably make it work by editing `/layouts/_default/single.html` but that's not what Quartz is designed to work with. 99% of things you are trying to do with those frameworks you can accomplish perfectly fine using just vanilla HTML/CSS/JS.\n\n## Still Stuck?\nQuartz isn't perfect! If you're still having troubles, file an issue in the GitHub repo with as much information as you can reasonably provide. Alternatively, you can message me on [Twitter](https://twitter.com/_jzhao) and I'll try to get back to you as soon as I can.\n\n🐛 [Submit an Issue](https://github.com/jackyzha0/quartz/issues)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/private/notes/updating":{"title":"Updating","content":"\nHaven't updated Quartz in a while and want all the cool new optimizations? On Unix/Mac systems you can run the following command for a one-line update! This command will show you a log summary of all commits since you last updated, press `q` to acknowledge this. Then, it will show you each change in turn and press `y` to accept the patch or `n` to reject it. Usually you should press `y` for most of these unless it conflicts with existing changes you've made! \n\n```shell\nmake update\n```\n\nOr, if you don't want the interactive parts and just want to force update your local garden (this assumed that you are okay with some of your personalizations been overriden!)\n\n```shell\nmake update-force\n```\n\nOr, manually checkout the changes yourself.\n\n\u003e [!warning] Warning!\n\u003e\n\u003e If you customized the files in `data/`, or anything inside `layouts/`, your customization may be overwritten!\n\u003e Make sure you have a copy of these changes if you don't want to lose them.\n\n\n```shell\n# add Quartz as a remote host\ngit remote add upstream git@github.com:jackyzha0/quartz.git\n\n# index and fetch changes\ngit fetch upstream\ngit checkout -p upstream/hugo -- layouts .github Makefile assets/js assets/styles/base.scss assets/styles/darkmode.scss config.toml data \n```\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/requirements/overview":{"title":"Logos Network Requirements Overview","content":"\nThis document describes the requirements of the Logos Network.\n\n\u003e Network sovereignty is an extension of the collective sovereignty of the individuals within. \n\n\u003e Meaningful participation in the network should be acheivable by affordable and accessible consumer grade hardware.\n\n\u003e Privacy by default. \n\n\u003e A given CiC should have the option to gracefully exit the network and operate on its own.\n\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/candidates/carnot/FAQ":{"title":"Frequently Asked Questions","content":"\n## Network Requirements and Assumptions\n\n### What assumptions do we need Waku to fulfill? - Corey\n\u003e `Moh:` Waku needs to fill the following requirements, taken from the Carnot paper:\n\n\u003e **Definition 3** (Probabilistic Reliable Dissemination). _After the GST, and when the leader is correct, all the correct nodes deliver the proposal sent by the leader (w.h.p)._\n\n\u003e **Definition 4** (Probabilistic Fulfillment). _After the GST, and when the current and previous leaders are correct, the number of votes collected by teh current leader is $2c+1$ (w.h.p)._\n\n## Data Distribution\n\n### How much failure rate of erasure code transmission are we expecting. Basically, what are the EC coding parameters that we expect to be sending such that we have some failure rate of transmission? Has that been looked into? - Dmitriy\n\u003e `Moh:` This is a great question and it points to the tension between the failure rate vs overhead. We have briefly looked into this (today me and Marcin @madxor discussed such cases), but we haven’t thoroughly analyzed this. In our case, the rate of failure also depends on committee size. We look into $10^{-3}$ to $10^{-6}$ probability of failure. And in this case, the coding overhead can be somewhere between 200%-500% approximately. This means for a committee size of 500 (while expecting receipt of messages from 251 correct nodes), for a failure rate of $10^{-6}$ a single node has to send \u003e 6Mb of data for a 1Mb of actual data. Though 5x overhead is large, it still prevent us from sending/receiving 500 Mb of data in return for a failure probability of 1 proposal out of 1 million. From the protocol perspective, we can address EC failures in multiple ways: a: Since the root committee only forwards the coded chunks only when they have successfully rebuilt the block. This means the root committee can be contacted to download additional coded chunks to decode the block. b: We allow this failure and let the leader be replaced but since there is proof that the failure is due to the reason that a decoder failed to reconstruct the block, therefore, the leader cannot be punished (if we chose to employ punishment in PoS). \n\n### How much data should a given block be. Are there limits on this and if so, what are they and what do they depend on? - Dmitriy\n\u003e `Moh:` This question can be answered during simulations and experiments over links of different bandwidths and latencies. We will test the protocol performances with different block sizes. As we know increasing the block size results in increased throughput as well as latency. What is the most appropriate block size can be determined once we observe the tradeoff between throughput vs latency.\n\n## Signature Propagation\n\n### Who sends the signatures up from a given committee? Do that have any leadered power within the committee? - Tanguy\n\u003e `Moh:` Each node in a committee multicasts its vote to all members of the parent committee. Since the size of the vote is small the bit complexity will be low. Introducing a leader within each committee will create a single point of failure within each committee. This is why we avoid maintaining a leader within each committee\n\n## Network Scale\n\n### What is our expected minimum number of nodes within the network? - Dmitriy\n\u003e `Moh:` For a small number of nodes we can have just a single committee. But I am not sure how many nodes will join our network \n\n## Byzantine Behavior\n\n### Can we also consider a flavor that adds attestation/attribution to misbehaving nodes? That will come at a price but there might be a set of use cases which would like to have lower performance with strong attribution. Not saying that it must be part of the initial design, but can be think-through/added later. - Marcin\n\u003e `Moh:` Attestation to misbehaving nodes is part of this protocol. For example, if a node sends an incorrect vote or if a leader proposes an invalid transaction, then this proof will be shared with the network to punish the misbehaving nodes (Though currently this is not part of pseudocode). But it is not possible to reliably prove the attestation of not participation.\n\n\u003e `Marcin:` Great, and definitely, we cannot attest that a node was not participating - I was not suggesting that;). But we can also think about extending the attestation for lazy-participants case (if it’s not already part of the protocol).\n\n\u003e `Moh:` OK, thanks for the clarification 😁 . Of course we can have this feature to forward the proof of participation of successor committees. In the first version of Carnot we had this feature as a sliding window. One could choose the size of the window (in terms of tree levels) for which a node should forward the proof of participation. In the most recent version the size of sliding window is 0. And it is 1 for the root committee. It means root committee members have to forward the proof of participation of their child committee members. Since I was able to prove protocol correctness without forwarding the proofs so we avoid it. But it can be part of the protocol without any significant changes in the protocol\n\n\u003e If the proof scheme is efficient ( as the results you presented) in practice and the cost of creating and verifying proofs is not significant then actually adding proofs can be good. But not required.\n\n### Also, how do you reward online validators / punish offline ones if you can't prove at the block level that someone attested or not? - Tanguy\n\u003e `Moh:` This is very tricky and so far no one has done it right (to my knowledge). Current reward mechanism for attestation, favours fast nodes.This means if malicious nodes in the network are fast, they can increase their stake in the network faster than the honest nodes and eventually take control of the network. Or in the case of Ethereum a Byzantine leader can include signature of malicious nodes more frequently in the proof of attestation, hence malicious nodes will be rewarded more frequently. Also let me add that I don't have definite answer to your question currently, but I think by revising the protocol assumptions, incentive mechanism and using a game theoretical approach this problem can be resolved.\n\n\u003e An honest node should wait for a specific number of children votes (to make sure everyone is voting on the same proposal) before voting but does not need to provide any cryptographic proof. Though we build a threshold signature from root committee members and it’s children but not from the whole tree. As long as enough number of nodes follow the the protocol we should be fine. I am working on protocol proofs. Also I think bugs should be discovered during development and testing phase. Changing protocol to detect potential bug might not be a good practice.\n\n## Synchronicity\n\n### How to guarantee synchronicity. In particular how to avoid that in a big network different nodes see a proposal with 2c+1 votes but different votes and thus different random seed - Giacomo\n\n\u003e `Moh:` The assumption is that there exists some known finite time bound Δ and a special event called GST (Global Stabilization Time) such that:\n\n\u003e The adversary must cause the GST event to eventually happen after some unknown finite time. Any message sent at time x must be delivered by time $\\delta + \\text{max}(x,GST)$. In the Partial synchrony model, the system behaves asynchronously till GST and synchronously after GST.\n\n\u003e Moreover, votes travel one level at a time from tree leaves to the tree root. We only need the proof of votes of root+child committees to conclude with a high probability that the majority of nodes have voted.","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/candidates/carnot/overview":{"title":"Carnot Overview","content":"\nCarnot (formerly LogosBFT) is a Byzantine Fault Tolerant (BFT) [consensus](roadmap/consensus/index.md) candidate for the Nomos Network that utilizes Fountain Codes and a committees tree structure to optimize message propagation in the presence of a large number of nodes, while maintaining high througput and fast finality.\n\n- [FAQ](roadmap/consensus/candidates/carnot/FAQ.md): Here is a page that tracks various questions people have around Carnot.\n\n## Work Streams\n\n### Current State of the Art\nAn ongoing survey of the current state of the art around Consensus Mechanisms and their peripheral dependencies is being conducted by Tuanir, and can be found in the following WIP Overleaf document: \n- [WIP Consensus SoK](https://www.overleaf.com/project/633acc1acaa6ffe456d1ab1f)\n\n### Committee Tree Overlay\nThe basis of Carnot is dependent upon establishing an committee overlay tree structure for message distribution. \n\nAn overview video can be found in the following link: \n- [Carnot Overview by Moh during Offsite](https://drive.google.com/file/d/17L0JPgC0L1ejbjga7_6ZitBfHUe3VO11/view?usp=sharing)\n\nThe details of this are being worked on by Moh and Alexander and can be found in the following overleaf documents: \n- [Moh's draft](https://www.overleaf.com/project/6341fb4a3cf4f20f158afad3)\n- [Alexander's notes on the statistical properties of committees](https://www.overleaf.com/project/630c7e20e56998385e7d8416)\n- [Alexander's python code for computing committee sizes](https://github.com/AMozeika/committees)\n\nA simulation notebook is being worked on by Corey to investigate the properties of various tree overlay structures and estimate their practical performance:\n- [Corey's Overlay Jupyter Notebook](https://github.com/logos-co/scratch/tree/main/corpetty/committee_sim)\n\n#### Failure Recovery\nThere exists a timeout that triggers an overlay reconfiguration. Currently work is being done to calculate the probabilities of another failure based on a given percentage of byzantine nodes within the network. \n- [Recovery Failure Probabilities]() - LINK TO WORK HERE\n\n### Random Beacon\nA random beacon is required to choose a leader and establish a seed for defining the overlay tree. Marcin is working on the various avenues. His previous presentations can be found in the following presentation slides (in chronological order):\n- [Intro to Multiparty Random Beacons](https://cloud.logos.co/index.php/s/b39EmQrZRt5rrfL)\n- [Circles of Trust](https://cloud.logos.co/index.php/s/NXJZX8X8pHg6akw)\n- [Compact Certificates of Knowledge](https://cloud.logos.co/index.php/s/oSJ4ykR4A55QHkG)\n\n### Erasure Coding (LT Codes / Fountain Codes / Raptor Codes)\nIn order to reduce message complexity during propagation, we are investigating the use of Luby Transform (LT) codes, more specifically [Fountain Codes](https://en.wikipedia.org/wiki/Fountain_code), to break up the block to be propagated to validators and recombined by local peers within a committee. \n- [LT Code implementation in Rust](https://github.com/chrido/fountain) - unclear about legal status of LT or Raptor Codes, it is currently under investigation.\n\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/candidates/claro":{"title":"Claro: Consensus Candidate","content":"\n\n\n**Claro** (formerly Glacier) is a consensus candidate for the Logos network that aims to be an improvement to the Avalanche family of consensus protocols. \n\n\n### Implementations\nThe protocol has been implemented in multiple languages to facilitate learning and testing. The individual code repositories can be found in the following links:\n- Rust (reference)\n- Python\n- Common Lisp\n\n### Simulations/Experiments/Analysis\nIn order to test the performance of the protocol, and how it stacked up to the Avalanche family of protocols, we have performed a multitude of simulations and experiments under various assumptions. \n- [Alvaro's initial Python implementations and simulation code](https://github.com/status-im/consensus-models)\n\n### Specification\nCurrently the Claro consensus protocol is being drafted into a specification so that other implementations can be created. It's draft resides under [Vac](https://vac.dev) and can be tracked [here](https://github.com/vacp2p/rfc/pull/512/)\n\n### Additional Information\n\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/development/overview":{"title":"Development Work","content":"","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/development/prototypes":{"title":"Consensus Prototypes","content":"\nConsensus Prototypes is a collection of Rust implementations of the [Consensus Candidates](tags/candidates)\n\n## Tiny Node\n\n\n## Required Roles\n- Lead Developer (filled)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/overview":{"title":"Consensus Work","content":"\nConsensus is the foundation of the network. It is how a group of peer-to-peer nodes understands how to agree on information in a distributed way, particuluarly in the presence of byzantine actors. \n\n## Consensus Roadmap\n### Consensus Candidates\n- [Carnot](roadmap/consensus/candidates/carnot/overview.md) - Carnot is the current leading consensus candidate for the Nomos network. It is designed to maximize efficiency of message dissemination while supoorting hundreds of thousands of full validators. It gets its name from the thermodynamic concept of the [Carnot Cycle](https://en.wikipedia.org/wiki/Carnot_cycle), which defines maximal efficiency of work from heat through iterative gas expansions and contractions. \n- [Claro](roadmap/consensus/candidates/claro.md) - Claro is a variant of the Avalanche Snow family of protocols, designed to be more efficient at the decision making process by leveraging the concept of \"confidence\" across peer responses. \n\n\n### Theoretical Analysis\n- [snow-family](roadmap/consensus/theory/snow-family.md)\n\n### Development\n- [prototypes](roadmap/consensus/development/prototypes.md)\n\n## Open Roles\n- [distributed-systems-researcher](roles/distributed-systems-researcher.md)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/theory/overview":{"title":"Consensus Theory Work","content":"\nThis track of work is dedicated to creating theoretical models of distributed consensus in order to evaluate them from a mathematical standpoint. \n\n## Navigation\n- [Snow Family Analysis](snow-family.md)\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/consensus/theory/snow-family":{"title":"Theoretical Analysis of the Snow Family of Consensus Protocols","content":"\nIn order to evaluate the properties of the Avalanche family of consensus protocols more rigorously than the original [whitepapers](), we work to create an analytical framework to explore and better understand the theoretical boundaries of the underlying protocols, and under what parameterization they will break vs a set of adversarial strategies","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/networking/carnot-waku-specification":{"title":"A Specification proposal for using Waku for Carnot Consensus","content":"\n##### Definition Reference \n- $k$ - size of a given committee\n- $n_C$ - number of committees in the overlay, or nodes in the tree\n- $d$ - depth of the overlay tree\n- $n_d$ - number of committees at a given depth of the tree\n\n## Motivation\nIn #Carnot, an overlay is created to facilitate message distribution and voting aggregation. This document will focus on the differentiated channels of communication for message distribution. Whether or not voting aggregation and subsequenty traversal back up the tree can utilize the same channels will be investigated later. \n\nThe overlay is described as a binary tree of committees, where a individual in each committee propogates messages to an assigned node in their two children committees of the tree, until the leaf nodes have recieved enough information to reconstitute the proposal block. \n\nThis communication protocol will naturally form \"pools of information streams\" that people will need to listen to in order to do their assigned work:\n- inner committee communication\n- parent-child chain communication\n- intitial leader distribution\n\n### **inner committee communication** \nall members of a given committee will need to gossip with each other in order to reform the initial proposal block\n- This results in $n_C$ pools of $k$-sized communication pools.\n\n### **parent-child chain communication** \nThe formation of the committee and the lifecycle of a chunk of erasure coded data forms a number of \"parent-child\" chains. \n- If we completely minimize the communcation between committees, then this results in $k$ number of $n_C$-sized communication pools.\n- It is not clear if individual levels of the tree needs to \"execute\" the message to their children, or if the root committee can broadcast to everyone within its assigned parent-chain communcation pool at the same time.\n- It is also unclear if individual levels of the tree need to send independant messages to each of their children, or if a unified communication pool can be leveraged at the tree-level. This results in $d$ communication pools of $n_d$-size. \n\n### **initial leader distribution**\nFor each proposal, a leader needs to distribute the erasure coded proposal block to the root committee\n- This results in a single communication pool of size $k(+1)$.\n- the $(+1)$ above is the leader, who could also be a part of the root committee. The leader changes with each block proposal, and we seek to minimize the time between leader selection and a round start. Thusly, this results in a requirement that each node in the network must maintain a connection to every node in the root committee. \n\n## Proposal\nThis part of the document will attempt to propose using various aspects of Waku, to facilitate both the setup of the above-mentioned communication pools as well as encryption schemes to add a layer of privacy (and hopefully efficiency) to message distribution. \n\nWe seek to minimize the availability of data such that an individual has only the information to do his job and nothing more.\n\nWe also seek to minimize the amount of messages being passed such that eventually everyone can reconstruct the initial proposal block\n\n`???` for Waku-Relay, 6 connections is optimal, resulting in latency ???\n\n`???` Is it better to have multiple pubsub topics with a simple encryption scheme or a single one with a complex encryption scheme\n\nAs there seems to be a lot of dynamic change from one proposal to the next, I would expect [`noise`](https://vac.dev/wakuv2-noise) to be a quality candidate to facilitate the creation of secure ephemeral keys in the to-be proposed encryption scheme. \n\nIt is also of interest how [`contentTopics`](https://rfc.vac.dev/spec/23/) can be leveraged to optimize the communication pools. \n\n## Whiteboard diagram and notes\n![Whiteboard Diagram](images/Overlay-Communications-Brainstorm.png)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/networking/overview":{"title":"P2P Networking Overview","content":"\nThis page summarizes the work around the P2P networking layer of the Nomos project.\n\n## Waku\n[Waku](https://waku.org) is an privacy-preserving, ephemeral, peer-to-peer (P2P) messaging suite of protocols which is developed under [Vac](https://vac.dev) and maintained/productionized by the [Logos Collective](https://logos.co). \n\nIt is hopeful that Nomos can leverage the work of the Waku project to provide the P2P networking layer and peripheral services associated with passing messages around the network. Below is a list of the associated work to investigate the use of Waku within the Nomos Project. \n\n### Scalability and Fault-Tolerance Studies\nCurrently, the amount of research and analysis of the scalability of Waku is not sufficient to give enough confidence that Waku can serve as the networking layer for the Nomos project. Thusly, it is our effort to push this analysis forward by investigating the various boundaries of scale for Waku. Below is a list of endeavors in this direction which we hope serves the broader community: \n- [Status' use of Waku study w/ Kurtosis](roadmap/networking/status-waku-kurtosis.md)\n- [Using Waku for Carnot Overlay](roadmap/networking/carnot-waku-specification.md)\n\n### Rust implementations\nWe have created and maintain a stop-gap solution to using Waku with the Rust programming language, which is wrapping the [go-waku](https://github.com/status-im/go-waku) library in Rust and publishing it as a crate. This library allows us to do tests with our [Tiny Node](roadmap/development/prototypes.md#Tiny-Node) implementation more quickly while also providing other projects in the ecosystem to leverage Waku within their Rust codebases more quickly. \n\nIt is desired that we implement a more robust and efficient Rust library for Waku, but this is a significant amount of work. \n\nLinks:\n- [Rust bindings to go-waku repo](https://github.com/waku-org/waku-rust-bindings)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/networking/status-network-agents":{"title":"Status Network Agents Breakdown","content":"\nThis page creates a model to describe the impact of the various clients within the Status ecosystem by describing their individual contribution to the messages within the Waku network they leverage. \n\nThis model will serve to create a realistic network topology while also informing the appropriate _dimensions of scale_ that are relevant to explore in the [Status Waku scalability study](roadmap/networking/status-waku-kurtosis.md)\n\nStatus has three main clients that users interface with (in increasing \"network weight\" ordering):\n- Status Web\n- Status Mobile\n- Status Desktop\n\nEach of these clients has differing (on average) resources available to them, and thusly, provides and consumes different Waku protocols and services within the Status network. Here we will detail their associated messaging impact to the network using the following model:\n\n```\nAgent\n - feature\n - protocol\n - contentTopic, messageType, payloadSize, frequency\n```\n\nBy describing all `Agents` and their associated feature list, we should be able do the following:\n\n- Estimate how much impact per unit time an individual `Agent` impacts the Status network\n- Create a realistic network topology and usage within a simulation framework (_e.g._ Kurtosis)\n- Facilitate a Status Specification of `Agents`\n- Set an example for future agent based modeling and simulation work for the Waku protocol suite \n\n## Status Web\n\n## Status Mobile\n\n## Status Desktop\nStatus Desktop serves as the backbone for the Status Network, as the software runs on hardware that is has more available resources, typically has more stable network and robust connections, and generally has a drastically lower churn (or none at all). This results in it running the most Waku protocols for longer periods of time, resulting int he heaviest usage of the Waku network w.r.t. messaging. \n\nHere is the model breakdown of its usage:\n```\nStatus Desktop\n - Prekey bundle broadcast\n - Account sync\n - Historical message melivery\n - Waku-Relay (answering message queries)\n - Message propogation\n - Waku-Relay\n - Waku-Lightpush (receiving)\n```","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/networking/status-waku-kurtosis":{"title":"Status' use of Waku - A Scalability Study","content":"\n[Status](https://status.im) is the largest consumer of the Waku protocol, leveraging it for their entire networking stack. THeir upcoming release of Status Desktop and the associated Communities product will heavily push the limits of what Waku can do. As mentioned in the [Networking Overview](roadmap/networking/overview.md) page, rigorous scalability studies have yet to be conducted of Waku (v2). \n\nWhile these studies most immediately benefit the Status product suite, it behooves the Nomos Project to assist as the lessons learned immediately inform us the limits of what the Waku protocol suite can handle, and how that fits within our [Technical Requirements](requirements/overview.md).\n\nThis work has been kicked off as a partnership with the [Kurtosis](https://kurtosis.com) distributed systems development platform. It is our hope that the experience and accumen gained during this partnership and study will serve us in the future with respect to Nomos developme, and more broadly, all projects under the Logos Collective. \n\nAs such, here is an overview of the various resources towards this endeavor:\n- [Status Network Agent Breakdown](roadmap/networking/status-network-agents.md) - A document that describes the archetypal agents that participate in the Status Network and their associated Waku consumption.\n- [Wakurtosis repo](https://github.com/logos-co/wakurtosis) - A Kurtosis module to run scalability studies\n- [Waku Topology Test repo](https://github.com/logos-co/Waku-topology-test) - a Python script that facilitates setting up a reasonable network topology for the purpose of injecting the network configuration into the above Kurtosis repo\n- [Initial Vac forum post introducing this work](https://forum.vac.dev/t/waku-v2-scalability-studies/142)\n- [Waku Github Issue detailing work progression](https://github.com/waku-org/pm/issues/2)\n - this is also a place to maintain communications of progress\n- [Initial Waku V2 theoretical scalability study](https://vac.dev/waku-v1-v2-bandwidth-comparison)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roadmap/virtual-machines/overview":{"title":"","content":"\n## Motivation\nLogos seeks to use a privacy-first virtual machine for transaction execution. We believe this can only be acheived through zero-knowledge. The majority of current work in the field focuses more towards the aggregation and subsequent verification of transactions. This leads us to explore the researching and development of a privacy-first virtual machine. \n\nLINK TO APPROPRIATE NETWORK REQUIREMENTS HERE\n\n#### Educational Resources\n- primer on Zero Knowledge Virtual Machines - [link](https://youtu.be/GRFPGJW0hic)\n\n### Implementations:\n- TinyRAM - link\n- CairoVM\n- zkSync\n- Hermes\n- [MIDEN](https://polygon.technology/solutions/polygon-miden/) (Polygon)\n- RISC-0\n\t- RISC-0 Rust Starter Repository - [link](https://github.com/risc0/risc0-rust-starter)\n\t- targets RISC-V architecture\n\t- benefits:\n\t\t- a lot of languages already compile to RISC-V\n\t- negatives:\n\t\t- not optimized or EVM where most tooling exists currently\n\n## General Building Blocks of a ZK-VM\n- CPU\n\t- modeled with \"execution trays\"\n- RAM\n\t- overhead to look out for\n\t\t- range checks\n\t\t- bitwise operations\n\t\t- hashing\n- Specialized circuits\n- Recursion\n\n## Approaches\n- zk-WASM\n- zk-EVM\n- RISC-0\n\t- RISK-0 Rust Starter Repository - [link](https://github.com/risc0/risc0-rust-starter)\n\t- targets RISC-V architecture\n\t- benefits:\n\t\t- a lot of languages already compile to RISC-V\n\t\t- https://youtu.be/2MXHgUGEsHs - Why use the RISC Zero zkVM?\n\t- negatives:\n\t\t- not optimized or EVM where most tooling exists currently\n\n## General workstreams\n- bytecode compiler\n- zero-knowledge circuit design\n- opcode architecture (???)\n- engineering\n- required proof system\n- control flow\n\t- MAST (as used in MIDEN)\n\n## Roles\n- [ZK Research Engineer](roles/zero-knowledge-research-engineer.md)\n- Senior Rust Developer\n","lastmodified":"2023-01-03T20:41:55.536851826Z","tags":null},"/roles/distributed-systems-researcher":{"title":"Open Role: Distributed Systems Researcher","content":"\n\n## About Status\n\nStatus is building the tools and infrastructure for the advancement of a secure, private, and open web3. \n\nWith the high level goals of preserving the right to privacy, mitigating the risk of censorship, and promoting economic trade in a transparent, open manner, Status is building a community where anyone is welcome to join and contribute.\n\nAs an organization, Status seeks to push the web3 ecosystem forward through research, creation of developer tools, and support of the open source community. \n\nAs a product, Status is an open source, Ethereum-based app that gives users the power to chat, transact, and access a revolutionary world of DApps on the decentralized web. But Status is also building foundational infrastructure for the whole Ethereum ecosystem, including the Nimbus ETH 1.0 and 2.0 clients, the Keycard hardware wallet, and the Waku messaging protocol (a continuation of Whisper).\n\nAs a team, Status has been completely distributed since inception. Our team is currently 100+ core contributors strong, and welcomes a growing number of community members from all walks of life, scattered all around the globe. \n\nWe care deeply about open source, and our organizational structure has minimal hierarchy and no fixed work hours. We believe in working with a high degree of autonomy while supporting the organization's priorities.\n\n \n\n## Who are we?\n\nWe are the Blockchain Infrastructure Team, and we are building the foundation used by other projects at the Status Network. We are researching consensus algorithms, Multi-Party Computation techniques, ZKPs and other cutting-edge solutions with the aim to take the blockchain technology to the next level of security, decentralization and scalability for a wide range of use cases. We are currently in a research phase, working with models and simulations. In the near future, we will start implementing the research. You will have the opportunity to participate in developing -and improving- the state of the art of blockchain technologies, as well as turning it into a reality\n\n## The job\n\n**Responsibilities:**\n- This role is dedicated to pure research\n- Primarily, ensuring that solutions are sound and diving deeper into their formal definition.\n- Additionally, he/she would be regularly going through papers, bringing new ideas and staying up-to-date.\n- Designing, specifying and verifying distributed systems by leveraging formal and experimental techniques.\n- Conducting theoretical and practical analysis of the performance of distributed systems.\n- Designing and analysing incentive systems.\n- Collaborating with both internal and external customers and the teams responsible for the actual implementation.\n- Researching new techniques for designing, analysing and implementing dependable distributed systems.\n- Publishing and presenting research results both internally and externally.\n\n \n**Ideally you will have:**\n[Don’t worry if you don’t meet all of these criteria, we’d still love to hear from you anyway if you think you’d be a great fit for this role!]\n- Strong background in Computer Science and Math, or a related area.\n- Academic background (The ability to analyze, digest and improve the State of the Art in our fields of interest. Specifically, familiarity with formal proofs and/or the scientific method.)\n- Distributed Systems with a focus on Blockchain\n- Analysis of algorithms\n- Familiarity with Python and/or complex systems modeling software\n- Deep knowledge of algorithms (much more academic, such as have dealt with papers, moving from research to pragmatic implementation)\n- Experience in analysing the correctness and security of distributed systems.\n- Familiarity with the application of formal method techniques. \n- Comfortable with “reverse engineering” code in a number of languages including Java, Go, Rust, etc. Even if no experience in these languages, the ability to read and \"reverse engineer\" code of other projects is important.\n- Keen communicator, eager to share your work in a wide variety of contexts, like internal and public presentations, blog posts and academic papers.\n- Capable of deep and creative thinking.\n- Passionate about blockchain technology in general.\n- Able to manage the uncertainties and ambiguities associated with working in a remote-first, distributed, decentralised environment.\n- A strong alignment to our principles: https://status.im/about/#our-principles\n\n\n**Bonus points:**\n- Experience working remotely. \n- Experience working for an open source organization. \n- TLA+/PRISM would be desirable.\n- PhD in Computer Science, Mathematics, or a related area. \n- Experience Multi-Party Computation and Zero-Knowledge Proofs\n- Track record of scientific publications.\n- Previous experience in remote or globally distributed teams.\n\n## Hiring process\n\nThe hiring process for this role will be:\n- Interview with our People Ops team\n- Interview with Alvaro (Team Lead)\n- Interview with Corey (Chief Security Officer)\n- Interview with Jarrad (Cofounder) or Daniel \n\nThe steps may change along the way if we see it makes sense to adapt the interview stages, so please consider the above as a guideline.\n\n \n\n## Compensation\n\nWe are happy to pay salaries in either 100% fiat or any mix of fiat and/or crypto. For more information regarding benefits at Status: https://people-ops.status.im/tag/perks/\n","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roles/rust-developer":{"title":"Rust Developer","content":"\n# Role: Rust Developer\nat Status\n\nRemote, Worldwide\n\n**About Status**\n\nStatus is an organization building the tools and infrastructure for the advancement of a secure, private, and open web3. We have been completely distributed since inception. Our team is currently 100+ core contributors strong and welcomes a growing number of community members from all walks of life, scattered all around the globe. We care deeply about open source, and our organizational structure has a minimal hierarchy and no fixed work hours. We believe in working with a high degree of autonomy while supporting the organization's priorities.\n\n**About Logos**\n\nA group of Status Contributors is also involved in a new community lead project, called Logos, and this particular role will enable you to also focus on this project. Logos is a grassroots movement to provide trust-minimized, corruption-resistant governing services and social institutions to underserved citizens. \n\nLogos’ infrastructure will provide a base for the provisioning of the next-generation of governing services and social institutions - paving the way to economic opportunities for those who need them most, whilst respecting basic human rights through the network’s design.You can read more about Logos here: [in this small handbook](https://github.com/acid-info/public-assets/blob/master/logos-manual.pdf) for mindful readers like yourself.\n\n**Who are we?**\n\nWe are the Blockchain Infrastructure Team, and we are building the foundation used by other projects at the [Status Network](https://statusnetwork.com/). We are researching consensus algorithms, Multi-Party Computation techniques, ZKPs and other cutting-edge solutions with the aim to take the blockchain technology to the next level of security, decentralization and scalability for a wide range of use cases. We are currently in a research phase, working with models and simulations. In the near future, we will start implementing the research. You will have the opportunity to participate in developing -and improving- the state of the art of blockchain technologies, as well as turning it into a reality.\n\n**Responsibilities:**\n\n- Develop and maintenance of internal rust libraries\n- 1st month: comfortable with dev framework, simulation app. Improve python lib?\n- 2th-3th month: Start dev of prototype node services\n\n**Ideally you will have:**\n\n- “Extensive” Rust experience (Async programming is a must) \n Ideally they have some GitHub projects to show\n- Experience with Python\n- Strong competency in developing and maintaining complex libraries or applications\n- Experience in, and passion for, blockchain technology.\n- A strong alignment to our principles: [https://status.im/about/#our-principles](https://status.im/about/#our-principles) \n \n\n**Bonus points if**\n\n-  E.g. Comfortable working remotely and asynchronously\n-  Experience working for an open source organization.  \n-  Peer-to-peer or networking experience\n\n_[Don’t worry if you don’t meet all of these criteria, we’d still love to hear from you anyway if you think you’d be a great fit for this role!]_\n\n**Compensation**\n\nWe are happy to pay in either 100% fiat or any mix of fiat and/or crypto. For more information regarding benefits at Status: [https://people-ops.status.im/tag/perks/](https://people-ops.status.im/tag/perks/)\n\n**Hiring Process** \n\nThe hiring process for this role will be:\n\n1. Interview with Maya (People Ops team)\n2. Interview with Corey (Logos Program Owner)\n3. Interview with Daniel (Engineering Lead)\n4. Interview with Jarrad (Cofounder)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null},"/roles/zero-knowledge-research-engineer":{"title":"Zero Knowledge Research Engineer","content":"at Status\n\nRemote, Worldwide\n\n**About Status**\n\nStatus is building the tools and infrastructure for the advancement of a secure, private, and open web3. \n\nWith the high level goals of preserving the right to privacy, mitigating the risk of censorship, and promoting economic trade in a transparent, open manner, Status is building a community where anyone is welcome to join and contribute.\n\nAs an organization, Status seeks to push the web3 ecosystem forward through research, creation of developer tools, and support of the open source community. \n\nAs a product, Status is an open source, Ethereum-based app that gives users the power to chat, transact, and access a revolutionary world of DApps on the decentralized web. But Status is also building foundational infrastructure for the whole Ethereum ecosystem, including the Nimbus ETH 1.0 and 2.0 clients, the Keycard hardware wallet, and the Waku messaging protocol (a continuation of Whisper).\n\nAs a team, Status has been completely distributed since inception.  Our team is currently 100+ core contributors strong, and welcomes a growing number of community members from all walks of life, scattered all around the globe. \n\nWe care deeply about open source, and our organizational structure has minimal hierarchy and no fixed work hours. We believe in working with a high degree of autonomy while supporting the organization's priorities.\n\n**Who are we**\n\n[Vac](http://vac.dev/) **builds** [public good](https://en.wikipedia.org/wiki/Public_good) protocols for the decentralized web.\n\nWe do applied research based on which we build protocols, libraries and publications. Custodians of protocols that reflect [a set of principles](http://vac.dev/principles) - liberty, privacy, etc.\n\nYou can see a sample of some of our work here: [Vac, Waku v2 and Ethereum Messaging](https://vac.dev/waku-v2-ethereum-messaging), [Privacy-preserving p2p economic spam protection in Waku v2](https://vac.dev/rln-relay), [Waku v2 RFC](https://rfc.vac.dev/spec/10/). Our attitude towards ZK: [Vac \u003c3 ZK](https://forum.vac.dev/t/vac-3-zk/97).\n\n**The role**\n\nThis role will be part of a new team that will make a provable and private WASM engine that runs everywhere. As a research engineer, you will be responsible for researching, designing, analyzing and implementing circuits that allow for proving private computation of execution in WASM. This includes having a deep understanding of relevant ZK proof systems and tooling (zk-SNARK, Circom, Plonk/Halo 2, zk-STARK, etc), as well as different architectures (zk-EVM Community Effort, Polygon Hermez and similar) and their trade-offs. You will collaborate with the Vac Research team, and work with requirements from our new Logos program. As one of the first hires of a greenfield project, you are expected to take on significant responsibility,  while collaborating with other research engineers, including compiler engineers and senior Rust engineers. \n \n\n**Key responsibilities** \n\n- Research, analyze and design proof systems and architectures for private computation\n- Be familiar and adapt to research needs zero-knowledge circuits written in Rust Design and implement zero-knowledge circuits in Rust\n- Write specifications and communicate research findings through write-ups\n- Break down complex problems, and know what can and what can’t be dealt with later\n- Perform security analysis, measure performance of and debug circuits\n\n**You ideally will have**\n\n- Very strong academic or engineering background (PhD-level or equivalent in industry); relevant research experience\n- Experience with low level/strongly typed languages (C/C++/Go/Rust or Java/C#)\n- Experience with Open Source software\n- Deep understanding of Zero-Knowledge proof systems (zk-SNARK, circom, Plonk/Halo2, zk-STARK), elliptic curve cryptography, and circuit design\n- Keen communicator, eager to share your work in a wide variety of contexts, like internal and public presentations, blog posts and academic papers.\n- Experience in, and passion for, blockchain technology.\n- A strong alignment to our principles: [https://status.im/about/#our-principles](https://status.im/about/#our-principles)\n\n**Bonus points if** \n\n- Experience in provable and/or private computation (zkEVM, other ZK VM)\n- Rust Zero Knowledge tooling\n- Experience with WebAssemblyWASM\n\n[Don’t worry if you don’t meet all of these criteria, we’d still love to hear from you anyway if you think you’d be a great fit for this role. Just explain to us why in your cover letter].\n\n**Hiring process** \n\nThe hiring process for this role will be:\n\n1. Interview with Angel/Maya from our Talent team\n2. Interview with team member from the Vac team\n3. Pair programming task with the Vac team\n4. Interview with Oskar, the Vac team lead\n5. Interview with Jacek, Program lead\n\nThe steps may change along the way if we see it makes sense to adapt the interview stages, so please consider the above as a guideline.\n\n**Compensation**\n\nWe are happy to pay in either 100% fiat or any mix of fiat and/or crypto. For more information regarding benefits at Status: [https://people-ops.status.im/tag/perks/](https://people-ops.status.im/tag/perks/)","lastmodified":"2023-01-03T20:40:57.351847438Z","tags":null}} \ No newline at end of file diff --git a/linkmap b/linkmap index 212e21887..7d240e854 100644 --- a/linkmap +++ b/linkmap @@ -1,33 +1,33 @@ -/private/notes/preview-changes/index.{html} /private/notes/preview-changes/ -/roadmap/consensus/candidates/carnot/FAQ/index.{html} /roadmap/consensus/candidates/carnot/FAQ/ -/roadmap/consensus/theory/overview/index.{html} /roadmap/consensus/theory/overview/ -/roles/zero-knowledge-research-engineer/index.{html} /roles/zero-knowledge-research-engineer/ -/roadmap/consensus/candidates/claro/index.{html} /roadmap/consensus/candidates/claro/ -/roadmap/consensus/development/overview/index.{html} /roadmap/consensus/development/overview/ -/roadmap/networking/status-network-agents/index.{html} /roadmap/networking/status-network-agents/ -/roles/rust-developer/index.{html} /roles/rust-developer/ -/index.html / -/private/notes/callouts/index.{html} /private/notes/callouts/ -/private/notes/editing/index.{html} /private/notes/editing/ -/private/notes/search/index.{html} /private/notes/search/ -/private/notes/hosting/index.{html} /private/notes/hosting/ -/private/notes/showcase/index.{html} /private/notes/showcase/ -/roadmap/networking/status-waku-kurtosis/index.{html} /roadmap/networking/status-waku-kurtosis/ -/requirements/overview/index.{html} /requirements/overview/ -/roadmap/networking/carnot-waku-specification/index.{html} /roadmap/networking/carnot-waku-specification/ -/roles/distributed-systems-researcher/index.{html} /roles/distributed-systems-researcher/ -/private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/index.{html} /private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/ -/private/notes/philosophy/index.{html} /private/notes/philosophy/ -/private/notes/troubleshooting/index.{html} /private/notes/troubleshooting/ -/private/notes/updating/index.{html} /private/notes/updating/ -/private/notes/config/index.{html} /private/notes/config/ -/private/notes/obsidian/index.{html} /private/notes/obsidian/ -/roadmap/consensus/development/prototypes/index.{html} /roadmap/consensus/development/prototypes/ -/roadmap/networking/overview/index.{html} /roadmap/networking/overview/ -/roadmap/consensus/overview/index.{html} /roadmap/consensus/overview/ -/roadmap/consensus/theory/snow-family/index.{html} /roadmap/consensus/theory/snow-family/ -/roadmap/virtual-machines/overview/index.{html} /roadmap/virtual-machines/overview/ -/private/notes/custom-Domain/index.{html} /private/notes/custom-Domain/ /private/notes/ignore-notes/index.{html} /private/notes/ignore-notes/ +/private/notes/preview-changes/index.{html} /private/notes/preview-changes/ /private/notes/setup/index.{html} /private/notes/setup/ +/private/notes/showcase/index.{html} /private/notes/showcase/ +/private/notes/hosting/index.{html} /private/notes/hosting/ +/private/notes/philosophy/index.{html} /private/notes/philosophy/ +/roadmap/networking/status-network-agents/index.{html} /roadmap/networking/status-network-agents/ +/roadmap/consensus/theory/overview/index.{html} /roadmap/consensus/theory/overview/ +/roadmap/consensus/theory/snow-family/index.{html} /roadmap/consensus/theory/snow-family/ +/index.html / +/private/notes/editing/index.{html} /private/notes/editing/ +/roadmap/consensus/candidates/claro/index.{html} /roadmap/consensus/candidates/claro/ +/roadmap/consensus/overview/index.{html} /roadmap/consensus/overview/ +/private/notes/callouts/index.{html} /private/notes/callouts/ +/roadmap/networking/overview/index.{html} /roadmap/networking/overview/ +/roadmap/networking/status-waku-kurtosis/index.{html} /roadmap/networking/status-waku-kurtosis/ +/private/notes/obsidian/index.{html} /private/notes/obsidian/ +/private/notes/updating/index.{html} /private/notes/updating/ +/roadmap/consensus/candidates/carnot/FAQ/index.{html} /roadmap/consensus/candidates/carnot/FAQ/ /roadmap/consensus/candidates/carnot/overview/index.{html} /roadmap/consensus/candidates/carnot/overview/ +/private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/index.{html} /private/notes/CJK-+-Latex-Support-%E6%B5%8B%E8%AF%95/ +/private/notes/config/index.{html} /private/notes/config/ +/requirements/overview/index.{html} /requirements/overview/ +/roadmap/consensus/development/overview/index.{html} /roadmap/consensus/development/overview/ +/private/notes/custom-Domain/index.{html} /private/notes/custom-Domain/ +/roles/zero-knowledge-research-engineer/index.{html} /roles/zero-knowledge-research-engineer/ +/roadmap/virtual-machines/overview/index.{html} /roadmap/virtual-machines/overview/ +/roles/distributed-systems-researcher/index.{html} /roles/distributed-systems-researcher/ +/roles/rust-developer/index.{html} /roles/rust-developer/ +/private/notes/search/index.{html} /private/notes/search/ +/private/notes/troubleshooting/index.{html} /private/notes/troubleshooting/ +/roadmap/consensus/development/prototypes/index.{html} /roadmap/consensus/development/prototypes/ +/roadmap/networking/carnot-waku-specification/index.{html} /roadmap/networking/carnot-waku-specification/ diff --git a/requirements/index.html b/requirements/index.html index 5cbb8d88b..e0a54c801 100644 --- a/requirements/index.html +++ b/requirements/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/requirements/overview/index.html b/requirements/overview/index.html index 58d3d9543..6858db296 100644 --- a/requirements/overview/index.html +++ b/requirements/overview/index.html @@ -103,7 +103,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/candidates/carnot/FAQ/index.html b/roadmap/consensus/candidates/carnot/FAQ/index.html index 8d75c537e..b5486c75d 100644 --- a/roadmap/consensus/candidates/carnot/FAQ/index.html +++ b/roadmap/consensus/candidates/carnot/FAQ/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/candidates/carnot/overview/index.html b/roadmap/consensus/candidates/carnot/overview/index.html index eb445ab59..b61cef658 100644 --- a/roadmap/consensus/candidates/carnot/overview/index.html +++ b/roadmap/consensus/candidates/carnot/overview/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/candidates/claro/index.html b/roadmap/consensus/candidates/claro/index.html index 298801afa..a762ebf92 100644 --- a/roadmap/consensus/candidates/claro/index.html +++ b/roadmap/consensus/candidates/claro/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/development/overview/index.html b/roadmap/consensus/development/overview/index.html index 834043b30..a888e943b 100644 --- a/roadmap/consensus/development/overview/index.html +++ b/roadmap/consensus/development/overview/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/development/prototypes/index.html b/roadmap/consensus/development/prototypes/index.html index f4d78c417..6396e8a3d 100644 --- a/roadmap/consensus/development/prototypes/index.html +++ b/roadmap/consensus/development/prototypes/index.html @@ -103,7 +103,7 @@ Tiny Node Required Roles Lead Developer (filled) " index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/overview/index.html b/roadmap/consensus/overview/index.html index c689fca50..81eed2148 100644 --- a/roadmap/consensus/overview/index.html +++ b/roadmap/consensus/overview/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/theory/overview/index.html b/roadmap/consensus/theory/overview/index.html index d7f999917..7018ee668 100644 --- a/roadmap/consensus/theory/overview/index.html +++ b/roadmap/consensus/theory/overview/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/consensus/theory/snow-family/index.html b/roadmap/consensus/theory/snow-family/index.html index 2df9e1345..899d9cf01 100644 --- a/roadmap/consensus/theory/snow-family/index.html +++ b/roadmap/consensus/theory/snow-family/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/index.html b/roadmap/index.html index 7f2fa61cd..03a0d1812 100644 --- a/roadmap/index.html +++ b/roadmap/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/networking/carnot-waku-specification/index.html b/roadmap/networking/carnot-waku-specification/index.html index 7614b857e..8d267b489 100644 --- a/roadmap/networking/carnot-waku-specification/index.html +++ b/roadmap/networking/carnot-waku-specification/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/networking/overview/index.html b/roadmap/networking/overview/index.html index 79d7e4642..bfb6f1010 100644 --- a/roadmap/networking/overview/index.html +++ b/roadmap/networking/overview/index.html @@ -103,7 +103,7 @@ Waku Waku is an privacy-preserving, ephemeral, peer-to-peer (P2P) messaging sui index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/networking/status-network-agents/index.html b/roadmap/networking/status-network-agents/index.html index 1d7ba6042..2536b0d79 100644 --- a/roadmap/networking/status-network-agents/index.html +++ b/roadmap/networking/status-network-agents/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/networking/status-waku-kurtosis/index.html b/roadmap/networking/status-waku-kurtosis/index.html index 0f9f10f9d..c2e4dfbf2 100644 --- a/roadmap/networking/status-waku-kurtosis/index.html +++ b/roadmap/networking/status-waku-kurtosis/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/page/2/index.html b/roadmap/page/2/index.html index ed60680cf..4ef3b0bbb 100644 --- a/roadmap/page/2/index.html +++ b/roadmap/page/2/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ diff --git a/roadmap/virtual-machines/overview/index.html b/roadmap/virtual-machines/overview/index.html index 71a80b365..c17291377 100644 --- a/roadmap/virtual-machines/overview/index.html +++ b/roadmap/virtual-machines/overview/index.html @@ -102,7 +102,7 @@ index: data.index, links: data.links, })), - fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.7cd1c707c3cb37f184b31b1da0012d41.min.json") + fetch("https:\/\/roadmap.logos.co\/indices\/contentIndex.a6e7ed4e82869b814f0c150b1a996998.min.json") .then(data => data.json()), ]) .then(([{index, links}, content]) => ({ @@ -297,9 +297,9 @@ Jan 3, 2023
  • MIDEN (Polygon)
    • -
  • RISK-0 +
  • RISC-0