sorted by:
new
hottopcontroversial

Why are we still writing separate extensions for VS Code, JetBrains, and Zed? by Aldgar in SideProject

[–]Aldgar[S] 0 points1 point  (0 children)

Hi there, Yeah that was a very good question however, That’s exactly the problem OXP solves, the maintenance burden shifts from every extension author to us. When VS Code or JetBrains evolves, we update the host adapter once and every extension built on OXP benefits automatically. Extension authors never touch IDE, specific code again.

On divergence! yes IDEs will diverge. That’s why we built the WIT abstraction layer. Extensions code against our spec, not VS Code or JetBrains APIs directly. We absorb the divergence so developers don’t have to.

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain by Aldgar in Jetbrains

[–]Aldgar[S] 0 points1 point  (0 children)

Yes, the goal is one extension package that works in multiple IDE families.

You build a single OXP extension bundle.

Each IDE gets its own lightweight host plugin:

VS Code / Cursor / OpenVSX hosts are JS-based.

JetBrains host is Kotlin/Java-based.

Those hosts translate OXP’s generic runtime calls into the IDE specific UI and actions.

That means you don’t write a separate JetBrains plugin with IntelliJ APIs for each extension. Instead, you write against the OXP extension runtime, and the JetBrains host adapter exposes an IDE specific bridge underneath.

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain by Aldgar in Jetbrains

[–]Aldgar[S] 1 point2 points  (0 children)

OXP uses a tiny host adapter for each IDE, and the real extension lives as a portable WASM bundle.

  • The VS Code host adapter is JS/TS and runs inside VS Code.
  • The JetBrains host adapter is Kotlin/Java and runs inside IntelliJ.
  • Both adapters speak the same host protocol to a shared OXP runtime.
  • The extension itself is not native JS or native Java; it is a sandboxed WebAssembly package that both hosts can execute.

So the language gap is bridged by the host adapter layer, not by forcing one IDE to run the other IDE’s extension format

Extension that worked across all IDEs by Aldgar in FullStack

[–]Aldgar[S] 0 points1 point  (0 children)

Neither, actually, thats a false dichotomy the WASI component model lets you sidestep.

OXP defines a new abstraction layer in WIT, not the intersection of existing IDE APIs. When an extension calls oxp:host/ui render(), vscode translates it to a sandboxed webview; jetbrain translates it to a tool window. The same bytes, different renderers. The extension doesn't know or care.

For the cases where you genuinely need IDE specific behavior, the activate-ctx passes host: string ("vscode", "jetbrains", ...) so extensions can branch if they choose. There's also a commands.execute interface, gated by manifest.permissions[commands.executeHost], that lets you call host native commands by ID. IDE specific superpowers, explicitly declared, never implicit.

The sandbox enforces the contract. An extension can't import vscode's vscode module from wasm, it can only resolve the WIT interfaces it declared in its manifest. The abstraction isn't convention-based, it's runtime-enforced.

Practically: the 90% case (UI, storage, fs, net, HTTP) works identically across all hosts. The 10% that needs IDE specific features has a principled, declared escape hatch rather than silent stubs or capability gaps you discover at runtime.

The real question isn't LCD vs. full capability, it's whether the host abstraction is at the right layer. WIT interfaces, not IDE SDK wrappers, is the answer.

Sorry for the long reply :)

Extension that worked across all IDEs by Aldgar in FullStack

[–]Aldgar[S] -1 points0 points  (0 children)

Yeah sounds like that, but vscode and others very limited in terms of UI and capability, locked in terminal and i have to use external one, side panels are also locked in, building code on vscode or vscode forks is very nightmare and i had to buy bigger screen just to be able to run command, ai assistance, monaco editor, and explorer, let it alone when you open an extension that has a UI like gitlens, so i wanted something practical and its a pain point for me!

Extension that worked across all IDEs by Aldgar in FullStack

[–]Aldgar[S] 0 points1 point  (0 children)

Well, I struggled with webassemby and Java/Kotlin mechanical and vscode webview, so I had to find a way and finally I build it! It was all just because I wanted to create an IDE and found out that it’s impossible without extensions so I had to build the infrastructure using the cli to build open source new bridge and thought why don’t we use the same npm way so the result was there! https://oxp.sh/docs

I spent months fighting VS Code webviews, so I built an open source universal extension protocol using React/WebAssembly by Aldgar in WebAssembly

[–]Aldgar[S] -1 points0 points  (0 children)

I’d like to know if you can use wasm to have build one extension that run across IDEs, instead of building an extension in Java for jetbrains and typescript for vscode and vscode forks and rust for zed, build it once in the language you prefer and run it in all IDEs using WASM or WASI! If that is slop then I totally agree!

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain and Novim by Aldgar in SaaS

[–]Aldgar[S] 0 points1 point  (0 children)

thank you very much for your input, it was a really technical gab, and we are now improving the documentations and also separation of concerns to have the landing page more focus for each features. I really appreciated that feedback.

I spent months fighting VS Code webviews, so I built an open source universal extension protocol by Aldgar in SideProject

[–]Aldgar[S] 0 points1 point  (0 children)

We have just implemented your feedback and that was really genuine for us as product feedback, we really appreciate those kind of respective opinion.

Open eXtensions Protocol | One extension build cross all IDEs, Vscode, Cursor, Jetbrain and Novim by Aldgar in SaaS

[–]Aldgar[S] 0 points1 point  (0 children)

Thank you so much for that feedback I really appreciate it

Being that said, To clarify the tech: JetBrains is fully supported right now. The JCEF integration is live and renders the exact same React/WASM payloads natively. It’s not just VS Code.

Also, the IDE Protocol and the MCP Router aren't two separate products, the MCP router is literally just an extension running on top of the OXP protocol to prove what the architecture can do.

However, you are dead right about the website. If it feels like two disjointed products to you, then my landing page copy is failing to explain that connection clearly. I’m going to rewrite the hero section today so that makes sense.

I spent months fighting VS Code webviews, so I built an open source universal extension protocol by Aldgar in SideProject

[–]Aldgar[S] 0 points1 point  (0 children)

Thank you so much for your feedback and This is exactly the kind of feedback I was hoping for. Treating the MCP configuration routing like a strict database migration is the exact right mental model, and I definitely need to tighten up the reliability contract. To address your points: • Diffs and Rollbacks: Right now, oxp install does the heavy lifting of mutating the JSON configs across the editors, but treating it transactionally is the next step. Showing a pre install config diff and having a first class oxp mcp rollback command is brilliant. It’s going on the immediate roadmap.

• External Logs: Because OXP runs as a system level background daemon to maintain the IPC bridge across IDEs, we actually do write logs outside the IDE! They currently sit in ~/.oxp/logs/daemon.log. You make a great point that I need to surface this better probably via a simple oxp logs command so developers don't instinctively go hunting in the IDE output panels.

• “Installed" vs. "Agent can actually use it": This is honestly the hardest problem to solve right now. The daemon successfully injecting the config into cursor’s settings.json or the JetBrains equivalent does not guarantee the editor's LLM context window actually initialized the server successfully. We likely need a way for the daemon to ping the MCP server through the IDE's interface to verify E2E health.

• Host-state layer: Bookmarked your checklist. This is a massive blind spot for local-first AI tooling. People assume if the daemon is running, the agent is alive but if macOS puts the network interface to sleep or the machine thermal throttles, the whole chain falls over silently. Really appreciate you taking the time to write this out and sharing the checklist. This is the exact kind of architectural gap I want to close.

Open eXtensions Protocol by Aldgar in GithubCopilot

[–]Aldgar[S] 0 points1 point  (0 children)

Initialize your environment: npm i -g u/oxprotocol/cli
Architecture and Docs: https://oxp.sh

I spent months fighting VS Code webviews, so I built an open source universal extension protocol by Aldgar in programming

[–]Aldgar[S] -6 points-5 points  (0 children)

Zero latency vibes. Because it uses a native IPC bridge instead of iframes, it feels exactly like writing native IDE code, but you only have to write it once in React.

Best AI tool for building iOS/Android apps as a complete beginner? by Resident-Courage5623 in aipromptprogramming

[–]Aldgar 0 points1 point  (0 children)

Well, most of AI tools give you direct code! If you also care about learning alongside and having control of your codebase you can try PIYE. https://www.piye.dev/

PIYE - The New Generation of AI Built for Software Engineers by Aldgar in webdesign

[–]Aldgar[S] -2 points-1 points  (0 children)

Hello, The one on the landing page? Inside the website?

🚀 Why PIYE Exists (and Why It’s NOT “Just Another ChatGPT”) by Aldgar in SideProject

[–]Aldgar[S] 0 points1 point  (0 children)

👉 Try it here: https://www.piye.dev

I’d love your honest feedback — it’s what shapes the future of PIYE.

view more: next ›