DEV Community: Methodox Technologies, Inc.

DevLog 20260319: Metaprogramming (Teaser)

Charles Zhang — Thu, 19 Mar 2026 20:16:19 +0000

Quick Comment

Following Document-Level Main Module, the possibility really opens up...

This is very different from our earlier hard-coded "Stats" node.

DevLog 20260319: Towards OOP - Document-Level Default Module and Module-Level Members and Behaviors

Charles Zhang — Thu, 19 Mar 2026 20:16:08 +0000

Revisiting Flappy Bird – The Pain Point

Remember our Flappy Bird example from mid-2025?

The long chain of variable initializations was needed for two main reasons:

No way to declare variables before using them
More critically - no way to define custom data structures that could group related values together and be instantiated with a single node.

In retrospective it seems obvious: we just need proper structured data containers. But building the scaffolding to support this properly in a visual, node-based system is a bit more involved.

Searching for a Solution

I spent a long time trying to bring OOP concepts into Divooka. A huge amount of effort went into DiOS (Divooka Open Standards), with the hope that a complete standard would naturally solve these kinds of problems. But standardization work is slow and deep - just like making Divooka itself feature-complete.

Then, while working on something completely unrelated and taking a short break from this topic, it suddenly clicked.

The key insight: start simple and approach it from a functional/declarative angle first, before jumping into inheritance, encapsulation, polymorphism, and all those good stuff.

I'm really excited - we finally have meaningful progress.

The Divooka Way

To claim our goal as "everything is a node" is a bit too strong, but I strongly prefer keeping almost everything on the graph.

This aligns with how we already handle structured primitives - direct value setting of compound inputs. That way, there's still hope that users can drop down to raw node programming when they need full control (and thus keep everything programmable).

Traditional property panels (like Unreal Blueprints' object definition GUIs) are out - they break the pure graph paradigm.

Instead, the solution is declarative, similar to how TerraGen works: the mere presence and connection of certain nodes defines meaning.

This feels awesome for several reasons:

We can make full use of the 2D graph layout - place things exactly where we want them visually
It stays completely coherent with Divooka's graphical paradigm
No need for separate "class editor" UIs

What's Been Implemented So Far

Current working pieces:

Graphs can now act as modules
Support for module-level data members and behavior members
A main module tied to the document, with existing graphs serving as associated behaviors

Module-scoped instance node – in Events context

Module-scoped instance node – in Dataflow context

Top-level module behavior graphs

This immediately unlocks:

Clean access to (top-level) module instances
Shared event and dataflow instance data
A unified programming and document model for subgraphs (still a work-in-progress)
In procedural contexts (Glaze! especially): we now have proper data containers - no more awkward giant variable lists or forced tuples! (Compare to the old Flappy Bird screenshot)
Much simpler and more natural state storage/access in Glaze! and procedural graphs

This is a big deal - for a system that's gearing up for real production use, it feels like crossing a major milestone in usefulness and core abstractions.

Current Limitations & Remaining Work

Still plenty to fix/polish:

A bunch of bugs and edge cases
Proper serialization support
Smooth context switching between graphs
Subgraph consolidation / better nesting UX

Looking Ahead

This is a solid foundation, but there's still a long road:

Full modularization support
Modules inside modules (nesting)
Module inheritance / composition patterns / polymorphism
Base DOM exposed as the "main module" for metaprogramming API
Detailed documentation: how it all fits together, recommended usage patterns, expected behaviors, pitfalls
Module-level scoped instances (deeper/finer control)

Overall - I am very happy with the direction. It feels like Divooka is finally getting the abstraction power it deserves while staying true to its visual, graph-first philosophy.

I am hyped for what we will achieve.

References

A Detective Story: The Case of The Dead Office Guy (Upcoming Game Release)

Charles Zhang — Fri, 06 Mar 2026 19:29:11 +0000

Overview

In the quiet town of Baytown, an unremarkable man lies dead under suspicious circumstances. Rumors ripple through the streets. Secrets long buried begin to surface. The whole community is buzzing - some in dread, others gripped by dark fascination.

A Detective Story is a compact detective simulator that brings generative AI to the heart of interactive fiction.

Step into the role of detective in this small-scale murder investigation. Interrogate a cast of AI-powered townsfolk, each with their own motives, fragmented memories, and the potential to lie or mislead. Explore the map to uncover physical evidence and hidden clues. Piece it all together before time runs out.

Game Guide

Your mission: Solve the murder as efficiently as possible - minimize days elapsed and questions spent.
Bringing suspects to the station costs valuable time (days). Choose your interviews with care.
These are informal interrogations - no formal oaths, no truth serum. Witnesses and suspects may deceive, omit, or hide the truth.
You have only 3 questions per interview. Make every one count.
Stay in character for maximum immersion: Ask about alibis, relationships, timelines, strange sightings, and contradictions.
Cross-check stories, hunt inconsistencies, and link conversations to evidence found on the map.

Hardware Requirements

A Detective Story is lightweight and runs smoothly on modest hardware. It requires at least 10 GB of system RAM (DRAM) - with no heavy VRAM demands.

DevLog 20260225: Divooka Visual Programming - Direct Value Setting of Compound Inputs

Charles Zhang — Wed, 25 Feb 2026 17:46:45 +0000

Finally, it arrived! Well, not exactly here yet, but getting closer.

Overview

Divooka intends to make visual programming simple and accessible - the accessible part is achieved both through wide availability and the general-purpose nature of the programming system, but the simple part is what we spend lots of effort thinking hard trying to improve.

In the past, dealing with complex configuration takes the form of either "explosion" of arguments or dedicated Make XXX construction functions:

The problem arises due to the direct exposure of all input arguments in visual programming. Both approach makes the canvas look busy, with the former a common approach in existing systems - using a struct sounds good on paper but still requires a complex looking construction node. This is a common problem in visual programming systems, below shows how it's done in Blender and ComfyUI.

You do get used to it after a while, but a busy looking canvas remains a busy-looking canvas. In Blender, you can sort of "collapse" a node:

As Blender is constantly improving, we can also now collapse property groups as shown in the earlier screenshot.

As a syntax purist and (unfortunately) very conscious about my working space, my eyes can't tolerate messiness. I kind of like how Houdini approaches this.

Essentially they offload all the complexity to the properties panel - this has the huge benefit of making everything look very clean. But the downside is Houdini rely heavily on scripting expressions (like Excel).

TerraGen and World Machine mixes the approach:

In both cases, connections represent flow of terrain data only and additional configurations are offloaded to property panels. In TerraGen especially, this allows those properties to be animated. The downside, once again, is whatever is offloaded to property panels are no longer programmable using nodes.

Our Approach

Our proposed solution for Divooka looks like this: fundamentally all properties remain as node inputs, but compound values (especially value types) should just allow "editing in place" through a property panel. If more complex programming is needed, one can easily fall back to Make XXX nodes again.

Future Work

There is still remaining work on type check, hierarchical compound types, arrays, and serialization, and also node rendering.

Conclusion

As usual with all the exciting language features of Divooka we intend to introduce, there are lots of details to take care of here.

DevLog 20260224 Divooka - Node-Level Automatic Dispatch (Runtime Execution Behavior)

Charles Zhang — Tue, 24 Feb 2026 22:20:52 +0000

Overview

Anything useful done with a program eventually involves file I/O and some form of repetition.

In Divooka, the dataflow context already makes it very easy to "just get a single thing done." That part feels good. But handling loops? That's where things start to get awkward.

One challenge lies on the GUI side — especially around lambdas and subgraphs. We do have foundational support (as shown here and here), but let's be honest: it's not smooth yet.

So the question becomes: how do we make repetition feel natural without introducing heavy conceptual overhead?

The Plan

There are several well-established ways to achieve looping behavior in a functional or visual programming context:

Subgraph context - Used in tools like Blender, vvvv, and Houdini. A specialized node group or frame defines loop entry and exit boundaries.
Lambda callbacks - Evaluation is handled via callback-style execution.
Expressive recursion - As seen in text-based functional languages, requiring explicit termination conditions to avoid stack overflow.

All of these approaches are powerful and necessary in certain contexts. But they also introduce additional constructs into the language model. For advanced workflows, that's fine. For simple operations, it can feel unnecessarily complex.

I wanted something lighter.

Array Coercion

Divooka already supports Array Coercion — a scalar value can be passed into an input expecting a collection.

This avoids the need to manually "wrap" a scalar into an array just to satisfy a function signature - I still remember the pain of handling arrays in Unreal Blueprint.

Scalar-to-array coercion keeps graphs clean and avoids clustering.

To take this to the next level, I've been giving it much thought on how the reverse might work: if we can coerce scalars into arrays — what if we also let nodes automatically dispatch when arrays are passed in?

Automatic Dispatch (Node-Level)

The core design question was:

Should an array input implicitly turn the entire downstream chain into a loop?
Or should the dispatch behavior stay localized to the node itself?

Eventually it seemed localizing things to the node made far more sense.

For example:

string String.Replace(string, string, string)

If any input is provided as an array instead of a scalar, the node automatically promotes itself to:

string[] String.Replace(string[], string[], string[])

The node executes element-wise.

Now, I can rename a folder of files with roughly three nodes:

Enumerate files
Regex replace
Rename file

No explicit loop node. No subgraph. No lambdas.

In this example, Duplicate as Array returns a strongly typed string[], enabled by generics support.

One important rule: All array inputs must align in size with the source array. The dispatch is index-based and deterministic.

Full Example

What used to require explicit iteration logic now becomes implicit behavior at the node boundary. The graph remains readable. The mental model stays simple.

Conclusion

This is still early work. Integration with the rest of Divooka's features is ongoing, and edge cases are being worked through.

So far so good.

Weekly Update 2026-01-11

Charles Zhang — Mon, 12 Jan 2026 01:29:00 +0000

This week was mostly about tightening up the foundations of our tools rather than pushing new features. A lot of our older experiments were starting to show their age, so we spent time cleaning things up and getting the core systems into better shape.

What Happened This Week

Refactoring Neo + Parcel NExT review

We continued working through refactors on Neo and reviewing the Parcel NExT implementation. Some of the earlier experimental frontend work had spread across multiple assemblies, so small API changes ripple everywhere. Slow, but necessary.

WPF + Nodify wrestling

A surprising amount of time went into understanding how WPF resource dictionaries, theming, and Nodify's API actually want to behave together. After digging through the quirks, we finally have a clearer picture of how to keep styling and view models consistent. Didn't get as far into custom styling as we hoped, but at least the fundamentals are sorted out.

Serialization groundwork

Started wiring up the basics for text-based JSON serialization of Divooka graphs/documents. Also began work on package reference records and figuring out how packages get identified and loaded at runtime. All early steps, but important ones.

Graph editor + GUI cleanup

Made some initial passes at reorganizing the graph editor. Small changes now, but they'll help us build better tools on top later.

Fantasy Planet Painter update

Spent a little time polishing and updating the Steam submission for Fantasy Planet Painter.

Methodox Threads

We also pushed out an early public release of Methodox Threads, our lightweight branching text environment for managing non-linear AI conversations. The new v0.7 build adds integrated Gen-AI generation directly inside each document pane, configurable providers, and a simple JSON-backed structure for exporting or versioning thought trees. It's essentially a cleaner way to explore tangents, run parallel prompts, and keep complex LLM work organized. Download is available on itch.io.

Closing Thoughts

Not a "big features" week, but a surprisingly productive one in terms of future stability. Refactors aren't glamorous, but they make everything that comes next a lot smoother.

Release Note: Methodox Threads (v0.7)

Charles Zhang — Mon, 12 Jan 2026 01:14:34 +0000

Overview

Version 0.7 introduces full Gen-AI generation capabilities, including per-document prompt-driven content generation, provider configuration, OpenAI integration, and asynchronous multi-editor execution with UI-level busy indicators. This release establishes the foundation for a extendable, multi-provider LLM workflow while maintaining the existing document layout and editing model.

New Features in v0.7

Configurable AI Provider Framework

A new Configure… dialog provides a unified interface for system-level and provider-specific settings:

System Tab

Edit the global System Prompt used for all generations.

OpenAI Tab

API key (masked)
Optional custom endpoint
Preset model list:
- gpt-4o-mini
- gpt-4o
- o3-mini
- Other → reveals a custom model name field
Support for model overrides when presets become outdated
Automatic load/save of configuration in a user-specific app directory

Additional provider tabs (Gemini, DeepSeek, Ollama, Grok) are included as placeholders for future integrations.

Gen-AI Generation Workflow

Each document now supports prompt-based content generation:

Users set a Prompt on any document.
Selecting Edit → Generate triggers generation for the focused document.
Generation uses:
- Global System Prompt
- Document Prompt

Per-Editor Async Generation

Each document editor generates independently in parallel.
Editors become temporarily read-only during generation.
A semi-transparent overlay displays Generating… with an indeterminate progress bar.
Sibling/Child creation buttons remain active.
Generated text is written directly into the document’s Content field.

OpenAI Integration (First Provider Implementation)

A new abstraction layer encapsulates provider calls.
Version 0.7 includes the first concrete backend:

OpenAI Chat Completion Backend

Uses the official OpenAI SDK.
Supports both default and custom endpoints.
Converts internal document structures into Chat API messages.
Returns full assistant text as document content.

This abstraction enables drop-in integration of additional providers in future versions.

Configuration Persistence

All provider and system settings are automatically stored as JSON in the user-local app directory:

Loaded when opening the Configure dialog
Saved on dialog close
Ensures persistent environment across editor sessions

Limitations

No document deletion or rearrangement
Markdown preview remains basic
Only OpenAI is implemented; other providers are placeholders
Generation does not yet stream partial output

References

Introducing Methodox Threads: Tame the Chaos of Branching AI Conversations

Charles Zhang — Mon, 12 Jan 2026 01:13:12 +0000

Tired of losing brilliant tangents in endless LLM chats?
Frustrated when editing a prompt wipes out your entire history, or when long threads become impossible to navigate?

You're not alone. Every generative AI user - from casual brainstormers to researchers, writers, and prompt engineers - hits the same wall:

Linear chat interfaces simply weren't built for nonlinear thinking.

That's why we built Methodox Threads.

Threads is a linear-yet-branching text environment crafted for managing complex ideas and AI conversations - especially those that naturally fork into tangents, nested explorations, and parallel paths.

And with the new v0.7 release, Threads becomes more than an organizational tool. It a generative workspace for chat management.

Core Experience at a Glance

Multi-pane, tree-like layout Each document lives in its own dedicated, scrollable editor. The whole structure remains visible, so you can see the big picture while diving deep into any branch.
Natural branching From any node, spawn siblings (parallel directions) or children (deeper explorations). Build clear, persistent hierarchies without losing context.
Integrated Gen-AI generation (new in v0.7!) Add a Prompt to any document and generate AI-assisted content directly into that pane. Includes:
- Per-document generation
- Parallel, asynchronous execution
- Read-only “Generating…” overlay during output
- Global system prompt
- Configurable AI providers (OpenAI available now; Gemini, DeepSeek, Ollama, Grok coming soon)
- Custom API endpoints and custom model names
- Secure, auto-saved per-user configuration Your entire AI workflow now runs inside the branching editor itself.
Iteration-friendly writing environment Full Markdown editing, inline notes, JSON/Markdown export, and a distraction-free dark UI. Refine AI outputs, rewrite prompts, annotate ideas - without ever resetting a thread.
Portable & future-proof A clean JSON structure under the hood, with markdown Gen-AI folder import/export support for v0.6+ projects. Version-control your thought trees with ease.

Threads lets you shape AI conversations the way your mind naturally works: branching, revisiting, exploring alternatives, and layering insights - all without friction.
Picture exploring what-ifs in a worldbuilding document, generating multiple stylistic takes side-by-side, or running parallel reasoning chains for research - all visible at once, never buried in scrollback.

For a deeper dive into the design motivations and architecture, check out our dev log “Motivations for Methodox Threads”.

Get Started

Threads is available now as an early public release from Methodox Technologies.
Download it today and start turning chaotic AI interactions into structured, generative thought trees.

→ https://methodox.itch.io/threads
→ Follow @methodox for updates, tips, and early access to upcoming provider integrations, streaming AI output, and full multi-model workflows.

Introducing Methodox Threads: Tame the Chaos of Branching AI Conversations

Charles Zhang — Mon, 12 Jan 2026 01:13:12 +0000

Tired of losing brilliant tangents in endless LLM chats?
Frustrated when editing a prompt wipes out your entire history, or when long threads become impossible to navigate?

You're not alone. Every generative AI user - from casual brainstormers to researchers, writers, and prompt engineers - hits the same wall:

Linear chat interfaces simply weren't built for nonlinear thinking.

That's why we built Methodox Threads.

And with the new v0.7 release, Threads becomes more than an organizational tool. It a generative workspace for chat management.

Core Experience at a Glance

Multi-pane, tree-like layout Each document lives in its own dedicated, scrollable editor. The whole structure remains visible, so you can see the big picture while diving deep into any branch.
Natural branching From any node, spawn siblings (parallel directions) or children (deeper explorations). Build clear, persistent hierarchies without losing context.
Integrated Gen-AI generation (new in v0.7!) Add a Prompt to any document and generate AI-assisted content directly into that pane. Includes:
- Per-document generation
- Parallel, asynchronous execution
- Read-only “Generating…” overlay during output
- Global system prompt
- Configurable AI providers (OpenAI available now; Gemini, DeepSeek, Ollama, Grok coming soon)
- Custom API endpoints and custom model names
- Secure, auto-saved per-user configuration Your entire AI workflow now runs inside the branching editor itself.
Iteration-friendly writing environment Full Markdown editing, inline notes, JSON/Markdown export, and a distraction-free dark UI. Refine AI outputs, rewrite prompts, annotate ideas - without ever resetting a thread.
Portable & future-proof A clean JSON structure under the hood, with markdown Gen-AI folder import/export support for v0.6+ projects. Version-control your thought trees with ease.

For a deeper dive into the design motivations and architecture, check out our dev log “Motivations for Methodox Threads”.

Get Started

Threads is available now as an early public release from Methodox Technologies.
Download it today and start turning chaotic AI interactions into structured, generative thought trees.

→ https://methodox.itch.io/threads
→ Follow @methodox for updates, tips, and early access to upcoming provider integrations, streaming AI output, and full multi-model workflows.

DevLog 20260110: Motivations for Methodox Threads - A Conversation Management Tool

Charles Zhang — Sat, 10 Jan 2026 20:02:39 +0000

Hey folks, Charles here from Methodox. As a developer deeply embedded in the generative AI space, I've spent the last couple of years wrestling with the limitations of LLM interfaces. Today, I want to dive into the motivations behind our latest project, Methodox Threads - a linear, branching text environment built to tame the chaos of long, tangled conversations. This isn't just another note-taking app; it's a structured canvas designed for iterative thinking, especially when collaborating with AI models. I'll keep this log developer-focused, touching on the architecture and implementation choices, while highlighting why this solves a universal pain point for anyone using gen AI tools.

The Problem: Chaos in Conversation Management

If you've ever dived deep into a conversation with an LLM like Grok, ChatGPT, or Gemini, you know the drill: things start linear, but soon you're branching into tangents, exploring "what-ifs," and iterating on ideas. The trouble? Existing interfaces suck at handling this complexity.

OpenAI's ChatGPT: They pioneered branching, which is a step up, but in long threads, navigation becomes a nightmare. Scrolling through endless history to find that one pivotal response? Forget it - context gets buried, and resuming a branch feels like archaeology.
Grok (xAI): The side navigation pane is a nice idea on paper, but in practice, it falls flat for multi-branching. Creating parallel explorations requires awkward workarounds, and the UI doesn't scale for deep hierarchies.
Gemini (Google): Editing a prompt erases the previous version entirely - no versioning, no undo. It's like the tool assumes your first draft is always perfect, which is laughable for creative or analytical work.

Worse still, none of these platforms let you edit the AI's responses natively. For developers doing prompt engineering or users in creative writing, this is a deal-breaker. You spot an inconsistency or want to tweak for better flow? You're stuck regenerating from scratch, praying the model stays consistent (spoiler: it often doesn't). OpenAI's Canvas tries to address iterative editing, but it's hampered by the underlying AI's memory lapses and lack of true state management.

This isn't just a dev gripe - it's a widespread issue. Casual users brainstorming ideas, researchers tracking hypotheses, or writers building narratives all hit the same wall: conversations sprawl, branches get lost, and productivity tanks. In a world where gen AI is democratizing creativity, we need tools that empower structured exploration without the friction.

My Journey: From Hacks to a Dedicated Tool

I've been hacking at this problem since the early days of gen AI. Inspired by tools like Kobold AI (which excels at local, scriptable story generation), I started building lightweight local management systems. Early prototypes used simple folder structures to mimic threads - each "branch" as a subfolder with text files for prompts and responses. Others adopted custom JSON formats for serialization, allowing easy versioning via Git.

These worked okay for personal use but lacked visual intuition. Exporting/importing conversations was manual, and scaling to nested tangents felt clunky. That's how I conceived Methodox Threads: born from my startup's focus on AI-enhanced workflows, it's a purpose-built app that evolves these ideas into a robust, user-friendly system.

From a dev perspective, Threads is architected around a tree-like data model (think hierarchical nodes in a graph database, but lightweight and in-memory for speed). Each node represents a thread segment:

Core Structure: A root document spawns children (nested explorations) and siblings (parallel branches). This is implemented with a recursive node class in our backend (built on Avalonia for cross-platform desktop use), easily exportable to JSON format.
UI Layout: Multi-pane editors, each fully scrollable and synchronized. We use a canvas-based layout with customizable pane width and height and automatic height adjustments for children documents - useful when dealing with deep hierarchies of varying complexities.
Features for Iteration:
- Markdown support via a lightweight parser (no rendered preview at this moment, but syntax highlighting is a work in progress).
- Document-wise notes and project README for meta-commentary (e.g., "This branch assumes v2 prompt").
- Project serialization to JSON or export to Markdown in folders, making it Git-friendly for version control.
Distraction-Free Design: No bloat - just a clean canvas. You can create branches either from the menu or through the hover buttons; In the future we may provide keyboard shortcuts for branching (e.g., Ctrl+B for new sibling) and drag-and-drop reorganization, drawing from IDEs like VS Code.

The goal is to enable deep dives without losing the forest for the threads. For general users, this means organizing a chatbot session on "world-building for a sci-fi novel" into branches like "Character Arcs," "Plot Twists," and "World Lore" - all visible at a glance. For devs, it's a playground for prompt chaining, where you can fork a thread to test API variations without derailing the main flow.

Why Build This?

At its core, Threads addresses the cognitive load of unstructured AI interactions. Gen AI users - whether hobbyists or pros - crave persistence and flexibility. Developers like us need it for debugging prompts, prototyping agents, or managing multi-model experiments (e.g., comparing Grok vs. GPT outputs side-by-side). The general public benefits from a tool that makes AI feel less like a black box and more like a collaborative partner, especially in fields like research, writing, or ideation.

We're charging a very small courtesy cost to support the continued development of this tool, since developing such an interface is easy for anyone with GUI dev experience - but continuously improving it is what makes it truly usable.

Future Plans: From Manual to Seamless AI Integration

Right now, Threads is a powerhouse multi-pane text editor, but populating it requires manual copy-pasting from your LLM of choice. That's fine for bootstrapping, but we're gearing up for true integration.

API Endpoints First: We'll start with the OpenAI API, allowing users to "continue" a thread by sending the full branch context plus a system prompt. Imagine right-clicking a node and selecting "Query GPT" - it appends the response as a child node, preserving history.
Prompt Engineering Tools: Built-in templating for system prompts.
Multi-Model Support: Expand to Grok, Gemini, and local models via Ollama. Devs can plug in custom endpoints.
Version Control Friendly Exports: Exporting to scattered Markdown files is very useful since internally many older conversations were archived this way and it looks nicer on Git diff than JSON.
AI-Assisted Structuring: Use lightweight ML to suggest branches or summarize threads (like how Grok works).

We're iterating fast so file formats and exact usage pattern may change, and will spend more time on this if receive plenty user interest. If you're a dev interested in sharing ideas or a user with feedback, hit us up at Methodox (contact@methodox.io). Stay tuned for more updates!

Let's make AI conversations manageable for everyone.

References

DevLog 20251216: Supporting Multiline Input in Pure

Charles Zhang — Tue, 16 Dec 2025 14:31:14 +0000

Make things much easier.

Currently you cannot go back, so it's pretty preliminary.

DevLog 20250927: Use Fossil for Binary Asset VCS

Charles Zhang — Fri, 17 Oct 2025 14:44:35 +0000

It's clean and elegant.

Overview

As discussed in a previous post about binary file version control, keeping binaries well-versioned has always been challenging.

Years ago, when I first discovered SQLite, I also found Fossil. At that time, it didn't meet my needs - Git proved far better for collaboration and text-based workflows (especially with GitHub and GitHub Desktop).

However, Fossil may perform better for binary files under ~2GB, provided some manual bookkeeping and syncing.

Beyond versioning, Fossil offers several useful built-in tools:

Chatroom: Configurable 7-day ephemeral chat for authorized users. Supports HTTP API.
Wiki
Embedded Documentation
Tech Notes
Web UI Server
Direct file views: HEX, Text, Download
Forum: Permanent records; CDN support for images
Bug Tracking / Tickets / Issues
Full-text search

Framework

This framework describes how I'm beginning to use Fossil alongside Git for version control.

Using Fossil + Git

The plan is simple: Use git for text files; fossil for binary assets.

# Create repo
cd "<Repo Folder>"
fossil init ../MyRepo.fossil    # The convention is to create fossil repository outside the repo folder
fossil open -k ../MyRepo.fossil # Creates the _FOSSIL_ tracking file; -k skips checkout

# Create fossil-settings (See commit message below)
mkdir -p .fossil-settings
printf ".git\n.git/*\n.gitignore\n" > .fossil-settings/ignore-glob
fossil add .fossil-settings
fossil commit -m "Add Fossil ignore rules for Git files"

# Manually ignore files already tracked by Git, then commit again if needed
# fossil changes
# fossil commit -m "Update ignore file"

# In Git (e.g. via GitHub Desktop), ignore Fossil's contents, especially:
# *.fossil
# _FOSSIL_

# Treat all files as binary
printf "*" > .fossil-settings/binary-glob
fossil add .fossil-settings/binary-glob
fossil commit -m "Treat all files as binary in Fossil"

# Inspect
# fossil changes
# fossil extras

fossil add .
fossil commit -m "Initial Fossil import alongside Git"

This setup cannot keep Fossil and Git perfectly synchronized. Manual bookkeeping is necessary to restore past states accurately.

Summary

Key conventions:

Keep the .fossil file outside the Git repo folder.
.fossil-settings/binary-glob: mark all files as binary.
.fossil-settings/ignore-glob: define ignore patterns.
_FOSSIL_ and .fossil-settings can be deleted safely.

Quick Reference

Common commands:

fossil init <Repo> [--project-name <Name>] - create repo; edit name later in UI if omitted
fossil add . - add all
fossil add <File> - add file
fossil rm <File> - remove file
fossil commit -m <Message> - commit all local changes
fossil commit file1.c file2.h -m <Message> - commit specific files
fossil open --keep <DB> - open repo without checkout
fossil open --force <DB> - open repo, overwrite with latest
fossil status or fossil info - show repo info
fossil changes - list modified tracked files
fossil extras - list untracked files
fossil diff - show content changes
fossil timeline - history view
fossil ui [<Repo>] - launch web UI
fossil server [<Repo>] - start web server for push/pull

The typical git status is achieved with fossil changes + fossil extras.

Recipes

Ignore Blender versioning files

Use this pattern:

*.blend[0-9]*

Importing Git Repos

Not required here, but reference: https://fossil-scm.org/home/doc/trunk/www/inout.wiki

Stashing and Committing Specific Files

Fossil lacks Git's staging (git add -p) feature. The checkout directory is treated as one working tree snapshot. Still, you can commit selectively.

Commit specific files

You can pass the filenames explicitly to fossil commit:

fossil commit file1.c file2.h

This will commit only the listed files, even if you changed other files in the checkout. The other modified files will stay uncommitted.

Use stash to isolate changes

If you want to set aside changes temporarily:

Stash away all changes: fossil stash
Reapply only the files you want: fossil stash pop file1.c file2.h
Commit those files: fossil commit file1.c file2.h
Optionally reapply remaining changes: fossil stash pop

Revert unwanted files

If you've edited several files but only want to commit some:

fossil revert fileX.c fileY.c

This discards edits to those files, leaving only the desired ones for commit. Use stash first if you want to preserve them.

References

Learn Fossil quickly:

Quickstart Guide