B3Forge v2: Shareable Canister Interactions, New Playground & The Future of AI App Building!

[b3hr4d]

Hey everyone!

I’m excited to announce a major update to B3Forge! We’ve been listening closely to your feedback since our initial launch, and today we’re rolling out a new version packed with features designed to significantly improve the developer experience on the Internet Computer.

Powered by ic-reactor v3

B3Forge is a production showcase of ic-reactor v3.

We built this entire platform using the latest version of our library. From the dynamic Candid parsing and state management to the seamless Actor interactions, ic-reactor v3 does all the heavy lifting. If you are building a React frontend for the IC and want the same level of performance and developer experience, give it a try! B3Forge is proof of what you can build with it.

What’s New?

1. A Completely Redesigned Landing Page

We’ve updated our Landing Page to be your central hub for exploring the IC. It explores available canisters, curate popular tokens, and gets you to the method you need faster than ever.

2. Shareable Canister Interactions (The “Killer Feature”!)

This is by far our most requested feature. You can now share specific canister methods with pre-filled arguments simply by copying the URL.

Imagine needing to debug a specific call with a teammate or sending a pre-configured transaction form to a user. Instead of explaining “Go here, select this method, type this…”, you just send them a link.

Try it out live:

• Pre-filled Transfer Example

3. All-New Candid Playground Editor

We’ve completely revamped the Candid editor. It’s now faster, cleaner, and provides a much better experience for viewing and editing your .did files directly in the browser. It helps you visualize your canister’s interface more intuitively than before.

---

The Future of B3Forge

We are not stopping here. Our vision is to turn B3Forge into a complete App Builder for the Internet Computer. Here is a sneak peek at what we are building next:

AI App Builder

We are working on an AI orchestration layer that understands natural language. Soon, you will be able to simply tell B3Forge, “Build me a DAO voting app with token-weighted votes,” and it will discover the necessary canisters (Ledger, Governance, etc.) and generate a fully interactive UI for you.

• Concept: Candid is not just an interface description; it’s an application schema. We use AI to interpret this schema and build the app.

Visual Workflow Builder

Inspired by tools like n8n and Zapier, we are designing a Visual Workflow Builder. This will allow you to drag-and-drop canisters and connect them to create multi-step workflows.

On-Chain Verification & Monetization

We are exploring “Execution Receipts” to prove that a workflow was executed correctly on-chain. This opens up possibilities for:

• Audit Compliance: verifiable proof that a process was followed.
• Grant Systems: automated metrics for app usage.
• Monetization: developers earning rewards when their templates or workflows are used by the community.

---

Why B3Forge?

B3Forge aims to standardize and simplify how we interact with dApps. Whether you are building a complex DeFi protocol or a simple utility canister, having a consistent, auto-generated UI that you can tweak and share is a massive time-saver.

We would love for you to try it out and let us know what you think!

• Live App: forge.b3pay.net
• Original Announcement & Context: Read the thread here
• ic-reactor Library: Check it out on GitHub

Drop your feedback, feature requests, or bugs in the comments below!

Happy Coding!

[b3hr4d]

I also want to give a special shoutout to Austin @skilesare and Ethan @Gekctek for their valuable feedback on the previous version!

Your suggestions—especially regarding the need for better deep-linking and usability—directly influenced the new features in this release. Real user feedback is what drives B3Forge forward, so thank you for taking the time to test and share your thoughts.

Looking forward to hearing what you all think of the new update!

[b3hr4d]

Hi everyone,

As promised in my February update on B3Forge, we’ve started taking the first concrete steps toward the workflow builder inside B3Forge.

This is not released yet. It is the first step toward getting workflows ready for the beta release.

The current prototype extends B3Forge beyond shareable single canister interactions into visual multi-step workflows. Right now the focus is on getting the execution model and the shared contract right before beta.

Here is the current workflow UI in progress for an ICP transfer flow:

What this already shows directionally:

• chained canister calls
• flow and variables nodes
• explicit success transitions
• explicit error branching
• a graph UI that makes multi-step interactions easier to inspect and reason about

While building this into B3Forge, I realized it would be useful to get early feedback on the underlying standard as well, before freezing the wrong semantics.

So I’m sharing the direction I’m currently calling Candid-Expr.

The goal is to define a Candid-native way to express workflow inputs, typed references to prior results, and explicit workflow transitions without inventing a new wire format or a separate expression language runtime.

At a high level, the model is:

• authors write normal Candid value and argument text
• expressions can reference prior node outputs with $... references
• the resolved text is parsed and type-checked by Candid
• values and call results are encoded and decoded through DIDL with declared types
• workflow transitions are explicit rather than implied by node order

I’m trying to keep the proposal small and strict:

• Candid stays authoritative for value syntax and wire format
• references are typed, not JSON-style string lookups
• traversal is explicit for records, variants, vectors, tuples, and opt
• casts are explicit only
• failures are deterministic and machine-readable so tools can branch on error codes instead of parsing messages

The current proposal has two node types:

• CanisterCall
• Variables

And a small shared workflow contract centered on:

• entry_node_id
• next_on_ok
• next_on_result_err
• an optional human-readable label for tracing and cross-tool readability

The important runtime distinction is:

• a top-level canister Result Err is still a typed return payload and may branch via next_on_result_err
• call-level failures such as reject, timeout, trap, decode failure, or type failure hard-stop execution

One opinionated part of the proposal is the runtime reference model. Each executed node exposes a single canonical return namespace:

ret

So these are equivalent:

$N3.ret.Ok
$N3.Ok

You can think of ret as the default return namespace for a node. In the common case it does not need to be written explicitly, which keeps expressions short while still leaving room for the standard to grow later if additional namespaces are ever needed.

Another opinionated part is explicit traversal semantics:

• records by field
• variants by active arm
• tuples or multi-return values by numeric index
• opt only through explicit .some

For example:

$transfer.Err.InsufficientFunds.balance
$profile.some.owner
$node.1
$amount : nat64

The workflow shape is roughly:

type CanisterCallConfig = record {
  canister_id : principal;
  method_name : text;
  arg_expr : text;
  method_candid : text;
  next_on_result_err : opt text;
};

type VariablesConfig = record {
  value_expr : text;
  value_type : text;
};

type DynamicCallNode = record {
  id : text;
  label : opt text;
  next_on_ok : opt text;
  config : variant {
    CanisterCall : CanisterCallConfig;
    Variables : VariablesConfig;
  };
};

type DynamicWorkflow = record {
  entry_node_id : text;
  nodes : vec DynamicCallNode;
};

What I am not trying to do:

• replace Candid
• invent a general-purpose programming language
• add implicit coercion rules
• mix editor layout or other app-only metadata into the shared workflow schema

What I am trying to do:

• make workflow expressions portable
• keep execution semantics aligned across environments
• make failures deterministic enough for tooling
• define a shared contract that multiple runtimes and editors could implement

I’d love feedback on both the B3Forge workflow direction and the standardization boundary behind it.

The main questions I’d especially like opinions on:

1. Does ret as the default return namespace feel like the right tradeoff, or does it make the expression model less clear for Candid users?
2. Is rootless shorthand like $N3.Ok a good ergonomic improvement, or does it hide too much?
3. Does separating typed Result Err branching from hard-stop call failures seem like the right execution model?
4. Is Variables worth standardizing as a first-class node, or should the standard stay narrower and focus only on inter-canister calls plus references?
5. Are explicit-only casts and explicit .some traversal the right strictness level, or do you think this becomes too annoying in real workflows?
6. Should an optional label be part of the shared contract as portable human-readable metadata for tracing, logs, and cross-tool readability, or should it stay outside the standard?
7. Does the workflow contract feel minimal enough to be shared across browser tooling, local runners, and canister runtimes?
8. What kinds of multi-step canister flows would you most want to build with something like this?
9. Are there compatibility, security, or usability pitfalls you’d worry about if tools start relying on this expression format?

This is still early, but I’d rather get the semantics challenged now than carry the wrong model into beta.

If useful, I can also share more of the draft spec around:

• workflow expression grammar
• transition semantics
• deterministic error codes
• shared interface contract

Thanks in advance. Blunt feedback is welcome.

[rem.codes]

Oh awesome, its looking really nice!

I was trying to build something similar for toolkit as a kind of POC where you could build canister call flows via drag and drop nodes where you could take responses from calls and use it as arguments for other connected nodes.

Is this something you are also planning to do? if so i might have some code you could use

[b3hr4d]

Yes, that’s exactly the direction I’m working toward.

The underlying parsing and execution pieces are already implemented and tested on both the backend and frontend, including typed node-to-node output binding and execution. What I’m working on now is turning that into a solid visual workflow builder inside B3Forge.

If you’re open to sharing your Toolkit POC, I’d genuinely love to take a look. It would be great to compare approaches, especially around graph UX and flow composition.

[rem.codes]

If you DM me your github i can add you to the repo

[b3hr4d]

Quick update: the workflow/AI direction I mentioned in this thread is now available as a beta.

I opened a new thread here so feedback can stay focused on the Workflow Beta:

B3Forge Flow Studio Beta: Generate, Run, Share, and Fork ICP Workflows with AI

Hey everyone, A few months ago I shared the B3Forge v2 update, where I mentioned that we were exploring AI app building and visual workflows for ICP canisters. Today I’m excited to share the next step: the B3Forge Flow Studio Beta is ready to try. [Screenshot 2026-05-01 at 20.37.08] B3Forge now lets you build multi-step ICP workflows visually, using Candid-native canister calls and typed values end-to-end. Instead of opening one canister method at a time, you can now connect steps together,…

You can now prompt AI to generate ICP workflows, run them in the browser, and share/fork workflows from the community area.

Would love for people to try the AI workflow generator and share prompts, published workflows, bugs, or feature requests.

[Charlie-James]

Nice, that sounds pretty cool.