Introducing Aether: The Open-Source Workspace Powered by AI

Managing digital workspace assets across local drives, remote servers, cloud platforms, and AI tools often feels fragmented. Aether is an open-source platform designed to unify your files, remote environments, workflows, and AI assistants into a single, cohesive experience.

Whether you need to manage distributed files, interact with smart AI agents, or run terminal sessions directly from your browser, Aether brings your workspace tools under one roof.

What Makes Aether Unique?

1. Unified Multi-Storage Access

Aether breaks down silos between storage services. Instead of juggling different tabs and cloud providers, Aether lets you seamlessly interact with local file systems, remote environments via SSH, and cloud storage like Google Drive inside one clean interface.

2. Embedded AI Assistants & Specialized Agents

Aether goes beyond standard file management by embedding AI into your daily tasks. From co-writing assistants and general helpers to specialized AI agents tailored for coding and productivity, smart assistance is always integrated directly alongside your files and documents.

3. Web-Based Terminal & Real-Time Connectivity

Work with your connected servers and local tools without leaving your browser. Built-in interactive terminal support and real-time updates provide a smooth, responsive workspace experience without requiring complex desktop setups.

4. Flexible Authentication & Customization

Designed for flexible deployment, Aether supports OpenID authentication, user setting controls, and modular provider configurations, making it easy to adapt to both individual needs and team environments.

Why Open Source?

Workspace management and productivity platforms should be transparent, extensible, and community-driven. Releasing Aether as open-source allows developers, creators, and power users to inspect, customize, and shape the future of unified digital workspaces together.

Whether you want to build custom AI agent skills, integrate new storage providers, or host Aether on your own infrastructure, the project is open for everyone.

Get Started

Aether is now live and available for self-hosting, testing, and contribution.

• Explore the Project: Check out the source code, installation steps, and technical architecture guidelines directly on GitHub.

• Get Involved: Report issues, suggest new features, or submit pull requests to help expand Aether's capabilities.

Welcome to a more connected way to work. Welcome to Aether.

How I Used Vibe Coding to Build HoloFrame: Bringing Big-Screen AR Back to Mac

 Like many people who picked up a pair of Xreal AR glasses, I had one simple dream: a massive, high-resolution virtual screen hovering right in front of my eyes wherever I opened my Mac. No bulky external monitors, no wasted desk space—just a giant floating workspace that goes wherever I do.

When Xreal originally launched their Nebula app for macOS, it felt like the future was finally here. But over time, official support waned, updates stalled, and the app became increasingly difficult to rely on. My glasses were slowly turning into an expensive pair of standard sunglasses sitting next to my laptop.

Instead of waiting for an official fix that might never come, I decided to build my own solution: HoloFrame.

Letting AI Do the Heavy Lifting: Enter "Vibe Coding"

If you told me a few years ago that I’d write software to communicate directly with hardware glasses, I probably would have laughed. Building something like this requires getting under the hood of hardware engineering:

• Decoding low-level USB HID protocols to talk to the glasses directly.

• Extracting raw IMU sensor data (accelerometers and gyroscopes).

• Performing complex 3D math and view-smoothing calculations so the screen stays firmly anchored in virtual space without making you feel motion sick.

Ordinarily, figuring out those low-level protocols and spatial calculations would require weeks of reading hardware specs and brushing up on advanced trigonometry. But in the era of vibe coding, I didn't need to write every line of math by hand.

I acted as the architect—defining the vision, testing the behavior, and steering the direction—while letting AI handle the grueling USB protocol plumbing and real-time head-tracking logic.

Meet HoloFrame

The result of this experiment is HoloFrame, a lightweight native Mac application designed to give you back your virtual multi-monitor experience.

Here is what HoloFrame brings to the table:

• Instant Big Screen Virtualization: Turns your Xreal glasses into a massive, crisp virtual display for macOS.

• Smooth Head Tracking: By leveraging custom sensor fusion and view smoothing, the screen stays pinned in mid-air seamlessly as you turn your head.

• Lightweight & Native: Built specifically for macOS, bypassing bloated frameworks to keep CPU usage low and battery life high.

• Zero Frustration: Plug in your glasses, launch the app, and get straight to work.

Why This Project Matters

HoloFrame started as a personal itch to fix a broken workflow, but it ended up demonstrating something bigger: hardware is no longer locked behind wall-off ecosystems.

When hardware companies move on or stop updating their software, community-driven development can step in. With AI acting as an assistant for low-level protocol decoding and mathematical crunching, building tailored software for your favorite gadgets is more accessible than ever.

If your Xreal glasses have been gathering dust because of unsupported Mac software, it's time to wipe them off. HoloFrame is here to give you back your workspace.

Check out the repo, try it out, and let me know how it works for your daily workflow!

Hemera — A Lightweight Bridge for Local & Cloud AI Models

Running local LLMs often means dealing with moving targets. Runtimes like llama.cpp move at a breakneck speed—sometimes releasing multiple builds in a single day. While that pace brings support for new quantizations immediately, an engine update today can easily break or regress a model that ran perfectly yesterday.

On top of that, managing different GPU backends (CUDA, ROCm, Vulkan), missing dynamic libraries, and setting up models for different client tools usually means juggling multiple local setups.

If you want to run local GGUF models—or route to cloud providers—without worrying about an engine update breaking your setup, you quickly run into friction.

That's why I came with idea of Hemera—a flexible local AI engine manager, wrapper, and proxy router written in Java.

The Spirit of the Project

The philosophy behind Hemera is simple: unify your AI tooling into one quiet, self-contained service.

Instead of juggling different local wrappers or hardcoding provider-specific integrations into your apps, Hemera sits in the middle. It acts as both a local engine orchestrator and a multi-dialect API translator.

I wanted a tool that:

• Doesn't force a framework on you: Zero external dependencies—no Maven, no Gradle, no heavy web frameworks, and no npm build step. Just JDK 21+ and a single 112 KB JAR file.

• Never deletes what worked: Engine builds live side-by-side. Updating llama.cpp never removes older versions, so if a new build misbehaves, you can roll back or pin a model to a previous tag in one click.

• Handles local & remote natively: Reads local GGUF files directly, manages backends (CUDA, ROCm, Vulkan) per model, and makes remote models (DeepSeek, OpenAI, Gemini, Claude) look like local endpoints.

Key Features

• One Endpoint, Three Dialects: Supports Ollama, OpenAI, and Anthropic Claude endpoints on a single port (12434). Every tool in your stack—from the native ollama CLI to Claude Code—can drive your models.

• Engine Versioning & Rollbacks: Keep multiple engine releases and GPU backends (ROCm, CUDA, Vulkan, SYCL, CPU) installed simultaneously without interference.

• Smart GPU Discovery (ELF Header Inspection): If a GPU build is missing vendor dynamic libraries, it often quietly falls back to CPU execution at a crawl. Hemera reads ELF headers on startup, detects missing .sodependencies, searches system paths, and automatically sets LD_LIBRARY_PATH for that process.

• Virtual Model Aliases: A single GGUF file can be configured as multiple named models—each with its own context size, GPU offload settings, chat templates, and environment variables.

• Native GGUF Inspection & Safe Deletion: Built-in direct GGUF header reading (GgufReader.java) parses metadata without external CLI tools. Deleting a model in the UI only drops the configuration, keeping expensive GGUF files safe.

• Minimalist Web Dashboard: An embedded, zero-framework web UI (vanilla HTML/CSS/JS) that follows your OS light/dark theme for monitoring running models, engine PIDs, and proxy settings.

Under the Hood (Architecture)

Hemera’s codebase is structured around a few core modules inside ing.aether.hemera:

ing.aether.hemera
├── api         # API dialects (OpenAI, Claude, Ollama) & Proxy Dispatcher
├── engine      # Engine downloaders, ELF/Tar handling, Instance lifecycle
├── model       # Bare-metal GGUF reader & Model Registry
├── http & json # Custom HTTP router & lightweight JSON engine
└── web         # Admin REST API endpoints & static dashboard assets

1. The Proxy & API Layer (hemera.api): Intercepts incoming requests, normalizes payloads via ProxyDispatcher, translates between protocols on the fly, and routes requests to local processes or cloud APIs while preserving Server-Sent Events (SSE) streaming.

2. The Engine Orchestrator (hemera.engine): Manages executable runtimes. It resolves required native shared libraries (LibraryResolver.java), handles binary archives (Tar.java), and manages the lifecycle of local engine processes (InstanceManager.java).

3. The Model Registry (hemera.model): Instead of relying on external CLI tools to inspect files, ModelScanner searches local directories and uses GgufReader to parse tensor metadata directly from binary headers to feed the central registry.

4. Core Infrastructure (hemera.http & hemera.json): Powered by a custom hand-rolled JSON parser and HTTP router running on Java's virtual threads for maximum efficiency.

Check out the code on GitHub: github.com/peprasetya/hemera

Vibrefy — a media server that doesn't watch you back

I finally open-sourced something I've been running for myself for a while: Vibrefy, a lightweight, self-hosted media server. Code's up on GitHub: github.com/peprasetya/Vibrefy.

The short version: it streams video from a local library, or from your own cloud storage (currently support: Google Drive, OneDrive, pCloud, or FileLu account), straight to the browser. The server proxies everything, so nothing but the video itself ever leaves it.

Why build another one, when Plex/Jellyfin/Emby already exist?

Two opinions I couldn't shake:

No database. Every media server I've used runs a database in the background — cataloguing, indexing, building a profile of what you watch. Vibrefy doesn't. Configuration lives in one JSON file, and the only per-user state is a small encrypted file that remembers where you left off in something, so it can resume it. That's it. No schema, no service to babysit, no "backup strategy" beyond copying a folder. You can move the whole install by dragging it to another disk.

The honest trade-off: there's no watch history, and nothing being collected to guess what you'll like next. If you want a recommendation engine, this isn't it. If you want something you can fully understand and hand to a friend without explaining a database schema, that's the whole point.

Landscape covers. Every media server inherits the vertical movie-poster look, because that's what DVD boxes and cinema posters happened to be shaped like. It's a strange default for something rendered on a screen. Vibrefy generates its thumbnails in 16:9, matching the video itself — so browsing looks like a shelf of screens, not a shelf of posters.

What it actually does:

• Browse and stream a local library, with resumable playback per file
• Mount your own cloud storage (currently support: Google Drive, OneDrive, pCloud, FileLu) and browse it exactly like a local folder
• Auto-play the next episode of a series
• Subtitles pulled straight out of the video container
• Cast to AirPlay, fullscreen, or Picture-in-Picture straight from the player
• OpenID login, first-run setup, no manual account provisioning, no password.

It's Java EE under the hood — Jakarta Servlets, JSP, vanilla JS, no framework sprawl — MIT licensed. Feedback, issues, and PRs welcome.