Neutron WEB6 Kernel over ICP

Developers
1

ntron.net

First public release. This release is for developers & adventurous users only.

Expect your Neutron to get accidentally bricked!
It requires ~4$ in cycles to deploy. Likely costs ~3$/mo to run - all of it cycle burn.
Invite code: DEVS

Highlights:

  • Chicken/egg loop - frontend compiles and installs the backend, backend serves the frontend - Users own both (1).
  • Developers can create apps without paying cycles (2) or worrying about tokens or decentralization (3).
  • Apps can collaborate at both the frontend and backend levels (4).
  • AI agents.
  • Vibecoding an app takes just hours.
  • Packs advanced #ICP cryptography features for blazing edge app development.
  • Apps are packaged as .neutron files that users can install.
  • User-sovereign Personal Cloud Computer — only the user is in control, just like with their personal computer.
  • GPLv3 - All apps are equal, no system apps, no Sherlocking (5). Owned by the world!

1,2,3,4,5 - Solutions for some of the biggest developer/user pain points.

@skilesare was co-author of the lightpaper which drafted some of it and was published long ago.

It currently deploys on the ICs new confidential TEE subnet!
I’ll tell you more about the apps and how they work, but I think it’s already a lot, so it’s better to just try it out and experience it.

2

ahhhhh…you built it!!!

I was trying to do this too, but I started from the wrong end and have been stuck in nuance hell for like 6 weeks. I’ll message you with what I have.

3

Can you add Settlers of Catan as well as chess? Actually no dont that may be a lot of work.

4

I don’t know if no one is here anymore or if no one is paying attention, but this is about 1000x more interesting than Multi/Dex…and if there is anyone is building an enterprise SAAS thingy and isn’t using this Neutron model, they are doing it wrong. This is data AND application sovereignty.

I have my Internet Computer now what do I do next @infu? I made a counter go to 6. Does everyone share that counter?

5

Maybe I misjudged you. What infu’s made here is absolutely a slice of fried gold.

6

This man is a kung fu master.

As the folks across the pond would say this looks to be bloody good stuff infu.

7

The counter in Kitchen Sink demonstrates how one tile connects to other tiles from the same app. They all run in isolated environments with separate origins. You could put another blackholed canister in the middle to share state, or have it DAO governed. There is also Neutron to Neutron.

The Wagyu app is a social network that demonstrates how peer-to-peer apps can work. There is no other than Neutron canisters involved to make it work. No single canister bottleneck.

Each Wagyu installation stores its owner’s posts as immutable, certified HTTP objects in their
Neutron. Following another user creates a cycles paid subscription on that user’s Neutron: the follow call attaches cycles that fund a lease and a limited number of delivery credits.

When someone posts, their Neutron first publishes and certifies the post, then pushes a compact
certified reference - not the full post - to eligible followers, attaching cycles to each inter-canister
delivery. Followers fetch the post over HTTP and verify it before displaying it.

When a user likes a post, their Neutron creates and certifies an immutable Like receipt and sends it to the original author. The author verifies the receipt and publishes it in certified Like packages.
Readers can therefore verify that each Like came from the claimed user’s Neutron, even though the package is served by the post author’s Neutron.

Sharing creates a separate certified action that references the original post and sends that reference to the sharer’s followers. Readers still fetch and verify the original post from its author.

The design keeps messages small, bounds fan-out and processing, and makes immutable HTTP objects cacheable by gateways and browsers. Peer-facing update routes accept only canister callers, enforce size and rate limits, and require enough attached cycles to meet a fixed processing floor.

Mail and File apps use vetKeys to derive and recover app-scoped encryption keys across authorized devices, keeping file and message content encrypted. Mail remains peer-to-peer, delivering messages directly between Neutrons. On top of that they now run in a confidential subnet with end to end encryption.

8

I wanted to take a look but it requires an invite code. I guess others got blocked at this stage too.

@infu is there a shared invite code or something that I’m missing

9

code is DEVS

chars chars chars chars chars

chars chars chars chars charschars chars chars chars charschars chars chars chars chars

10

Thanks. Oh yeah, it’s in the original post lol. Serves me right for skim reading

11

Wow, there’s a lot in there. I think something that would really help get my head around it is some demos, like an example of a few compositions that demonstrate different things that can be done - and then how to verify the claims that are made about sovereign ownership, build hash reproducibility etc.

This whole thing definitely sounds extremely promising. The community can establish trusted modules, and builders can avoid reinventing wheels and instead compose out of well established verified modules (or contribute new ones where some are lacking - and the community can come to verify and establish trust in those new modules).

Is that sort of the idea?

12

We should definitely do some demos and more end-user-oriented landing pages. This is intentionally for early adopters/devs so that people can try it out, help polish the rough edges, so normal users get a good experience.

You can check the controllers, it’s your principal and your canister. In order to check if the whole assembly compiler pipeline is not using external services but only what’s in your neutron, you need to check the code, which is open-source, or ask an agent to do it. The kernel is handling most of the security and apps are requesting permissions which the user approves.

Yes, that is a big part of the idea. You have an operating system, the kernel - like Linux (also has GPL license) that is what makes apps work. Without that you can’t put multiple apps inside one environment. If you can’t do that, you end up with hundreds of apps all around, much harder to discover and use. Devs reimplement a lot of the functionality in different ways, like identities, wallets, agents, file storage, contacts, social, etc. With different interfaces. In order to go around a bunch of IC apps you need to spend a day and learn all the different interfaces.

With Neutron you can add apps to your workspace, use them like a dashboard, or set your homepage to your canister. Take your morning coffee while checking out what’s going on in seconds. If you like AI, then ask your agent to compile you a summary, check your mail, socials, look at your markdown file knowledgebase, prepare replies - like a secretary of a sort. It works with all of your apps from different vendors.

There are some solutions now that take control of your whole PC, full access, and do that, but I doubt that’s the solution. People using the web historically don’t like installing software they download and prefer the convenience and security of a browser tab - it’s sandboxed and battle-tested for decades. I think it will be the same with agents and they wouldn’t like them having full disk access. Another use would be to create a neutron for every agent, each one having their own OS and context. Your digital secretary, your project manager, etc. Then the apps/tiles become a good way of observing what is going on. A chat box is good for some of the control, but isn’t that nice when you want to see things visually.

These are some of the ways I would use it, but don’t get limited by my imagination.

Why GPLv3? Interesting fact. Tivo boxes used Linux which has GPLv2, but locked the device so users couldn’t upgrade it and were forced to use what Tivo decides to put on these devices. This was named “Tivoization” and the reason GPLv3 was created, so that it makes sure that doesn’t happen and the license requires whoever deploys it to allow users to change it. Imagine me or someone else making an OS using the Neutron kernel, gathering a lot of users, but then going nuts or trying to put business logic inside to favor Sherlock apps (make their apps work better and remove the competition). The license restricts it from being deployed in a way that won’t let users change it to a fork that’s doing what was originally intended. It’s the most fair setup for developers and users I could think of.

13

@Lorimer to actually verify it I can give you the list. This needs a script of some sorts.

(1) Building the wasm compiler in this repo https://github.com/infu/neutron_motoko has to match the wasm installed in Neutron.

Motoko changes info

We made these four commits because the existing js_of_ocaml browser compiler was hitting JavaScript stack limits and could not compile a Neutron kernel with more than roughly three apps; we switched the compiler build to wasm_of_ocaml, added browser-specific build and initialization support, and optimized the compiler’s largest recursive and allocation-heavy paths—including list flattening, instruction generation, module linking, diagnostics, and Wasm encoding—to be stack-safe and memory- efficient, allowing substantially larger Neutron app sets to compile reliably in a standard browser without custom stack-size flags.

From here https://github.com/infu/neutron
(2) Dispenser canister hash has to match its repo source, that’s what creates your Neutron.
(3) Dispenser starter pack hash has to match repo files, it’s what gets installed initially.
(4) After the initial starter setup it’s up to the Motoko wasm inside the browser to compile the new canister version, you don’t compare hashes of apps and wasms, the system should be doing most of that.
(5) Lastly when hashes match and we are sure repo code is what ends up in new Neutrons - verify both code repositories do what they are supposed to do

14

Thanks for clarifying. Seems like this maybe increases verification burden. Could you explain what this system is about in terms of a problem statement? What’s the current problem and how is it solved by using this system?

Given that it does so much I’m struggling to understand which bits are core to the problem statement and which bits are sort of optional nice-to-haves

15

It’s actually not that hard, wrote the instructions here: https://github.com/infu/neutron/blob/main/doc/how_to_verify.md

This is the result:

1. **Browser Motoko compiler — PASS.** Two fresh builds of `neutron_motoko` commit `d7ed0a92b6219d784b7143e0851ed64b55dfc25a` matched byte-for-byte; the compiler Wasm is `6807a1f38a755497e2f5ef0e632359ea053597f8549f9be22074b5222bff543b`.

Neutron commit `32298b947c7723dc7f550373dd29ee0cea38b696` vendors those exact artifacts, and Kernel `v0.3.6` embeds the complete vendored compiler directory byte-for-byte.

2. **Dispenser — PASS.** Fresh `icp build -e ic dispenser` produced 983,848 raw Wasm bytes with SHA-256 `46032684e925b02c10aa92fea90cddf1ba0a374b3eaeadea066e36598dfa1f10`, exactly matching live canister `2o4cy-waaaa-aaaay-aacqq-cai`.

The live target-subnet query also matches production; this compares raw installed Wasm with raw build output, never gzip transport bytes.

3. **Starter pack — PASS.** All 12 pinned archives match their tracked size and SHA-256, and two uncached builds reproduced live deployment `6f7f333a53e9076185e63497a9743e9d` and gzip hash `a1bd30da35c5eade7774aab861b268ebd56a18a7cb9280e36add133acdd8044b`.

Live revision 1 has the expected app order, 2,255,438 Wasm bytes, and all 460 stored files match aggregate SHA-256 `e68c764e70d9e79521b9435beee9573ba15d141eba478c5f029cc5e1c5e3630f`.

4. **Post-starter compilation — PASS through the Dispenser boundary.** Package/source identities are content-hashed, the browser compiler builds the combined actor, and installation verifies the resulting module rather than standalone per-app Wasms.

The problems it addresses are a lot, it’s not a replacement workflow for every kind of app you build on the IC, it’s something new. It will make sense with time. There isn’t anything optional, except the apps - by design. It does help verification Neutron treats every ordinary app - including first-party apps - as untrusted, potentially adversarial code.

Apps receive explicit, finite, owner-approved authority scoped to their exact installation.
That is enforced through closed manifests, restricted Motoko source, generated app scopes, narrow capability handles, runtime broker checks, quotas, isolated browser frames, and private message ports.

In other words, we verify the kernel which limits and controls hundreds of apps, so they need a lot less verification if any. That’s good for AI too, when coding apps, it can’t get out and put slop all around the place or use things it’s not allowed to. To help you imagine it better, one app - even inside the same canister, can hold tokens in a ledger and even tho other apps share the same backend, they can’t touch these tokens. All the cryptography capabilities, certified assets, etc are app scoped as well. That’s to protect the Neutron owner, however to one Neutron another Neutron is potentially adversarial as well, since it’s fully controlled by the owner.

16

Okay. I’m only asking because I want to find a reason to use it, and I currently don’t quite get it. A problem statement, or sequence of problem statements would help a lot.

17

If it involves more work then verifying a canister’s build hash then it increases the verification burden. I’m not saying it makes verification too hard, I’m just mentioning that it sounds like there’s a non-zero cost on that front.

I’d appreciate getting an understanding of a scenario or set of scenarios that it makes easier rather than harder. Like concrete examples.

18

Well, it just moves things one step ahead; it’s not getting it all the way to a finished end-user product. It’s mostly up to the applications to convince a user whether it’s worth it for them or not. I imagine nothing will make me want to use a bare Linux kernel if it didn’t have the applications. The kernel is just doing supporting work. So yeah! making useful things is the next step.

19

I guess this is the problem statement/solution aspect then?

Can I ask how and in what ways the kernel limits/controls the apps? I guess if it constrains what the apps can do, there are some limitations in terms of what can be built?

At the moment the ICOS is sort of like the ‘kernel’, and canisters are the ‘apps’. What’s introduced by this extra kernel layer?

Again, I’m asking because I sense that this is useful and I want to be able to use it and understand its use cases

20

The capabilities are listed here https://ntron.net/docs/security/capabilities we will keep adding until all are covered.

Let’s say you want to do something like users deploying personal canisters. Without something like Neutron each of your apps will take one canister. For 15 apps, that will be around 300MB subnet memory for each + 1 for the controlling app, that’s 4.8 GB for a user. Then a subnet can fit 833 such users and its memory will be filled. If the app idle with 300mb (thats the minimum in Motoko) canister takes 2$/mo, a user needs to pay 32$/mo for his apps when idle. Then these would also do a bunch of cross-canister calls to sync, while in Neutron they are in one canister so they can call each other syncronously. So lots of cost savings 2$/mo vs 32$/mo and a subnet can fit ~14,000 Neutrons while it can only fit 833 with the above architecture.

Neutron is also doing a lot in the frontend layer, handling js, iframes, origins, identities, permissions, compilation, etc