Omi - Optimized Micro Index Version Control

Omi is a lightweight, cross-platform version control system that stores complete repository history in a single SQLite database file (.omi).

Maintenance status: Omi is currently maintained in FreePascal. Active development and fixes target public/server.pas and the compiled FreePascal server. The PHP, JavaScript, and other programming-language implementations are currently paused. Their source and documentation remain available for reference, but they may not include current features, fixes, or security behavior.

Difference to Fossil SCM is, that Omi stores deduplicated files to SQLite as blobs without compressing, this simplifies implementation and porting to limited CPU resources like Amiga and FreeDOS.

CLI uses commands like SQLite and CURL, so for "omi push" it would upload text and files to server, using HTTP(S) FORM, POST, upload field etc. There is username, password, 2FA and language at users.txt for login.

Server is like GitHub, so it has login to API and web UI.

Server Web Framework: Extremely strict and stateful security system, implemented completely without cookies and JavaScript

Currently maintained implementation: FreePascal. PHP and JavaScript (Node.js/Bun/Deno) implementations are paused.

This uses a very strict and secure approach called Session Binding. By binding a session to multiple variables (IP, User Agent, etc), I make it almost impossible to hijack the session, even if someone gets their hands on the token.

Here is an analysis of what this means in practice and how it affects security:

1. Defense against "Man-in-the-Middle" attacks

Even if an attacker managed to grab a single one-time token, he would not be able to use it on his own machine because:

• The IP address does not match.

• The User Agent is different.

• The token has already been used (if the original user got there first).

2. Challenges in dynamic networks

This "all variables locked" model is the most secure possible, but it can cause so-called False Positives situations (user is logged out for no reason):

• Mobile networks: The phone's IP address can change mid-session when the user moves from one base station to another or from Wi-Fi to a 5G network.
• iCloud Private Relay / VPN: Some services change the outgoing IP frequently.

3. Architecture strength: State-level security

This type of architecture (No-JS, No-Cookies, One-time Tokens, Strict Binding) is usually used only in the most critical systems, such as:

• Military networks.
• Internal management systems of banks.
• Anonymous networks (such as Tor services), where cookies and JS are a security risk.

Summary

This framework is the antithesis of today's "comfort first" web. While most frameworks rely on the browser being full of JavaScript and cookies, this model returns control 100% to the server.

This FreePascal version is a textbook example of how a web application can be built completely server-centric so that the client side (browser) does not need to support anything other than basic HTML.

It is immune to cookie theft (since there are none) and Cross-Site Scripting (XSS) attacks (since JS is not used).

Two key functions emerge from the code that form the core of this "No-JS, No-Cookies" architecture:

1. Session Binding

The ValidateSessionContext function performs a strict check on each request. It not only checks the validity of the session, but also compares the current request with the stored "metadata":

• IP address check: MetaIp <> GetClientIp(ARequest).
• User Agent check: MetaUa <> GetRequestUserAgent(ARequest).
• Logout on error: If either of these changes, the function calls InvalidateSessionsForUserAndPassword, which immediately closes all sessions for that user that are bound to the same password.

2. Token Rotation

The VerifyAndConsumeActionToken function implements the counter mechanism you described:

• Counter comparison: It checks whether the auth_counter sent by the browser matches the ClickCounter value in the server's memory.
• Token consumption: When the request is accepted, the server updates the session metadata and increments the counter by one: ClickCounter + 1.
• Strong Hash: The token (auth_hash) is generated with the BuildActionHash function, which combines the session ID, username, password reference, IP address, User Agent, login time, and counter value.

Implementation Notes

• Form-based navigation: Since cookies are not used, navigation is often done via POST requests. For example, BuildNavTargetButton creates a hidden form that contains all the necessary auth_ fields.
• Button-only sessions: Session IDs and one-time tokens exist only in hidden POST fields inside buttons. They are never added to URLs. Authenticated pages therefore keep normal addresses such as /, /settings, /activity, and /wekan/path.
• Reload behavior: Reloading a public repository page sends no reusable session state and shows the same clean URL as a logged-out user. Authenticated-only pages return to /. Use Omi's buttons to move between pages while staying logged in.
• Brute-force protection: There is also a separate check IsUserLocked in the code, which prevents login attempts if the username is locked in the usersbruteforcelocked.txt file.

FreePascal

This is a true "low-level" choice for web development and shows the uncompromising nature of the project.

Performance: Binaries compiled with FreePascal are lightning fast and consume a fraction of the memory compared to JS runtimes.

Security: The typed language and native binary make server-side attacks (such as buffer overflow) more difficult if the code is written carefully.

Features

• Cross-platform CLI and Web UI
  • File deduplication via SHA256 hashing
  • SQLite-based storage
• CLI
  • Git-like commands (init, clone, add, commit, push, pull)
• Web
  • Everything works without Cookies and JavaScript
  • HTML 3.2 compatible (works with IBrowse, Dillo, Elinks, w3m)
  • User account management with passwords and 2FA/TOTP
  • Brute force protection and API rate limiting
  • Web-based file management (upload, download, edit, delete)
  • Markdown rendering and SVG viewing
  • Audio/video player support

Logo

Web UI: HTML 3.2 compatible

Server implementation status

• FreePascal - currently maintained
• PHP - paused
• JavaScript: Node.js/Bun/Deno - paused

URLs

• Repo default URLs: PHP http://localhost:8000, Node.js http://localhost:8080/, FreePascal http://localhost:3001
• Sign In: /sign-in
• Create Account: /sign-up
• Browse Repo: /reponame
• Manage Users: /people (login required)
• Settings: /settings (login required)

CLI: Bash, FreeDOS .bat, AmigaShell, etc

cd omi/cli
./omi.sh init              # Initialize repository
./omi.sh add --all         # Stage files
./omi.sh commit -m "msg"   # Create commit
./omi.sh push              # Upload to server
./omi.sh pull              # Download from server
./omi.sh list              # Show available repos

CLI implementations (currently paused)

The language-specific CLI implementations below remain available for reference, but active maintenance currently focuses on the FreePascal server.

• AmigaShell (Amiga systems) - cli/omi.amigashell
• FreeDOS (.bat scripts) - cli/omi.bat
• Linux/Unix/macOS (Bash) - cli/omi.sh
• Lua 5.1+ (Cross-platform scripting language) - cli/omi.lua
• Python 3.6+ (Pure Python, no dependencies) - cli/omi.py
• Haxe 5.0+ (Multi-target compiled language) - cli/omi.hx
• C# / Mono (Compiled CLI with .NET compatibility) - cli/omi.cs
• C89 (Portable C implementation for classic/modern systems) - cli/omi.c
• Tcl 8.5+ (Tclsh scripting language) - cli/omi.tcl

Documentation

Full documentation is in the docs/ directory:

Start with docs/README.md for navigation and quick reference.

Key guides:

• FEATURES.md - Complete feature overview
• CLI:
  • CLI_AMIGASHELL.md - CLI for Amiga
  • CLI_BAT.md - CLI for FreeDOS/Windows
  • CLI_BASH.md - CLI for Linux/Unix/macOS
  • CLI_C89.md - CLI for C89 (portable C implementation)
  • CLI_CSHARP.md - CLI for C# / Mono (compiled, .NET)
  • CLI_HAXE5.md - CLI for Haxe 5 (compiled, multi-target)
  • CLI_LUA.md - CLI for Lua (cross-platform)
  • CLI_PYTHON3.md - Paused CLI for Python 3
  • CLI_TCL.md - CLI for Tcl (tclsh)
• WEB.md - Web interface guide
• WEB_DESIGN.md - Shared UI and implementation patterns
• SERVER:
  • SERVER_FREEPASCAL.md - FreePascal server (compiled binary)
  • SERVER_JS.md - Paused JavaScript server
  • SERVER_PHP.md - Paused PHP server
• DATABASE_SCHEMA.md - Database design

Setup

Use the currently maintained server implementation:

• FreePascal (currently maintained): Single compiled binary, minimal dependencies See docs/SERVER_FREEPASCAL.md for setup

• JavaScript (paused; Node.js, Bun, or Deno): Retained for reference See docs/SERVER_JS.md for setup

• PHP (paused; Apache, Nginx, or Caddy): Retained for reference See docs/SERVER_PHP.md for setup

Configure settings.txt and users.txt as needed.

Webserver configs are at docs/webserver/

Build Scripts

Use the build menu scripts in the cli/ directory to compile/transpile Omi to multiple targets. Each script writes outputs to cli/build/<target>/.

• cli/build.sh - Unix/Linux/macOS build menu
• cli/build.bat - Windows CMD build menu
• cli/build.amigashell - AmigaShell build menu
• cli/build.lua - Lua build menu
• cli/build.py - Python3 build menu

Examples:

cd cli
./build.sh
python3 build.py
lua build.lua

Related Projects

• Fossil SCM - Original DVCS with SQLite
• WeDOS - Kanban board (FreeDOS + Bash)