Planning Athas extension support

[piotrmaciejbednarski]

Here’s a quick summary of what we discussed on Discord about the future of Athas and how the editor should support extensions.

Compatibility with VSCode Extensions

One key idea we agreed on is that Athas extensions should be at least partially compatible with existing VSX extensions made for Visual Studio Code. Technically, that’s totally allowed - the VSC API is under the MIT license, so as long as we refer to the official repo and credit the authors, we’re good.

However, we need to be careful with the legal stuff around the VSCode Marketplace. Microsoft doesn’t allow VSCode extensions to be published anywhere outside their own marketplace. This is clearly mentioned in section 1b of their “Visual Studio Marketplace Terms of Use”:

Marketplace Offerings are intended for use only with Visual Studio Products and Services and you may only install and use Marketplace Offerings with Visual Studio Products and Services.

So, legally, the better option would be to integrate with Open-VSX, which is an open-source alternative. This way, we avoid breaking Microsoft’s terms and stay license-compliant.

Native API vs. Full Compatibility

I suggest we create our own native Rust API, but design it in a way that maps cleanly to the VSCode API - so we can build an automatic translator between the two.

Why Rust? Because it gives us full control over performance, architecture (using WASM), and we can really tap into what Tauri and Rust have to offer. The alternative would be to run extensions in V8, like VSCode does, but that means dealing with JavaScript, garbage collection, and a heavier runtime. Also, it makes less sense if we're using Tauri anyway.

Security is a big concern too. We should run extensions in isolated environments - no shared memory, and no direct access to Athas core. Otherwise, we’re basically creating “Vulnerability as a Service”. For more on why this matters, see issue #240 😉

Yes, JS with V8 can sometimes be faster for small tasks thanks to JIT and GC, but for most use cases, WASM should be good enough - especially for more complex or longer-running tasks.

Marketplace & Extension Distribution

I think we should build our own marketplace where users can publish:

1. Extensions made specifically for Athas
2. Auto-translated VSCode plugins

We could create a tool powered by an AI agent that uses RAG and embedded documentation (for both VSCode and Athas APIs) to auto-translate the code. We could host the embedding data using something like pgvector in PostgreSQL or even a lighter option like ChromaDB. The AI model could run locally or via a cloud provider.

This translation tool should be its own project and dockerized, so it doesn’t bloat Athas itself.

Suggestions

Here’s what I think we should do (but only after the alpha phase, since things are still pretty fluid):

• Design a native Rust API with clear inspiration to VSCode API.
• Prepare a documentation corpus and do a first-pass embedding.
• Test the RAG-powered translation on some example extensions.
• Launch our own marketplace and integrate it into Athas.

What do you think?