Build something useful.

Run the desktop browser

Use Node.js 22 or newer (an active LTS release is recommended). You need access to the private Vrifni/infibrowser repository.

git clone git@github.com:Vrifni/infibrowser.git
cd infibrowser
npm ci
npm test
npm start

npm run package creates an unpacked application. npm run dist builds installers for the current OS. The configuration targets macOS DMG/ZIP, Windows NSIS/portable, and Linux AppImage/DEB. Public releases require platform testing, signing, and updates; unsigned local builds are development artifacts.

Everyday controls

Use the address bar for a URL or a DuckDuckGo query. Ctrl/⌘ L focuses it, T opens a tab, W closes it, R reloads, and D bookmarks. Ctrl/⌘ Shift T opens a private tab. The ◐ button unloads the active page to release memory; unsaved page edits will be lost. Click Wake tab to reload it.

Ordinary tabs restore lazily, up to 32. Private tabs use a separate nonpersistent session and do not enter history or session restore. Downloads always ask for a save location and never open automatically.

Run on Android or iOS

The mobile client uses Flutter and webview_flutter: Android System WebView on Android and WKWebView on iOS. Install a Flutter SDK supporting Dart 3.13.1 or newer, the Android SDK, and Xcode for iOS.

cd apps/mobile
flutter pub get
flutter analyze
flutter test
flutter run
# Local development artifacts:
flutter build apk --debug
flutter build ios --simulator

Mobile v0.1 supports up to 16 tabs, local bookmarks, session restore, navigation, and search. Private sessions, managed downloads, and integration commands are desktop-only for this milestone. No store publishing or release signing is configured automatically.

Your first integration

Download the GitHub Search manifest, or save the following as infibrowser.json.

{
  "manifest_version": 1,
  "id": "com.example.github-search",
  "name": "GitHub Search",
  "version": "1.0.0",
  "description": "Find repositories and code on GitHub.",
  "permissions": ["tabs.create"],
  "commands": [{
    "id": "search",
    "title": "Search GitHub",
    "url": "https://github.com/search?q={query}"
  }]
}

1. Choose a stable, unique ID. Reverse-domain names work well.
2. Declare your permissions and a fixed HTTPS destination.
3. Run the validator below from the repository root.
4. In Infibrowser desktop, open Integrations → Install integration.
5. Review permissions and destination origins, then confirm installation.
6. Enter a query and run the command. A new browser tab opens.

npm run plugin:validate -- examples/search-github/infibrowser.json

Reinstalling the same ID replaces the manifest after another permission review. Disable pauses commands immediately; Remove deletes the installed manifest. There is no background updater or remote code loader.

Manifest contract

API v1 accepts a strict JSON object, no more than 32 KB. Unknown fields and permissions are rejected. Download the JSON Schema or the standalone Node.js validator. Runtime validation also checks URL safety, placeholder placement, permission dependencies, and unique command IDs.

Template inputs

Substitutions are URL-component encoded. Placeholders are allowed in paths, queries, and fragments, never in the scheme or host. Embedded username/password credentials are rejected. Commands require HTTPS, and page-sharing commands cannot run from private tabs.

const { validatePlugin, commandURL } = require('./core.cjs');
const manifest = validatePlugin(require('./infibrowser.json'));
const destination = commandURL(manifest, 'search', {
  query: 'a better browser'
});

Permissions & security

tabs.create opens a new tab only after the user runs a command. activeTab permits an integration to request the current page URL or title. Infibrowser displays a separate confirmation with the destination origin and current page before sharing context.

API v1 does not execute plugin JavaScript. It exposes no filesystem, shell, cookies, credential storage, page DOM, background network access, or unrestricted browser IPC. Third-party destinations remain external websites and have their own data policies.

The desktop browser isolates remote pages in sandboxed WebContentsView renderers without Node.js or browser-control preload scripts. Only the packaged UI can send privileged commands. Certificates use the engine’s normal validation. Camera, microphone, location, notifications, and device permissions are currently denied. Permission prompts are future work.

Architecture and language choices

Chromium supplies the desktop rendering engine through Electron. A small JavaScript control layer owns tabs, sessions, navigation validation, local persistence, and the integration registry. A framework-free UI keeps the chrome simple. Flutter provides a shared mobile interface while the OS maintains its webview engine.

Rust and Go do not replace a browser engine. We chose maintained, practical embedding layers for the first milestone. If profiling later identifies a CPU-heavy service or an isolation boundary that benefits from Rust, it can be added behind a narrow API.

Engine sources: Electron WebContentsView, Electron security guidance, Android WebView, Apple WKWebView. Infibrowser does not claim Chrome Web Store compatibility.

Website development & Docker

The product site, developer site, and documentation are static, self-hosted pages. No external fonts, trackers, or runtime framework are needed. All routes live under /infibrowser/.

npm run build
npm run dev
# http://127.0.0.1:8093/infibrowser/

docker compose up -d --build --wait
# http://127.0.0.1:8094/infibrowser/

Production uses the existing AWS Lightsail host and HTTPS gateway. The application container runs as an unprivileged user with a read-only filesystem, dropped capabilities, and no public application port. See docs/DEPLOYMENT.md in the repository for the staged deployment and rollback procedure.

What comes next

1. Validate desktop installers and mobile behavior on real devices. Establish repeatable startup, memory, battery, and compatibility benchmarks.
2. Sign releases and ship an automatic security-update channel.
3. Add carefully scoped website permission prompts, download controls, and better crash recovery.
4. Design executable extensions with process isolation, explicit host permissions, signing, revocation, and compatibility tests.
5. Extend integrations to mobile after platform policy and security review.
6. Evaluate optional encrypted sync and further browsing features from real usage.

This is an ordering of work, not a release-date commitment. v0.1 establishes a maintainable starting point.