Developer Onboarding: How can we contribute to the Core?

Hi team,

I’ve been reading through the technical roadmap (specifically the Browser Core and WASM/App integration), and the vision is incredibly ambitious.

I know there are developers here (myself included) who have experience in C++, Systems Programming, and Rust and are ready to get our hands dirty to help build this.

To help us (and future contributors) get started, could you clarify the current contribution workflow?

  • Repository Status: Is the core browser fork currently open-source (GitHub/GitLab), or is it still in private development?
  • Architecture Entry Points: For those of us interested in low-level systems (e.g., the C++ Network Delegate for DDOC or the WASM Runtime), are there specific modules that are ready for external contributions?
  • “Good First Issues”: Do you have a list of smaller tasks or architectural spikes that new contributors can tackle to get familiar with the codebase?

I’d love to help document this process or set up a CONTRIBUTING.md once we have a clear path. Let’s get the community building!

Best , Peter

1 Like

Hi Peter!

I really appreciate your interest of getting involved and I will account all of your questions, I find your point of making a clear path really important, actually it’s work in progress

As soon as possible I will release the repo for the Orivon Browser base, which will be the Brave Fork, with some modifications to make it easy to build and integrate into IDE, so that cloning and a couple of commands will be enough to start coding and prototype on Orivon code easily for everyone
I hope to make it available as soon as possible

That will allow an easier creation of MVPs and solutions about the design of Orivon parts

We still need to make clearer technical design descriptions, so right now technical contributors can help defining that 3 points:

  • WASM Runtime, which is still the chromium one with V8, we just add new API’s to Blink implementing the needed raw functions, or limited ones for security reasons
    Then we write an ABI Description (the same way WASI has been created) so that any language compilable in Wasm can easly target Orivon to generate a compatible binary

  • Application system, we need to define how the basics of the Applications system works, how Apps communicate each other, how them does actually run, keep Mobile compatibility, and the design for each kind of App, which is going to define then how devs will be able to implement their own apps on Orivon

  • UI changes, actually UI contributions could be made now by modifying the current Brave UI, so that while the Application system becomes true the UI is already there ready to show it

Unless someone comes before on these points, I will work on these once the contribution workflow is ready

Once the Applications system becomes clearer, doors for devs to build their Integrations will gradually open, but 80% of the effort is to actually make up the entire Application system in first place