@mohitkrr2557

Today’s update closes one of the biggest gaps in Cyber OS’s in-browser experience: Brave is no longer a static prop showing a handful of hardcoded mock pages — type literally any URL into the address bar and it now resolves to a real page rendered live inside the browser window, with a proper loading state in the tab while it fetches and a working back/forward history stack once it’s in. Sites that refuse to be embedded (anything sending X-Frame-Options or a frame-ancestors CSP header) now fail gracefully into a clear “this site won’t load here — open it in a new tab” message instead of the silent blank pane the old build used to choke on. It sounds like a small change on paper, but it’s the difference between Brave being decoration on the desktop and an actual working browser — you can search, click through, and browse the real web without ever leaving the simulated OS.

Cyber OS v2.1 Devlog:
After roughly 150 hours since the last milestone, Cyber OS has moved from “looks like a desktop” to “behaves like one.” Where the previous release solved identity, session persistence, and the visual shell, this cycle was almost entirely focused on giving the file layer real teeth and giving the entire interaction surface a pass for latency, jank, and visual inconsistency. The result is a build that no longer just simulates file management and motion — it actually performs both.
The single biggest structural addition is a genuine virtual file system sitting underneath File Explorer, replacing what was previously a static icon list with no backing state. Every file is now a real node object — name, type, parent-directory reference, content payload, and a last-modified timestamp — serialized directly into the user’s persistent profile store instead of hardcoded into the DOM. Opening a file resolves its type against an app-association table and routes the payload into the correct handler, so text-type nodes stream straight into Space Notepad’s editable surface with two-way binding: in-app edits write back to the node’s content field on a debounced save cycle rather than firing a disk write on every keystroke. Deletion no longer just yanks a DOM element; it stages the node into a true Recycle Bin queue with restore and permanent-purge paths, and renaming is now an in-place editable operation with collision checks against sibling nodes so a file can’t silently clobber another with the same name. None of this existed before — files were effectively props with no underlying state machine. Now they’re a small but real persistence layer with actual create, open, edit, and delete semantics behind it.
On the visual side, the focus was smoothing every interaction that previously felt jarring or laggy under real use. Window open, close, and minimize transitions were rebuilt around a single eased transform-and-opacity curve instead of mismatched linear defaults, so windows scale and fade consistently rather than snapping into place. Drag and resize logic was rewritten to update transforms through the animation frame loop instead of writing styles synchronously on every pointer move, which cut visible stutter substantially on larger windows. Hover, focus, and active states across buttons, taskbar icons, and context menu items now pull from one shared elevation and shadow scale instead of ad hoc values scattered across components built at different times, so the desktop finally reads as one coherent surface instead of a patchwork of UI built in different sessions. Scrollbars, focus rings, and context menu animations were rebuilt to match the neon/glass aesthetic instead of falling back to browser defaults — one of the more obvious “unfinished” tells before, now gone.
Underneath the visible layer, a meaningful share of those 150 hours went into cleanup nobody sees directly but that the whole experience depends on: debouncing the autosave scrapers so they stop thrashing local storage on every keystroke, validating file payloads before they ever reach the profile serializer so a malformed or oversized entry can’t corrupt a session, and trimming redundant reflows that were firing every time a window gained focus or a flyout opened. None of it shows up in a screenshot, but it’s the difference between an OS that feels responsive under sustained use and one that only feels responsive in a thirty-second demo.
Taken together, the file engine and the motion pass were the two threads tying this update together — files now persist and behave like real file management instead of a mock-up, and the chrome around them finally moves the way a native desktop would. Next up: drag-and-drop file moves between folders, and carrying this same eased-transform approach into the snap-layout and alt-tab overlays, which still run on the older, snappier logic and now visibly lag behind everything else.

I have officially completed a massive architectural refactor of Cyber OS v2.0, transforming a simple frontend mock-up into a highly interactive, stateful, and secure multi-user desktop simulation environment. This milestone release successfully bridges a secure boot kernel, an encrypted local file engine, and a fully reactive visual compositing layer.

The core JS script now treats user sessions as persistent sandbox environments by running a secure boot cycle tied to browser local storage and custom profile serialization. To make the OS feel truly functional, I engineered automated data scrapers that continuously track and save a user’s local application modifications, including text inside the Space Notepad, active items within the Todo list, and chat logs inside the AI interface. These sessions are mapped directly to the authorized user’s profile and fully restored upon login, while strict kernel state flags manage layout depth and window minimizing queues.

Visually, the entire desktop environment has been upgraded to a hardware-accelerated layout pipeline powered by a modular CSS variable architecture. This decoupled theme system allows the entire UI to instantly toggle between a neon terminal space and a sleek light mode theme through a single class injection. The styling rules supply high-fidelity interactive state vectors for active running applications, introducing translucent container overlays, distinct border changes, and neon glow vectors for active or minimized windows.

Finally, the HTML scaffolding has been expanded to support modern desktop components, introducing a custom profile customizer on the boot screen and an advanced taskbar system. This taskbar hosts an active search utility, application launcher shortcuts, a terminal clock, and a hardware simulation tray complete with placeholder nodes for network, battery, and notification toggles. The system markup is fully optimized with hidden containment hooks, perfectly primed to anchor background canvas animation loops and edge-drag window snapping logic next.

I am going to continue advancing this OS to reach a windows desktop experties!

Project Update: Cyber OS

I’m stoked to share the progress on my custom WebOS! I’ve built a futuristic, space-themed desktop environment from scratch using pure HTML, CSS, and JavaScript, designed to feel like a high-performance digital cockpit running in the heart of a nebula.

I’ve engineered a custom window manager that handles dragging, closing, and dynamic z-index layering. This is paired with a built-in utility suite featuring a Space Notepad for captain’s logs, a dynamic Star-Date Calendar, and a functional Todo list for managing station operations.

Looking ahead, I’m preparing to launch a Wallpaper Engine for custom cosmic backgrounds and an AI Navigator Chatbot with a terminal-style interface.

Can’t wait to see this OS fully powered up!

lostify update!

Now there there is a functioning npm comand that allows us to fully run the application on a web brouser. However there is still work to be done to make the application fully functional, there is no backend aor frontend as of now.

The next step is to create a backend using node.js and express and then connect it to the frontend using react. I will also need to set up a database to store user data and other information. Once I have the backend and frontend set up, I can start working on the functionality of the application and make it fully functional.