graphing work is taking slightly longer than we initially expected, but the microcontroller is here
work on the demo will begin as soon as we get universal-weave 0.5.0 published
The microcontroller for the demo is nearly here.
Work on the demo will start as soon as the microcontroller arrives; Right now, we're working on getting our graphing implementation to meet our high standards.
Simple explanation for the community:
It means the system that takes all the branches inside a Loom and automatically arranges them into a visual map that users can actually see and navigate.
@transkatgirl now has a working draft with reasonably good performance. The next step is testing its reliability and fixing edge cases before including it in the next @universalweave release.
So the project has moved from:
“Can this graphing layer work?”
to:
“Is it reliable enough to ship?”
This matters because future Loom builders would not need to find a separate graphing library or build one from scratch. @universalweave could provide both the branching structure and the foundation needed to display it.
Still WIP, but another difficult layer is taking shape in public.
$weave
A quick update on the graphing work: We now have a draft implementation with reasonably good performance, and now we're working towards ensuring it's reliable enough to include in the library's next update.
We've finally completed our work on the core Loom algorithms, and now we're moving on to the next most important component of a Loom interface: Graphing!
Existing graphing libraries don't work well for Looms, as they tend to be too slow, heavy, or opinionated to be usable for the user interface.
So, we're building our own, integrated into universal-weave, and we aim to hold the graphing code to the same standards as the core Loom algorithms: High reliability, intuitive behavior, good performance characteristics, and the ability to run anywhere.
5 new commits just landed in @universalweave src.
@transkatgirl has started implementing the DAG coordinate assignment system.
Simple version: once a Loom has many paths splitting, crossing and merging, the app needs to decide where every node should sit, how far apart the branches should be, and how each connection should travel without turning the screen into a mess.
That’s what this code is starting to solve.
The update adds graph ranking, 2D node placement, spacing, polyline routing for connections, and viewport-aware loading so apps can focus only on what is currently visible.
This is the machinery that turns a raw graph into an actual map people can navigate.
Around 1,550 lines were added across these 5 commits. It’s still WIP, so graphing is not finished yet.
But the hard parts are taking shape in public, commit by commit.
Keep an eye on the repo.
$weave
Sharing this with @transkatgirl permission.
Some people have asked whether $weave is only a community token or if it could eventually have real utility.
Let me explain again. Right now, $weave is not required to use @universalweave. And honestly, it shouldn’t be.
@universalweave is a public-domain library. The core should remain free and easy for any developer to use. Forcing a token into the library would only make adoption harder.
But @transkatgirl told us that she is open to possibly building services that use $weave in the future.
Please read that carefully.
This is a possibility, not a certainty.
Nothing has been planned yet, there is no ETA, and this is something she would probably explore during the final phase of @universalweave development.
That timeline depends on many factors, including @transkatgirl physical and mental health. So please don’t pressure her or treat this as a promise.
If token utility ever happens, the most logical place would be through optional services built around @universalweave.
For example, hosted inference, cloud storage, cross-device sync, real-time collaboration, large Weave hosting, or a marketplace for Loom plugins and templates.
Those are examples from my side. They are not confirmed services or announcements from @transkatgirl.
For now, $weave is still primarily a community funding layer. Creator fees help Kat continue building, test better models, get hardware, and fund further development.
What makes this bullish to me is not “utility confirmed.”
It’s the order in which everything is happening.
Most projects invent token utility first and then hope someone eventually builds something behind it.
Here, the builder, the code, and the actual tech already exist.
Any token utility would come later, only if it genuinely fits what @transkatgirl is building.
That’s exactly how I want $weave to grow.
Just a real builder, and an honest possibility of something much bigger later.
The microcontroller for the demo is nearly here.
Work on the demo will start as soon as the microcontroller arrives; Right now, we're working on getting our graphing implementation to meet our high standards.
Once our graphing library is finished, we plan on building a new demo showcasing universal-weave's portability: A Loom interface running on a microcontroller.
When we mean "can run anywhere", we mean *anywhere*, even in environments with less RAM than some graphing calculators (for reference, the TI-Nspire CX has 64MB of RAM).
(When we reach Stage 3, we're considering expanding on this to build a Loom Deck: An open-source physical Loom terminal with functionality on par with Tapestry Loom, which can be easily assembled by anyone using off-the-shelf components.)
We're also continuing work on experimental efforts to extend the capability of our multiplayer Loom implementation, and we'll keep you in the loop regarding further developments on this.
We've finally completed our work on the core Loom algorithms, and now we're moving on to the next most important component of a Loom interface: Graphing!
Existing graphing libraries don't work well for Looms, as they tend to be too slow, heavy, or opinionated to be usable for the user interface.
So, we're building our own, integrated into universal-weave, and we aim to hold the graphing code to the same standards as the core Loom algorithms: High reliability, intuitive behavior, good performance characteristics, and the ability to run anywhere.
After this demo, we're planning on building Loom UI components for multiple GUI toolkits, starting with egui and ratatui, which will act as the transitionary period between Stages 1 and 2.
During Stage 1, we're building core Loom building blocks that can run anywhere.
As part of that, we've recently been putting substantial effort into improving universal-weave's performance without sacrificing reliability.
Development is going to proceed in three stages:
- Stage 1 = Building the essential foundation for any and every Loom.
- Stage 2 = Building powerful tooling to make most Loom ideas a single prompt away.
- Stage 3 = Showing the world what's possible.
1. Frontier AI models, like Claude Fable and GPT Sol. They assist with many aspects of development, such as testing, prototyping, and code review, significantly expanding the scope of what the project can tackle.
2. Allowing the core developer to continue working on the project by funding their basic living expenses.
3. Outside assistance with design and development work.
At the moment, this has been limited to traveling to discuss Loom design with those who have been using Loom interfaces almost since the term was coined, and some of these people have also built their own experimental Loom implementations in the past.
However, if funding allows, we may hire outside contractors for some parts of the project's development.
4. Hardware for UI testing and demos. At the moment, the only hardware bought for this project is a microcontroller-based device for an upcoming demo, but there are plans to build Loom UI components for a variety of UI toolkits, some of which may need to run on mobile devices of different form factors.
Whenever possible, the $weave fees will be spent on funding further development work and allowing the project to be more ambitious than it could be otherwise.
Here's what's the money ($weave fees + direct donations) is being spent on, roughly sorted by current proportion of total spending:
this is probably best chance we have at a Simulator Era resurgence
none of the other people theoretically interested in loom I've spoken to were willing to take action, even with my support
so i'm choosing to support kat, because i'd rather have one distant hope than for the dream of loomworlds to fizzle out
finally, they're choosing to fund something actually real
a world where anyone will be able to claude code up their own loom, but with a stable and interoperable foundation, is a world i want to live in.
We've recently been focusing on optimizing the foundational code, as we'd like to make Looms into a user interface primitive that can be used anywhere.
Later this month, we're planning on building a demo of a physical Loom terminal to demonstrate what's possible.
Development is going to proceed in three stages:
- Stage 1 = Building the essential foundation for any and every Loom.
- Stage 2 = Building powerful tooling to make most Loom ideas a single prompt away.
- Stage 3 = Showing the world what's possible.
A few people told me my previous explanation was too technical, so here is @universalweave in the simplest way possible:
A normal AI chat is like one straight road. If you want to explore a different answer halfway through, you usually have to restart, open another chat, or lose your previous direction.
A Loom turns that road into a map.
From any message, you can create multiple branches, explore different answers, return to an earlier point, edit an idea, compare the results, and combine the useful parts without deleting the other possibilities.
For example:
You ask AI to help build a business. One branch explores the product, another creates the marketing strategy, and another analyzes the risks. You can explore all three separately and later bring the best ideas together into one final plan.
@universalweave is the open-source foundation @transkatgirl built so developers can add this branching system to AI assistants, research tools, writing apps, games, decision-making software, and collaborative workspaces without building everything from scratch.
Simply put:
Normal AI chat gives you one answer path.
@universalweave lets you explore every possible path.
$weave
We've already solved some of the hardest technical and UX problems involved in representing a Loom as a DAG.
But we're not satisfied yet, because we love expanding the frontier of what's possible.
Development is going to proceed in three stages:
- Stage 1 = Building the essential foundation for any and every Loom.
- Stage 2 = Building powerful tooling to make most Loom ideas a single prompt away.
- Stage 3 = Showing the world what's possible.
loom implementations are easy to prototype, but incredibly hard to build well. even with LLMs doing all of the work, it can take months to build something that feels truly complete.
so, i'm building thoughtfully-designed, highly-flexible building blocks that can be mixed and matched to build any loom.
(2/x)
Today, we're in Stage 1, which will likely be the longest of the three stages because it involves solving the hard technical problems.
We're building functionality that has never been used in any LLM interface before, because interfaces shouldn't be limited to being just a tree.