commit b23585a54cef8ff32a6cb86be10d9a4491500950 Author: Sunil Thakare Date: Sun Jul 5 17:35:08 2026 +0530 Initial commit: NX9 philosophy, architecture, roadmap and website diff --git a/.idea/.gitignore b/.idea/.gitignore new file mode 100644 index 0000000..30cf57e --- /dev/null +++ b/.idea/.gitignore @@ -0,0 +1,10 @@ +# Default ignored files +/shelf/ +/workspace.xml +# Editor-based HTTP Client requests +/httpRequests/ +# Ignored default folder with query files +/queries/ +# Datasource local storage ignored files +/dataSources/ +/dataSources.local.xml diff --git a/.idea/modules.xml b/.idea/modules.xml new file mode 100644 index 0000000..5820a91 --- /dev/null +++ b/.idea/modules.xml @@ -0,0 +1,8 @@ + + + + + + + + \ No newline at end of file diff --git a/.idea/nx9.iml b/.idea/nx9.iml new file mode 100644 index 0000000..6102194 --- /dev/null +++ b/.idea/nx9.iml @@ -0,0 +1,8 @@ + + + + + + + + \ No newline at end of file diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md new file mode 100644 index 0000000..e118165 --- /dev/null +++ b/ARCHITECTURE.md @@ -0,0 +1,108 @@ +# NX9 Architecture + +## A Philosophy-Driven Ecosystem for Self-Hosted Infrastructure + +**NX9** is an ecosystem of independent, philosophically aligned infrastructure software built by Sunil Thakare (@thakares). + +Every project is designed around one simple idea: + +> **Infrastructure should belong to its operator — not to a cloud provider, subscription service, or vendor.** + +NX9 is not a framework. +It is not a platform that requires dozens of services. +It is not a cloud product that happens to support self-hosting. + +Instead, NX9 is a collection of carefully engineered **single-binary Rust applications** that prioritize: + +- Privacy +- Simplicity +- Reliability +- Performance +- Operational Excellence +- Long-term Maintainability + +Every application is fully open-source, Linux-native, resource-efficient, and designed to run equally well on Raspberry Pi, mini PCs, VPS instances, enterprise servers, air-gapped government infrastructure, or personal homelabs. + +**No telemetry. No vendor lock-in. No mandatory cloud. No unnecessary complexity.** + +--- + +## Design Philosophy + +The NX9 ecosystem follows several consistent principles across every project. + +### 1. Operator Ownership + +The operator owns the binaries, the configuration, the databases, the backups, the encryption keys, and the deployment. + +No service depends on proprietary APIs or cloud-hosted control planes. + +### 2. Self-Hosting First + +Every architectural decision begins with one question: + +> "Can this be deployed and operated by a single administrator?" + +If the answer requires Kubernetes, managed databases, cloud messaging, or external dependencies, the design is reconsidered. + +### 3. Simplicity Over Complexity + +NX9 intentionally avoids fashionable complexity. Instead of dozens of microservices, service meshes, or distributed databases, NX9 prefers: + +- One binary +- One configuration +- One (or a few) SQLite databases +- One administrator + +Simple systems are easier to understand, secure, and recover. + +### 4. Privacy by Default + +Privacy is a design requirement, not an optional feature. Applications never assume cloud connectivity, analytics collection, or third-party tracking. + +### 5. Security by Design + +Security is embedded throughout the stack: + +- Argon2id password hashing +- Ed25519 signatures +- BLAKE3 hashing +- RBAC +- CSRF protection +- Secure cookies +- Transaction-safe audit logs +- Hardened compilation flags + +### 6. Operational Excellence + +Every project includes: + +- Diagnostics and health checks +- Backup and restore procedures +- Migration tools +- CLI administration +- Reproducible deployments +- Structured logging +- Documentation + +### 7. Long-Term Stability + +NX9 intentionally avoids dependency churn. Projects are expected to remain understandable and maintainable years into the future. + +--- + +## Core Architectural Pillars + +### 1. Pure Rust + +All projects are implemented in modern Rust (2021 Edition) for memory safety, predictable performance, and minimal runtime overhead. Typical binaries are around 10–12 MB. + +### 2. Single Binary Deployment + +One executable contains the HTTP server, business logic, authentication, database migrations, CLI, and templates. + +Installation is often as simple as: + +```bash +cargo build --release +./application serve \ No newline at end of file diff --git a/CASE-STUDY.md b/CASE-STUDY.md new file mode 100644 index 0000000..97aa0ea --- /dev/null +++ b/CASE-STUDY.md @@ -0,0 +1,466 @@ +# NX9 Philosophy: Engineering Beyond Frameworks + +## A Real-World Case Study in Software Minimalism, Explicit Routing, and Reduced Attack Surface + +> *"The best way to reduce complexity is not to manage more software—it is to deploy less software."* + +--- + +## Executive Summary + +This case study examines the first publicly accessible deployment of **NX9** and the unsolicited Internet traffic it received immediately after exposure. + +The objective was not to conduct a penetration test or security benchmark. Instead, the production access logs were analyzed to understand how real-world Internet scanners interacted with a deliberately minimal software stack. + +The results were revealing. + +During the observed period: + +* **362 HTTP requests** were received. +* **331 requests (91.4%)** resulted in **`404 Not Found`**. +* **20 requests (5.5%)** returned **`304 Not Modified`**, indicating normal browser caching. +* **11 requests (3.1%)** returned **`200 OK`**, serving legitimate published resources. + +The overwhelming majority of incoming requests were **not attempts to use the application**. + +They were attempts to identify technologies that were never deployed. + +--- + +# Introduction + +Modern software engineering frequently begins with a familiar question: + +> **"Which framework should we use?"** + +NX9 begins with a different question: + +> **"Do we need one at all?"** + +This distinction is fundamental. + +NX9 is not opposed to frameworks. + +Frameworks such as React, Angular, Laravel, Spring Boot, Django, and Next.js have solved genuine engineering problems at enormous scale. + +React solved Facebook's UI challenges. + +Angular addressed Google's enterprise applications. + +Laravel transformed PHP productivity. + +Those are significant engineering achievements. + +The question NX9 asks is simply: + +> **Does our project have those same problems?** + +Many self-hosted services do not. + +A documentation website. + +A URL shortener. + +An authentication server. + +A digital timestamping service. + +A lightweight dashboard. + +These applications often require reliability, simplicity, maintainability, and operational transparency far more than they require extensive framework ecosystems. + +NX9 therefore adopts a different philosophy. + +--- + +# The NX9 Philosophy + +Every NX9 project follows a common set of engineering principles. + +* Privacy First +* Self-Hosted First +* Linux Native +* Rust Native +* Single Binary Applications +* Explicit Routing +* Minimal Dependencies +* Open Source (FOSS) +* No Vendor Lock-In +* Operational Simplicity + +Rather than beginning with a framework and removing features, NX9 begins with the application itself and adds only the software required to solve the problem. + +Nothing more. + +Nothing less. + +--- + +# Complexity Is Not Free + +Every dependency introduces responsibility. + +Someone must eventually: + +* install it; +* configure it; +* update it; +* monitor it; +* patch it; +* audit it; +* understand it. + +Modern web applications frequently include: + +* thousands of npm packages; +* hundreds of indirect dependencies; +* build systems; +* transpilers; +* runtime environments; +* middleware layers; +* plugins; +* framework conventions. + +Each component may be valuable. + +Collectively, they also increase operational complexity and expand the software that must be maintained throughout the application's lifetime. + +NX9 therefore asks a much simpler engineering question: + +> **Can this problem be solved with significantly less software?** + +If the answer is yes, simplicity becomes the preferred engineering decision. + +--- + +# Production Snapshot + +This study is based entirely on production access logs collected after **nx9.in** became publicly accessible. + +This was **not**: + +* a penetration test; +* a laboratory simulation; +* synthetic benchmark traffic. + +It was ordinary Internet traffic. + +Within a short period of public exposure: + +* automated vulnerability scanners began probing the server; +* legitimate browsers accessed the published website; +* Twitter/X generated preview cards; +* search crawlers indexed the content; +* additional independent scanners continued probing throughout the observation period. + +--- + +# Observed Traffic + +During the observation period: + +| Response | Count | Percentage | +| ---------------- | ------: | ---------: | +| 404 Not Found | **331** | **91.4%** | +| 304 Not Modified | 20 | 5.5% | +| 200 OK | 11 | 3.1% | + +The most striking observation is that **over 91% of incoming requests were not attempts to use the application.** + +They were attempts to discover software that was never deployed. + +--- + +# What Were the Bots Looking For? + +Representative examples include: + +```text +/.env +/vendor/.env +/wp-admin/ +/wp-content/ +/wp-includes/ +/phpinfo.php +/admin.php +/public/css.php +/f35.php +/222.php +/chosen.php +/vercel.json +/vite.config.ts +/vendors~main.bundle.js +/vue/ +/v1/admin/ +``` + +These requests reveal remarkably consistent assumptions. + +| Requested Resource | What the Scanner Expected | +| ------------------------ | --------------------------- | +| `.env` | Laravel / PHP configuration | +| `vendor/.env` | Composer project | +| `wp-admin` | WordPress | +| `wp-content` | WordPress plugins | +| `phpinfo.php` | PHP runtime | +| `admin.php` | PHP administration panel | +| `f35.php` | PHP web shell | +| `public/css.php` | Vulnerable PHP application | +| `vite.config.ts` | Vite project | +| `vendors~main.bundle.js` | Webpack / React build | +| `vercel.json` | Vercel deployment | +| `vue/.env` | Vue application | + +The scanners were not attempting to identify NX9. + +They were attempting to identify technologies commonly deployed across today's Internet. + +--- + +# What Actually Happened? + +Every vulnerability probe received essentially the same response. + +```text +404 Not Found +``` + +Not because NX9 blocked the request. + +Not because a Web Application Firewall intercepted it. + +Not because an intrusion detection system analyzed it. + +The requested resources simply did not exist. + +This distinction is critical. + +There is a significant engineering difference between software successfully defending itself and software that was never deployed in the first place. + +--- + +# Explicit Routing + +NX9 applications expose only routes intentionally defined by the developer. + +Conceptually: + +```text +/ +├── / +├── /projects +├── /about +├── /contact +└── 404 +``` + +There is: + +* no automatic controller discovery; +* no runtime file resolution; +* no directory-based routing; +* no framework-generated endpoints. + +If a route was never implemented, it simply cannot be reached. + +Unknown requests terminate immediately at the fallback handler. + +--- + +# Security Begins Before Deployment + +Security is often discussed in terms of: + +* firewalls; +* intrusion detection systems; +* endpoint protection; +* monitoring platforms. + +Those remain valuable. + +However, architecture itself is also a security decision. + +The NX9 deployment contained: + +* no PHP interpreter; +* no WordPress; +* no Laravel; +* no Composer vendor directory; +* no Node.js runtime; +* no exposed `.env`; +* no framework-generated administration interface; +* no debug endpoints. + +Those components were never installed. + +Consequently, they never became part of the deployment's attack surface. + +This is not **security through obscurity**. + +It is **security through intentional software selection**. + +--- + +# A Smaller Stack + +Many modern web deployments resemble: + +```text +Internet + │ + ▼ +Reverse Proxy + │ + ▼ +Runtime + │ + ▼ +Framework + │ + ▼ +Middleware + │ + ▼ +Plugins + │ + ▼ +Packages + │ + ▼ +Application +``` + +NX9 deliberately reduces the deployment: + +```text +Internet + │ + ▼ +Nginx + │ + ▼ +Rust Binary + │ + ▼ +Explicit Route Table + │ + ▼ +Application Logic +``` + +The objective is not minimalism for its own sake. + +The objective is engineering proportional to the problem being solved. + +--- + +# Frameworks Are Not the Enemy + +This case study should not be interpreted as criticism of frameworks. + +Frameworks solve difficult engineering problems. + +Many projects genuinely require them. + +NX9 simply argues that every dependency should justify its existence. + +Engineering is not about choosing the most fashionable technology. + +It is about choosing the most appropriate technology. + +Sometimes that means a sophisticated framework. + +Sometimes that means a single Rust binary. + +--- + +# Legitimate Traffic Continued Normally + +An equally important observation is what **did** work. + +Legitimate clients successfully accessed the application throughout the observation period. + +This included: + +* desktop browsers; +* Android browsers; +* Twitter/X preview generation; +* search engine crawlers; +* browser cache validation (`304 Not Modified`). + +The minimal deployment remained fully functional for intended users while exposing no unnecessary application surface. + +--- + +# Non-Goals + +This article does **not** claim: + +* that Rust is immune to vulnerabilities; +* that frameworks are insecure; +* that 404 responses alone provide security; +* that NX9 cannot contain bugs. + +Instead, it demonstrates a much simpler engineering principle: + +> **Software that is never deployed cannot become part of your deployment's attack surface.** + +--- + +# Lessons Learned + +The production logs reveal a surprisingly simple truth. + +The overwhelming majority of unsolicited Internet traffic was not exploring the application itself. + +It was exploring assumptions. + +The scanners assumed: + +* PHP; +* WordPress; +* Laravel; +* Vue; +* Node.js; +* Composer; +* Vite; +* Vercel; +* common administration panels. + +NX9 deliberately deployed none of them. + +The result was not that sophisticated defensive software defeated the attacks. + +The result was that the attacks found nothing matching their expectations. + +--- + +# Conclusion + +Every NX9 project begins with the same engineering question: + +> **What is the smallest amount of software required to solve this problem well?** + +Sometimes that answer includes a framework. + +Often it does not. + +This case study demonstrates that software minimalism is not merely an aesthetic preference. + +It is an architectural decision with practical operational consequences. + +During the observed period, more than **91%** of incoming requests were attempts to identify technologies that simply were not present. + +That outcome was not accidental. + +It was the direct consequence of choosing a smaller, simpler, explicitly designed software stack. + +**Build only what you need.** + +**Deploy only what you trust.** + +**Maintain only what you own.** + +Because every component you choose **not** to deploy is one less component to configure, patch, monitor, audit—and one less component available to be targeted. + +**That is the NX9 philosophy.** diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..3435033 --- /dev/null +++ b/LICENSE @@ -0,0 +1,52 @@ +# License + +Copyright © 2026 Sunil Thakare + +This project is licensed under **either** of the following licenses, at your option: + +* Apache License, Version 2.0 +* MIT License + +You may choose either license for your use of this software. + +--- + +## Apache License 2.0 + +Copyright © 2026 Sunil Thakare + +Licensed under the Apache License, Version 2.0 (the "License"); +you may not use this software except in compliance with the License. +You may obtain a copy of the License at + +> https://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, software +distributed under the License is distributed on an **"AS IS" BASIS**, +WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +See the License for the specific language governing permissions and +limitations under the License. + +--- + +## MIT License + +Copyright © 2026 Sunil Thakare + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED **"AS IS"**, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/PHILOSOPHY.md b/PHILOSOPHY.md new file mode 100644 index 0000000..d870865 --- /dev/null +++ b/PHILOSOPHY.md @@ -0,0 +1,122 @@ +# NX9 Philosophy: Engineering Beyond Frameworks + +**A real-world case study in software minimalism, explicit routing, and reduced attack surface** + +> "The best way to reduce complexity is not to manage more software—it is to deploy less software." + +## Introduction + +Modern software engineering often begins with a familiar question: + +> "Which framework should we use?" + +NX9 begins with a different question: + +> "Do we need one at all?" + +This is not an argument against frameworks. Frameworks like React, Angular, Laravel, Spring Boot, and Next.js have solved incredibly hard problems and transformed development. + +But they solved *specific* problems. + +A personal website, a self-hosted utility, an authentication service, a URL shortener, or an infrastructure component rarely requires thousands of JavaScript packages, multiple runtimes, extensive middleware chains, complex build pipelines, and enormous dependency trees simply to deliver its intended functionality. + +For many projects, complexity becomes the default — not the requirement. + +NX9 deliberately chooses another path. + +## Production Snapshot + +The observations presented in this article come directly from the production logs of **nx9.in** after its first public deployment. + +They are **not** the result of a penetration test, laboratory simulation, or synthetic benchmark. + +During the observation period: + +- Multiple independent vulnerability scanners began probing the server shortly after public exposure. +- Automated requests targeted common framework artifacts, PHP files, WordPress installations, Laravel configuration, Vue projects, Docker deployments, and build-system outputs. +- Every vulnerability probe resulted in **404 Not Found**. +- Legitimate visitors — including desktop browsers, Android devices, Twitter/X crawlers, search crawlers, and internal users — continued to access the published resources normally. + +These observations provide a useful real-world case study of the NX9 engineering philosophy. + +## Engineering Beyond Frameworks + +NX9 is founded on a simple engineering principle: + +> Deploy only the software necessary to solve the problem. +> Nothing more. +> Nothing less. + +Every project within the NX9 ecosystem follows the same philosophy: + +- Privacy First +- Self-Hosted First +- Linux Native +- Rust Native +- Single Binary Applications +- Explicit Routing +- Minimal Dependencies +- Open Source (FOSS) +- No Vendor Lock-In +- Operational Simplicity + +Frameworks are not avoided because they are "bad." + +They are avoided when they solve problems the application simply does not have. + +Every dependency should justify its existence. +Every abstraction should earn its maintenance cost. +Every additional component should provide value greater than the complexity it introduces. + +## Complexity Has a Cost + +Modern applications are often assembled from enormous dependency trees. + +A simple "Hello World" project may involve: + +- thousands of npm packages +- hundreds of transitive dependencies +- multiple build tools +- package managers +- runtime environments +- framework-specific tooling +- automated code generation + +Each component is individually useful. +Collectively, they increase operational responsibility. + +Every additional dependency must eventually be: + +- installed +- configured +- updated +- audited +- monitored +- patched +- understood + +NX9 asks a simple engineering question: + +> Can this problem be solved with significantly less software? + +If the answer is yes, simplicity becomes the preferred design. + +## Real-World Validation + +Shortly after **nx9.in** became publicly accessible, automated scanners began probing the server. + +The requests were not random. They were highly characteristic of Internet-wide reconnaissance targeting common deployment technologies. + +Representative examples included: + +```text +/.env +/vendor/.env +/wp-admin/ +/wp-content/ +/phpinfo.php +/vercel.json +/vite.config.ts +/vendors~main.bundle.js +/vue/ +/v1/admin/ \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..3394a2e --- /dev/null +++ b/README.md @@ -0,0 +1,66 @@ +# NX9 + +**Next Generation 9** — A philosophy-driven ecosystem of self-hosted, privacy-first software. + +Every project is built around one core idea: + +> **Infrastructure should belong to its operator — not to a cloud provider, subscription service, or vendor.** + +### Philosophy + +NX9 is not a framework or a platform. It is a collection of independent, single-binary Rust applications designed for: + +- Operator ownership +- Privacy by default +- Self-hosting first +- Simplicity over complexity +- Long-term maintainability +- Zero telemetry or vendor lock-in + +We deliberately choose minimal dependencies, explicit routing, SQLite-first storage, and Linux-native design. The goal is software that is easy to understand, deploy, operate, and trust — even years from now. + +### Core Projects + +- **[nx9-url-shortener](https://codeberg.org/thakares/nx9-url-shortener)** + Multi-user URL shortener with analytics, QR codes, password protection, expiration, and tenant isolation. + +- **[nx9-auth](https://codeberg.org/thakares/nx9-auth)** + Lightweight identity and access management service with sessions, PATs, RBAC, and audit logging. + +- **[nx9-dns-server](https://codeberg.org/thakares/nx9-dns-server)** + Authoritative DNS server with DNSSEC support. Lightweight and designed for self-hosted use. + +- **[nx9-chronoseal-rs](https://codeberg.org/thakares/nx9-chronoseal-rs)** + Privacy-first browser attestation framework for anti-bot and anti-AI scraping protection. + +### Documentation + +- [Philosophy → Engineering Beyond Frameworks](https://nx9.in/case-study.html) +- [Architecture Overview](ARCHITECTURE.md) +- [Case Study: How Simplicity Defended Against Real Attacks](https://nx9.in/case-study.html) +- [Roadmap](ROADMAP.md) + +### Website + +The full website source is available in the [`www/`](www/) directory. + +### Values + +- Privacy by design +- Single binary deployments +- Explicit routing +- Operator sovereignty +- Open Source (permissive licenses) +- No telemetry. No vendor lock-in. + +### Get Involved + +- Star or fork the projects you find useful +- Open issues or discussions for feedback +- All projects are independent but share the same architectural principles + +--- + +**NX9** — Software people can own, understand, and control. + +Built by [Sunil Thakare](https://codeberg.org/thakares). \ No newline at end of file diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 0000000..14db731 --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,440 @@ +# NX9 Roadmap + +> **Engineering Beyond Frameworks** +> +> *Building a complete ecosystem of self-hosted, privacy-first, single-binary applications.* + +--- + +# Vision + +NX9 is not a single application. + +It is an ecosystem of independent, interoperable, self-hosted tools designed around a common engineering philosophy: + +* Build only what is necessary. +* Avoid unnecessary frameworks. +* Minimize dependencies. +* Keep deployments simple. +* Respect user privacy. +* Eliminate vendor lock-in. +* Remain fully open source. + +Every project should be deployable in minutes, understandable by a single engineer, and maintainable for years—not months. + +--- + +# Core Principles + +Every NX9 project follows the same architectural principles. + +## Privacy First + +No telemetry. + +No tracking. + +No analytics. + +Your data belongs to you. + +--- + +## Self-Hosted First + +Cloud deployment is optional. + +Self-hosting is the default. + +Users should own their infrastructure. + +--- + +## Linux Native + +Linux is the primary deployment platform. + +Applications should feel like first-class Linux software. + +--- + +## Rust Native + +Rust provides: + +* predictable performance +* memory safety +* modern tooling +* excellent concurrency +* minimal runtime requirements + +--- + +## Single Binary Applications + +Whenever practical: + +* one executable +* one configuration directory +* one service +* one deployment + +No dependency on heavyweight runtime ecosystems. + +--- + +## Explicit Over Implicit + +Nothing should happen "by convention." + +Routes. + +Configuration. + +Permissions. + +Features. + +Everything should be explicit. + +--- + +## Minimal Dependencies + +Dependencies are engineering decisions—not conveniences. + +Every dependency: + +* increases maintenance +* expands attack surface +* introduces supply-chain risk + +If a problem can be solved internally with reasonable effort, that may be preferable to importing another dependency. + +--- + +## Operational Simplicity + +Deployment should be boring. + +Installation should be boring. + +Upgrades should be boring. + +Reliability is more valuable than cleverness. + +--- + +# Current Projects + +## BZOD + +**Status:** Stable + +Privacy-first URL shortener. + +Features include: + +* custom aliases +* QR codes +* expiration +* password protection +* analytics +* audit logs +* REST API +* SQLite +* PostgreSQL +* Docker +* single-binary deployment + +--- + +## nx9-auth + +**Status:** Active Development + +Authentication platform designed for self-hosted applications. + +Goals include: + +* OAuth2 +* OpenID Connect +* JWT +* session management +* user management +* API authentication +* SSO for NX9 ecosystem + +--- + +## ChronoSeal + +**Status:** Planned + +Digital timestamping platform. + +Goals: + +* trusted timestamping +* immutable records +* hash verification +* document integrity +* long-term verification + +--- + +# Planned Ecosystem + +The long-term objective is a cohesive ecosystem where every application shares the same design philosophy and integrates naturally with the others. + +Potential projects include: + +## File Sharing + +Simple. + +Fast. + +Self-hosted. + +No unnecessary complexity. + +--- + +## Password Manager + +Encrypted. + +Offline-first. + +Self-hostable. + +--- + +## Notification Service + +Email. + +Webhooks. + +Push. + +Simple API. + +--- + +## Monitoring Dashboard + +Infrastructure monitoring. + +System health. + +Container health. + +Notifications. + +--- + +## Documentation Platform + +Markdown-first. + +Fast. + +Searchable. + +Single binary. + +--- + +## Workflow Automation + +Simple automation engine for self-hosted infrastructure. + +Designed for practical administration rather than enterprise complexity. + +--- + +# Technical Direction + +## Frontend + +Preference for: + +* HTML5 +* CSS3 +* Vanilla JavaScript + +JavaScript frameworks should only be introduced when they solve demonstrable engineering problems. + +--- + +## Backend + +Primary language: + +* Rust + +Preferred characteristics: + +* async +* efficient +* predictable +* memory safe + +--- + +## Database + +Primary: + +* SQLite + +Optional: + +* PostgreSQL + +Applications should not require a database server unless the workload justifies it. + +--- + +## APIs + +REST-first. + +JSON. + +Well documented. + +Versioned. + +Simple. + +--- + +## Deployment + +Supported environments: + +* Linux +* Docker +* Podman + +Future consideration: + +* FreeBSD + +--- + +## Reverse Proxy + +Recommended: + +* Nginx + +Applications should work behind any standards-compliant reverse proxy. + +--- + +# Security Philosophy + +Security begins with architecture. + +NX9 emphasizes: + +* explicit routing +* reduced attack surface +* minimal dependencies +* least privilege +* secure defaults +* modern cryptography +* reproducible builds + +Security features should emerge naturally from good engineering—not from accumulating layers of defensive software. + +--- + +# Non-Goals + +NX9 does **not** aim to: + +* replace every web framework; +* eliminate JavaScript; +* compete with enterprise platforms; +* build monolithic "all-in-one" systems; +* chase technology trends; +* optimize for resume-driven development. + +The objective is thoughtful engineering, not ideological minimalism. + +--- + +# Design Philosophy + +Every new feature should answer three questions: + +1. Does it solve a real problem? +2. Can it be implemented simply? +3. Does it increase long-term maintenance disproportionately? + +If the answer to the third question is **yes**, the feature should be reconsidered. + +--- + +# Success Criteria + +A successful NX9 application should be: + +* understandable by reading the source; +* deployable within minutes; +* maintainable by a small team—or even a single developer; +* performant without extraordinary hardware; +* secure through simplicity; +* pleasant to operate. + +--- + +# Community Principles + +NX9 welcomes contributions that align with its philosophy. + +Preferred contributions include: + +* bug fixes +* documentation +* accessibility improvements +* performance optimizations +* security improvements +* interoperability +* code simplification + +Contributions that significantly increase complexity without corresponding long-term value may not align with the project's direction. + +--- + +# Looking Forward + +The goal of NX9 is not to build the largest software ecosystem. + +It is to build one of the most coherent. + +Every project should feel familiar. + +Every deployment should feel predictable. + +Every application should respect the user's ownership of their data and infrastructure. + +The roadmap will continue to evolve as new ideas emerge, but one principle will remain unchanged: + +> **Choose the simplest architecture capable of solving the problem well.** + +Because software should empower its users—not burden them with unnecessary complexity. + +--- + +**NX9** + +*Engineering Beyond Frameworks.* +*Build only what you need.* +*Deploy only what you trust.* +*Maintain only what you own.* diff --git a/www/android-icon-144x144.png b/www/android-icon-144x144.png new file mode 100644 index 0000000..dc5d672 Binary files /dev/null and b/www/android-icon-144x144.png differ diff --git a/www/android-icon-192x192.png b/www/android-icon-192x192.png new file mode 100644 index 0000000..23eaf74 Binary files /dev/null and b/www/android-icon-192x192.png differ diff --git a/www/android-icon-36x36.png b/www/android-icon-36x36.png new file mode 100644 index 0000000..afc8771 Binary files /dev/null and b/www/android-icon-36x36.png differ diff --git a/www/android-icon-48x48.png b/www/android-icon-48x48.png new file mode 100644 index 0000000..cd7cacb Binary files /dev/null and b/www/android-icon-48x48.png differ diff --git a/www/android-icon-72x72.png b/www/android-icon-72x72.png new file mode 100644 index 0000000..5f9aa11 Binary files /dev/null and b/www/android-icon-72x72.png differ diff --git a/www/android-icon-96x96.png b/www/android-icon-96x96.png new file mode 100644 index 0000000..98b94e2 Binary files /dev/null and b/www/android-icon-96x96.png differ diff --git a/www/apple-icon-114x114.png b/www/apple-icon-114x114.png new file mode 100644 index 0000000..16abb12 Binary files /dev/null and b/www/apple-icon-114x114.png differ diff --git a/www/apple-icon-120x120.png b/www/apple-icon-120x120.png new file mode 100644 index 0000000..e4f2ea7 Binary files /dev/null and b/www/apple-icon-120x120.png differ diff --git a/www/apple-icon-144x144.png b/www/apple-icon-144x144.png new file mode 100644 index 0000000..37de658 Binary files /dev/null and b/www/apple-icon-144x144.png differ diff --git a/www/apple-icon-152x152.png b/www/apple-icon-152x152.png new file mode 100644 index 0000000..77dd1e1 Binary files /dev/null and b/www/apple-icon-152x152.png differ diff --git a/www/apple-icon-180x180.png b/www/apple-icon-180x180.png new file mode 100644 index 0000000..a49ddd3 Binary files /dev/null and b/www/apple-icon-180x180.png differ diff --git a/www/apple-icon-57x57.png b/www/apple-icon-57x57.png new file mode 100644 index 0000000..5564ed1 Binary files /dev/null and b/www/apple-icon-57x57.png differ diff --git a/www/apple-icon-60x60.png b/www/apple-icon-60x60.png new file mode 100644 index 0000000..f52c6b6 Binary files /dev/null and b/www/apple-icon-60x60.png differ diff --git a/www/apple-icon-72x72.png b/www/apple-icon-72x72.png new file mode 100644 index 0000000..5f9aa11 Binary files /dev/null and b/www/apple-icon-72x72.png differ diff --git a/www/apple-icon-76x76.png b/www/apple-icon-76x76.png new file mode 100644 index 0000000..81bdbda Binary files /dev/null and b/www/apple-icon-76x76.png differ diff --git a/www/apple-icon-precomposed.png b/www/apple-icon-precomposed.png new file mode 100644 index 0000000..e518b3a Binary files /dev/null and b/www/apple-icon-precomposed.png differ diff --git a/www/apple-icon.png b/www/apple-icon.png new file mode 100644 index 0000000..e518b3a Binary files /dev/null and b/www/apple-icon.png differ diff --git a/www/banner.png b/www/banner.png new file mode 100644 index 0000000..d1dfb12 Binary files /dev/null and b/www/banner.png differ diff --git a/www/browserconfig.xml b/www/browserconfig.xml new file mode 100644 index 0000000..c554148 --- /dev/null +++ b/www/browserconfig.xml @@ -0,0 +1,2 @@ + +#ffffff \ No newline at end of file diff --git a/www/case-study.html b/www/case-study.html new file mode 100644 index 0000000..22fdac9 --- /dev/null +++ b/www/case-study.html @@ -0,0 +1,1345 @@ + + + + + +NX9 — Next Generation 9 | Software people can own, understand, and control + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+

NX9 Philosophy: Engineering Beyond Frameworks

+

A real-world case study in software minimalism, explicit routing, and reduced attack surface

+
+

"The best way to reduce complexity is not to manage more software—it is to deploy less software."

+
+
+

Introduction

+

Modern software engineering often begins with a familiar question:

+
+

"Which framework should we use?"

+
+

NX9 begins with a different question:

+
+

"Do we need one at all?"

+
+

This is not an argument against frameworks.

+

Frameworks have transformed software development and solved some of the most challenging engineering problems ever encountered.

+

React revolutionized large-scale user interfaces at Facebook.

+

Angular addressed Google's enterprise-scale application requirements.

+

Laravel dramatically improved developer productivity for PHP applications.

+

Spring Boot simplified enterprise Java development.

+

Next.js made sophisticated React applications easier to deploy.

+

These are remarkable engineering achievements.

+

But they solved specific engineering problems.

+

The question every project should ask is:

+
+

Do we have those same problems?

+
+

A personal website, a self-hosted utility, an authentication service, a URL shortener, or an infrastructure component rarely requires thousands of JavaScript packages, multiple runtimes, extensive middleware chains, complex build pipelines, and enormous dependency trees simply to deliver its intended functionality.

+

For many projects, complexity becomes the default—not the requirement.

+

NX9 deliberately chooses another path.

+
+

Production Snapshot

+

The observations presented in this article come directly from the production logs of nx9.in after its first public deployment.

+

They are not the result of a penetration test, laboratory simulation, or synthetic benchmark.

+

During the observation period:

+
    +
  • Multiple independent vulnerability scanners began probing the server shortly after public exposure.
  • +
  • Automated requests targeted common framework artifacts, PHP files, WordPress installations, Laravel configuration, Vue projects, Docker deployments, and build-system outputs.
  • +
  • Every vulnerability probe resulted in 404 Not Found.
  • +
  • Legitimate visitors—including desktop browsers, Android devices, Twitter/X crawlers, search crawlers, and internal users—continued to access the published resources normally.
  • +
+

These observations provide a useful real-world case study of the NX9 engineering philosophy.

+
+

Engineering Beyond Frameworks

+

NX9 is founded on a simple engineering principle:

+
+

Deploy only the software necessary to solve the problem.

+
+

Nothing more.

+

Nothing less.

+

Every project within the NX9 ecosystem follows the same philosophy:

+
    +
  • Privacy First
  • +
  • Self-Hosted First
  • +
  • Linux Native
  • +
  • Rust Native
  • +
  • Single Binary Applications
  • +
  • Explicit Routing
  • +
  • Minimal Dependencies
  • +
  • Open Source (FOSS)
  • +
  • No Vendor Lock-In
  • +
  • Operational Simplicity
  • +
+

Frameworks are not avoided because they are "bad."

+

They are avoided when they solve problems the application simply does not have.

+

Every dependency should justify its existence.

+

Every abstraction should earn its maintenance cost.

+

Every additional component should provide value greater than the complexity it introduces.

+
+

Complexity Has a Cost

+

Modern applications are often assembled from enormous dependency trees.

+

A simple "Hello World" project may involve:

+
    +
  • thousands of npm packages;
  • +
  • hundreds of transitive dependencies;
  • +
  • multiple build tools;
  • +
  • package managers;
  • +
  • runtime environments;
  • +
  • framework-specific tooling;
  • +
  • automated code generation.
  • +
+

Each component is individually useful.

+

Collectively, they increase operational responsibility.

+

Every additional dependency must eventually be:

+
    +
  • installed;
  • +
  • configured;
  • +
  • updated;
  • +
  • audited;
  • +
  • monitored;
  • +
  • patched;
  • +
  • understood.
  • +
+

NX9 asks a simple engineering question:

+
+

Can this problem be solved with significantly less software?

+
+

If the answer is yes, simplicity becomes the preferred design.

+
+

Real-World Validation

+

Shortly after nx9.in became publicly accessible, automated scanners began probing the server.

+

The requests were not random.

+

They were highly characteristic of Internet-wide reconnaissance targeting common deployment technologies.

+

Representative examples included:

+
/.env
+/vendor/.env
+/wp-admin/
+/wp-content/
+/phpinfo.php
+/vercel.json
+/vite.config.ts
+/vendors~main.bundle.js
+/vue/
+/v1/admin/
+

These examples represent many similar probes observed throughout the production logs.

+

The scanners were attempting to identify technologies rather than applications.

+
+

What the Bots Assumed

+ + + + + + + + + + + +The production logs demonstrate a simple reality:

+

The scanners were not looking for NX9.

+

They were looking for technologies that dominate today's web.

+

NX9 simply wasn't one of them.

+
+

What Actually Happened

+

Every probe produced essentially the same result.

+
404 Not Found
+

Not because NX9 blocked the requests.

+

Not because a Web Application Firewall analyzed malicious behaviour.

+

Not because an intrusion prevention system intervened.

+

The requested resources simply did not exist.

+

This distinction is important.

+

There is a fundamental difference between software successfully defending itself and software that was never deployed in the first place.

+
+

Security Begins Before Deployment

+

Security is often associated with firewalls, intrusion detection systems, endpoint protection, and monitoring platforms.

+

Those remain valuable.

+

However, architecture itself is also a security decision.

+

The production deployment contained:

+
    +
  • no PHP interpreter;
  • +
  • no WordPress;
  • +
  • no Laravel;
  • +
  • no Composer vendor directory;
  • +
  • no Node.js runtime;
  • +
  • no exposed .env files;
  • +
  • no framework-generated administration interfaces;
  • +
  • no debug endpoints;
  • +
  • no unnecessary middleware.
  • +
+

Those components were never installed.

+

Consequently, they were never available for attackers to discover.

+

This is not security through obscurity.

+

It is security through intentional software selection.

+
+

Explicit Routing

+

One of the defining characteristics of NX9 applications is explicit routing.

+

Only routes intentionally defined by the developer exist.

+

Conceptually:

+//projects/about/contact404 (Fallback) +

There is no directory discovery.

+

There is no automatic controller resolution.

+

There is no runtime searching for matching files.

+

If a route was never implemented, it simply cannot be reached.

+

Unknown URLs immediately terminate at the application's fallback handler.

+
+

A Smaller Stack

+

Many modern web applications resemble:

+ + + + + + + InternetReverse ProxyRuntimeFrameworkMiddlewarePluginsPackagesApplication +

NX9 deliberately reduces the stack.

+ + + + + + + InternetNginxRust BinaryExplicit Route TableApplication Logic +

The objective is not minimalism for its own sake.

+

The objective is proportional engineering.

+
+

Why NX9 Chose This Path

+

The previous comparison is not intended to suggest that one architecture is universally superior.

+

Frameworks remain exceptional engineering tools.

+

React solved Facebook's problems.

+

Angular solved Google's.

+

Laravel dramatically improved PHP development.

+

Spring Boot transformed enterprise Java.

+

Those achievements deserve recognition.

+

NX9 simply asks a different question:

+
+

Does this framework solve our problem?

+
+

If the answer is yes, use it.

+

If the answer is no, adding it merely increases long-term complexity.

+

Engineering is not about choosing the most popular technology.

+

It is about choosing the most appropriate one.

+
+

The Production Logs Tell a Story

+

The production logs describe a remarkably ordinary day on the public Internet.

+ + + + + + + Public deploymentAutomated vulnerability scannersSearch engine and social crawlersTwitter/X preview generationReal desktop and mobile visitorsAdditional vulnerability scanners +

The site remained fully functional for legitimate users while automated scanners repeatedly searched for technologies that simply were not present.

+
+

Less Software Means Less Responsibility

+

Every dependency becomes another responsibility.

+

Someone must:

+
    +
  • update it;
  • +
  • audit it;
  • +
  • patch it;
  • +
  • monitor it;
  • +
  • understand it.
  • +
+

Every framework introduces conventions.

+

Every plugin introduces assumptions.

+

Every runtime introduces operational complexity.

+

None of these are inherently negative.

+

They are engineering trade-offs.

+

NX9 deliberately chooses different trade-offs.

+

Smaller deployments.

+

Fewer dependencies.

+

Explicit behaviour.

+

Simpler operations.

+
+

Non-Goals

+

NX9 does not attempt to:

+
    +
  • replace every web framework;
  • +
  • eliminate JavaScript;
  • +
  • discourage modern development practices;
  • +
  • claim that Rust is immune to vulnerabilities;
  • +
  • promote security through obscurity.
  • +
+

NX9 simply argues that software should be proportional to the problem being solved.

+
+

Conclusion

+

This philosophy extends beyond a single website.

+

Every NX9 project—whether it is a URL shortener, an authentication service, a digital timestamping platform, or future infrastructure components—begins with the same engineering question:

+
+

What is the smallest amount of software required to solve this problem well?

+
+

The answer will not always be the same.

+

Some problems genuinely require sophisticated frameworks.

+

Many do not.

+

NX9 exists to explore that second category.

+

Not because minimalism is fashionable.

+

Not because frameworks are flawed.

+

But because simplicity remains one of the most effective engineering tools available.

+

The production logs provide a practical demonstration of this philosophy.

+

The Internet searched for PHP.

+

It searched for WordPress.

+

It searched for Laravel.

+

It searched for Vue.

+

It searched for Node.js deployment artifacts.

+

It searched for technologies that have become commonplace.

+

What it found instead was a deliberately minimal Rust application exposing only the functionality it was designed to provide.

+

That outcome was not accidental.

+

It was the result of an engineering decision made long before the first HTTP request reached the server.

+

Build only what you need.

+

Deploy only what you trust.

+

Maintain only what you own.

+

Because every component you choose not to deploy is one less component to configure, patch, monitor, audit—and one less component available to be targeted.

+

That is the NX9 philosophy.

ProbeLikely Assumption
/.envLaravel / PHP configuration
/vendor/.envComposer project
/wp-admin/WordPress
/wp-content/WordPress plugins
/phpinfo.phpPHP runtime
vite.config.tsVite project
vendors~main.bundle.jsWebpack / React build
vercel.jsonVercel deployment
/vue/.envVue project
/v1/admin/Administrative API
+
+
+ + + + + + \ No newline at end of file diff --git a/www/docker-compose.yaml b/www/docker-compose.yaml new file mode 100644 index 0000000..ac063fe --- /dev/null +++ b/www/docker-compose.yaml @@ -0,0 +1,47 @@ +name: nx9-www +services: + nx9-www: + cpu_shares: 90 + command: [] + container_name: nx9-www + deploy: + resources: + limits: + memory: 31940M + hostname: nx9-www-www + image: nginx:alpine + labels: + icon: https://github.com/thakares/nx9-www-rs/raw/main/logo/nx9-www.svg + ports: + - mode: ingress + target: 80 + published: "8484" + protocol: tcp + restart: unless-stopped + volumes: + - type: bind + source: /DATA/AppData/nx9-www + target: /usr/share/nginx/html + read_only: true + bind: + create_host_path: true + devices: [] + cap_add: [] + environment: [] + networks: + - default + privileged: false +networks: + default: + name: nx9-www_default +x-casaos: + author: self + category: self + hostname: "" + icon: https://github.com/thakares/nx9-www-rs/raw/main/logo/nx9-www.svg + index: / + is_uncontrolled: false + port_map: "8484" + scheme: http + title: + custom: nx9-www diff --git a/www/favicon-16x16.png b/www/favicon-16x16.png new file mode 100644 index 0000000..dfedb7b Binary files /dev/null and b/www/favicon-16x16.png differ diff --git a/www/favicon-32x32.png b/www/favicon-32x32.png new file mode 100644 index 0000000..53476c8 Binary files /dev/null and b/www/favicon-32x32.png differ diff --git a/www/favicon-96x96.png b/www/favicon-96x96.png new file mode 100644 index 0000000..6cba788 Binary files /dev/null and b/www/favicon-96x96.png differ diff --git a/www/favicon.ico b/www/favicon.ico new file mode 100644 index 0000000..d33b52c Binary files /dev/null and b/www/favicon.ico differ diff --git a/www/icon.svg b/www/icon.svg new file mode 100644 index 0000000..79460be --- /dev/null +++ b/www/icon.svg @@ -0,0 +1,16 @@ + + + + + + + + + + + + + + + + diff --git a/www/index.html b/www/index.html new file mode 100644 index 0000000..aef865a --- /dev/null +++ b/www/index.html @@ -0,0 +1,1068 @@ + + + + + +NX9 — Next Generation 9 | Software people can own, understand, and control + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +
+
+

nx9 --version

+ +

Next Generation 9

+
Software people can own, understand, and control.
+

NX9 is a philosophy-driven ecosystem of independent, self-hosted, privacy-first infrastructure software — single-binary Rust applications built for people and organizations who would rather run their own infrastructure than rent someone else's. No telemetry. No subscriptions. No mandatory cloud.

+ + +
+
+ +
+
+
+

NX9 is not a framework, and it is not a cloud product that happens to support self-hosting. It is a collection of carefully engineered, single-binary Rust applications — designed for individuals and organizations that value ownership, simplicity, and independence, and built to run equally well on a Raspberry Pi, a mini PC, a VPS, or air-gapped government infrastructure.

+
+
+
+ +
+
+
+

01 — Design Philosophy

+

Principles That Don't Change Per Project

+

Nine commitments that stay constant across every NX9 application, regardless of what it does.

+
+
+
+
+ +
+
+
+

02 — Architecture

+

Core Architectural Pillars

+

Every NX9 application is built on the same nine foundations — the same reason a BZOD deployment and a ChronoSeal deployment feel like they came from the same shop.

+
+
+ +
+

Security Stack

+

Embedded, Not Bolted On

+

Modern cryptographic primitives and hardened defaults, standardized across the whole ecosystem.

+
+
+ +
+

Positioning

+

The NX9 Trade-off, Made Explicit

+
+
+ + + + + +
Traditional StackNX9
+
+
+
+ +
+
+
+

03 — Ecosystem

+

Current Projects

+

Four projects are currently available. The NX9 ecosystem is designed to grow into a family of nine focused, self-hosted applications.

+
+ +
+ +

Codeberg is the canonical home of NX9. GitHub repositories are maintained as mirrors to improve discoverability and make adoption easier.

+
+ +
+ +
+
+
+ +
+
+
+

04 — Vision

+

Why NX9 Exists

+
+
+

In an era of cloud lock-in, subscriptions, and heavy dependencies, NX9 builds software that serves humanity — not platforms.

+

Technology should empower people to own their infrastructure, data, and future.

+
+
+
+ +
+
+
+

05 — Values

+

Core Values

+

The twelve commitments every NX9 decision is measured against.

+
+
+
+
+ +
+
+
+

06 — Roadmap

+

Roadmap to Nine

+
+

NX9 is not a single application — it is an ecosystem of nine focused, interoperable tools built around ownership, privacy, simplicity, and open standards. Four projects are already available, with five more planned to complete the vision.

+ +
+ +

Nodes are ordered by ship date, not ambition — chronoseal, dns-server, auth, and url-shortener shipped in that sequence. Five more applications are planned to complete the family of nine, reusing the same Tokio · Axum · SQLite · Argon2 · Ed25519 · BLAKE3 foundation.

+
+
+ +
+ + + + + + \ No newline at end of file diff --git a/www/logo.png b/www/logo.png new file mode 100644 index 0000000..1501d7f Binary files /dev/null and b/www/logo.png differ diff --git a/www/logo.svg b/www/logo.svg new file mode 100644 index 0000000..3e31442 --- /dev/null +++ b/www/logo.svg @@ -0,0 +1,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + NX9 + + + OWN YOUR INFRASTRUCTURE. + + diff --git a/www/manifest.json b/www/manifest.json new file mode 100644 index 0000000..013d4a6 --- /dev/null +++ b/www/manifest.json @@ -0,0 +1,41 @@ +{ + "name": "App", + "icons": [ + { + "src": "\/android-icon-36x36.png", + "sizes": "36x36", + "type": "image\/png", + "density": "0.75" + }, + { + "src": "\/android-icon-48x48.png", + "sizes": "48x48", + "type": "image\/png", + "density": "1.0" + }, + { + "src": "\/android-icon-72x72.png", + "sizes": "72x72", + "type": "image\/png", + "density": "1.5" + }, + { + "src": "\/android-icon-96x96.png", + "sizes": "96x96", + "type": "image\/png", + "density": "2.0" + }, + { + "src": "\/android-icon-144x144.png", + "sizes": "144x144", + "type": "image\/png", + "density": "3.0" + }, + { + "src": "\/android-icon-192x192.png", + "sizes": "192x192", + "type": "image\/png", + "density": "4.0" + } + ] +} \ No newline at end of file diff --git a/www/ms-icon-144x144.png b/www/ms-icon-144x144.png new file mode 100644 index 0000000..37de658 Binary files /dev/null and b/www/ms-icon-144x144.png differ diff --git a/www/ms-icon-150x150.png b/www/ms-icon-150x150.png new file mode 100644 index 0000000..7113eb4 Binary files /dev/null and b/www/ms-icon-150x150.png differ diff --git a/www/ms-icon-310x310.png b/www/ms-icon-310x310.png new file mode 100644 index 0000000..dc28418 Binary files /dev/null and b/www/ms-icon-310x310.png differ diff --git a/www/ms-icon-70x70.png b/www/ms-icon-70x70.png new file mode 100644 index 0000000..6b1b24b Binary files /dev/null and b/www/ms-icon-70x70.png differ