DEV Community: Siamese_Cat_Dev

Open Canvas: A Free Open Source Infinite Canvas for Storyboarding, Film Planning and Visual Thinking

Siamese_Cat_Dev — Fri, 14 Aug 2026 17:00:40 +0000

Most creative projects do not begin with a perfectly organized document.

They begin with scattered ideas.

A reference image here. A camera angle there. A rough scene description. A character concept. A location photo. Maybe a few arrows connecting things that only make sense inside your head.

Traditional documents are not particularly good at this kind of thinking.

That is exactly the problem DJAI Open Canvas is trying to solve.

DJAI Open Canvas is a free, open-source, local-first infinite canvas built for visual thinking, storyboarding, film pre-production, mood boards, diagrams and shot planning.

Instead of forcing your ideas into pages, slides or rows, it gives you an open space where you can arrange information visually.

For filmmakers, video creators, designers and people experimenting with AI filmmaking, that can be surprisingly useful.

What is an infinite canvas?

Imagine putting a giant whiteboard on your wall.

You could place a storyboard in one corner, reference images beside it, notes underneath, camera ideas on the right and a rough flowchart somewhere else.

You could then zoom out and see the entire project.

An infinite canvas brings that idea into software.

There is no traditional page boundary telling you where your ideas need to fit.

That makes it useful when the relationship between things matters as much as the things themselves.

A filmmaker might organize a project like this:

Opening scene

Character references

Location inspiration

Camera angles

Lighting ideas

Storyboard frames

Shot order

Visual effects references

Production notes

Instead of keeping all of those things in separate folders and applications, they can become part of one visual workspace.

Why I think this is especially interesting for filmmaking

Film production is extremely visual.

A written description such as "wide shot of the character entering a dark warehouse" communicates an idea, but a director, cinematographer, editor and production designer may still imagine four completely different scenes.

A storyboard helps turn that abstract idea into something everyone can see.

That is why visual planning is such an important part of pre-production.

DJAI Open Canvas takes the idea further by giving creators space not only for storyboard frames, but also for the information surrounding those frames.

You could place a character reference next to a scene.

Put lighting references underneath it.

Add notes about camera movement.

Then connect that scene to the next part of the story.

You are effectively building a visual map of the production.

For independent filmmakers and small teams, that can be much easier to understand than a collection of disconnected documents.

It could also be useful for AI filmmaking

AI video generation has made visual planning even more important.

Generating a good-looking eight-second clip is one problem.

Generating 30 clips that actually look like they belong in the same film is a completely different problem.

You need to think about character consistency, locations, shot progression, costumes, lighting, camera direction and the visual language of the overall production.

An infinite storyboard canvas gives you somewhere to organize those decisions before you start generating everything.

For example, you could create a section for each scene and keep the following information together:

Reference image

Storyboard frame

Prompt concept

Character appearance

Environment

Camera angle

Camera movement

Lighting

Expected duration

Transition into the next shot

Suddenly AI video generation stops being a random prompt-and-hope process and starts looking more like actual pre-production.

That is where I think tools like DJAI Open Canvas become particularly interesting.

Why open source matters

There are already plenty of online whiteboards, design platforms and storyboard applications.

DJAI Open Canvas is interesting for another reason: it is open source.

The repository is publicly available on GitHub.

That matters because developers are not limited to whatever features a SaaS company decides to provide.

You can inspect the project.

You can modify it.

You can build on top of it.

You can contribute improvements.

You can adapt the concept to your own workflow.

And because the project describes itself as local-first, it is designed around the idea that your working environment does not always need to revolve around sending everything to somebody else's cloud service.

For developers and technical teams, that opens up some interesting possibilities.

A production company could eventually adapt the interface around its own workflow.

A university could experiment with it as a visual teaching tool.

A developer could extend it for game planning.

An AI filmmaker could build integrations around image or video generation.

A creative agency could create its own internal planning environment.

Open source changes the question from "Can this software do what I want?" to "Can I make this software do what I want?"

That is a much more interesting question.

You do not need to be a developer to understand the idea

Open source projects sometimes make themselves sound unnecessarily complicated.

The basic idea here is actually simple.

DJAI Open Canvas gives you a large visual workspace where you can organize a project spatially instead of forcing everything into documents.

If you have ever used sticky notes on a wall to plan something, you already understand the concept.

The difference is that your wall can now keep expanding.

For a filmmaker, that wall becomes a storyboard.

For a designer, it becomes a mood board.

For a developer, it could become a system diagram.

For a content creator, it might become a video planning board.

For an AI filmmaker, it could become the control center for references, prompts and generated scenes.

That flexibility is the interesting part.

A useful open-source alternative in a world of subscriptions

Creative software is increasingly moving toward subscription models.

Sometimes those subscriptions are worth paying for.

But there is also value in having open-source alternatives that people can learn from, modify and contribute to.

DJAI Open Canvas is still a young project, and it should be viewed that way.

This is not about pretending that a community project automatically replaces every mature commercial product.

The exciting part is that the foundation is open.

People can experiment with it.

Developers can improve it.

Creators can test new workflows.

And the community can help determine where it goes next.

That is how interesting open-source tools often begin.

Where to find DJAI Open Canvas

The project is available on GitHub under:

lovecatisgood-sudo/djai-open-canvas

If you are interested in open-source storyboard software, infinite canvas tools, visual project planning, AI filmmaking workflows or film pre-production software, it is worth checking out.

Clone it if you want to experiment.

Fork it if you want to build something different.

Open an issue if you find something that could be better.

Contribute if you have an idea worth adding.

And if you simply like seeing free creative tools being developed in public, give the repository a star.

DJAI Open Canvas is still early, but the concept makes a lot of sense: give creators an open visual space, let them organize ideas their own way, and make the underlying project open enough for developers to take it further.

For filmmakers trying to organize increasingly complicated visual workflows, especially people experimenting with AI-generated film and video, that could become very useful.

The turning point is here, real acceleration in AI redefining humanity.

Siamese_Cat_Dev — Mon, 10 Aug 2026 04:34:13 +0000

AI Is Starting to Change How Scientific Research Works

Most of the attention around AI still goes to things that are easy to see. A new image model comes out and suddenly the images look more realistic. A coding model gets better and someone posts a video of it building an app in ten minutes.

I follow all of that because I work with AI and software myself, but lately I’ve been much more interested in what is happening in scientific research.

Some AI systems are starting to do more than search papers, summarize information or answer questions. They are beginning to take part in the research process itself.

Google’s Co-Scientist is a good example. It can generate scientific hypotheses, but generating ideas is not really the impressive part anymore. Modern language models can come up with plenty of plausible ideas if you give them a problem.

The difficult part is figuring out which ideas are actually worth testing.

Co-Scientist approaches this by having different parts of the system generate ideas, criticize them, compare similar hypotheses and gradually improve the stronger ones. I find this much more interesting than simply asking an AI for its best answer, especially when language models can still produce something completely wrong while sounding very confident.

In science, eventually someone has to test the idea and see if it actually works.

Researchers have already explored systems like this in areas including cancer research and drug repurposing. This doesn't mean AI has suddenly cured cancer, and I think headlines sometimes make these results sound much more dramatic than they really are.

What matters is that AI can help researchers search through possibilities.

There are an enormous number of drugs, proteins, mutations, cell types and combinations that scientists could investigate. Testing everything in a laboratory is impossible. Experiments cost money and take time.

If AI can help move an unusual but promising candidate higher up the list, researchers can spend more of their time testing better guesses.

That alone could be extremely useful.

Other systems are starting to go further.

Robin, for example, has been used in research where the AI doesn't simply suggest something to test. It can also work with experimental results, help write analysis code, create visualizations and use what happened in one experiment to help decide what should be investigated next.

This is where I think things get particularly interesting.

Scientific research is a loop. You start with an idea, run an experiment, collect data, analyze what happened and then decide what to try next.

A lot of time is spent between those steps.

If AI can shorten that process, researchers may be able to try more ideas in the same amount of time. An experiment that creates another question can quickly lead to another experiment, and several possibilities could potentially be explored at once.

The important development may not be an AI suddenly producing one brilliant scientific answer. It may simply be that researchers can move through this cycle much faster.

Another system I’ve been following is Mammal, which tries to learn relationships between different kinds of biological information.

That makes sense because biology doesn't really care about the categories humans use to organize it. A molecule interacts with a protein, that protein affects a cellular pathway, gene expression changes and the cell behaves differently.

Those relationships cross several areas of biology.

A model that can work across those layers may notice useful connections that would otherwise take researchers much longer to find.

Mammal has been tested on things like predicting how cancer cell lines respond to drugs and generating parts of antibody designs. Again, these are early research results. A drug working on cells in a laboratory is very different from that drug working safely in a human patient.

But that isn't really the point.

The interesting part is that AI can help researchers decide where to look.

When you put systems like these together, you can start to imagine how scientific research might change.

A researcher begins with a problem. AI searches existing research and suggests possible explanations. Another model helps rank compounds or generate potential designs. Researchers test the most promising candidates. The resulting data goes back into the system, which helps analyze what happened and suggests what might be worth trying next.

Then the process repeats.

Laboratory automation could eventually make that loop even faster.

I don't think this means scientists disappear. Someone still needs to understand whether a result makes sense, decide which questions are worth asking and recognize when something unexpected deserves further investigation.

AI is useful here because humans have limits. Researchers specialize, nobody can read every paper ever published, and there are simply too many possible experiments to test everything.

The machine doesn't need to become the scientist.

It can help scientists search a much larger space.

There are obviously risks as these systems become more capable. Models hallucinate, datasets contain biases and experimental results don't always reproduce. Something that works in cultured cells can fail in animals, and something that works in animals can still fail in humans.

Biology is also an area where increasingly capable AI systems need serious safety controls and human oversight.

So I don't think every new AI biology paper should be treated as a breakthrough.

But I do think the overall direction is worth paying attention to.

A few years ago, the interesting question was whether AI could answer scientific questions.

Now researchers are beginning to explore whether AI can help decide which question should be asked next.

For me, that is a much more important development.

The biggest impact of AI on science may not eventually be one famous AI-discovered drug. It may be thousands of smaller improvements to the way research is done, allowing scientists to test ideas, learn from the results and move on to the next experiment faster.

We are still very early, but AI becoming part of the scientific process isn't really a future prediction anymore.

It has already started.

Full video : https://www.youtube.com/watch?v=rwujwQn3wOg&t=1102s

I build and experiment with AI and software to help my Siamese Cat Cafe :https://siamesecat.cafe/ which could help you saving hundreds of dollar every year on SEO : https://www.youtube.com/watch?v=DNlpgX7MAv4&t=5s

I also created the [Siamese Cat Dev course at DJAI Academy : https://djai.academy/siamese_cat/dev/course, where I focus on learning how to actually build with AI by connecting models, code, data and tools instead of simply learning whichever AI product happens to be popular right now.

Building a Free, Local-First SEO Crawler for Developers and Small Businesses

Siamese_Cat_Dev — Sun, 02 Aug 2026 03:26:08 +0000

Screaming Toad , not a frog. An alternative to Screaming Frog and Ashrefs have been built. Opensource and self hosted.

A technical SEO crawler can save hours of manual work.

It can find broken links, missing titles, indexing problems, duplicate pages, redirect issues, and pages that search engines may struggle to understand.

The problem is that many professional SEO tools require a recurring subscription.

That may be reasonable for a large SEO agency, but it can be difficult to justify for:

Independent developers
Students
Small agencies
Local businesses
Open-source projects
Founders managing only a few websites

This was the motivation behind SEO Screaming Toad — Not Frog, an open-source technical SEO crawler designed to run locally.

The goal is simple:

Crawl a website, identify technical problems, preserve the evidence, and help the user understand what should be fixed.

The project combines a Go crawler, SQLite persistence, a React dashboard, a local API, a command-line interface, and an MCP server for AI-assisted workflows.

But the main benefit is not the technology.

The benefit is being able to inspect and improve a website without paying for every crawl or uploading the crawl database to a third-party platform.

Why Build Another SEO Crawler?

There are already excellent commercial SEO tools available.

They are mature, powerful, and widely used.

However, many developers and small businesses do not need an entire enterprise SEO platform.

Sometimes they only need answers to a few practical questions:

Are there broken links?
Can search engines reach the important pages?
Are page titles missing or duplicated?
Are canonical tags configured correctly?
Are redirects creating unnecessary chains?
Is important content visible only after JavaScript runs?
Did the latest website update introduce new problems?

A local crawler can answer these questions without requiring a cloud account or recurring subscription.

It also gives developers more control over the data and the implementation.

Testing the Crawler on Real Websites

The crawler was tested on two websites with very different purposes:

djai.academy
siamesecat.cafe

DJAI Academy provides AI education, software-development services, and coding-related content.

Siamese Cat Café is a local business in Bangkok that depends on customers discovering its location, services, menu, and activities through search.

At first, both websites appeared functional.

The pages loaded, the navigation worked, and the content was visible.

But crawling the sites revealed issues that were easy to miss during normal development.

These included:

Broken and outdated links
Weak or duplicated page metadata
Pages that were difficult for search engines to discover
Indexing and sitemap inconsistencies
Internal linking problems
Page titles that did not clearly describe the content
Technical differences between raw HTML and rendered content

After reviewing and fixing these issues, both websites showed better technical SEO health.

The improvements included:

Fewer broken links
Cleaner indexing signals
Better internal navigation
Improved SEO audit scores
Stronger search visibility
Higher rankings for relevant pages

The main lesson was that a website can look correct to a visitor while still sending confusing signals to search engines.

The Real Value of a Technical Audit

An SEO audit score is useful, but the score itself does not improve a business.

The value comes from what the score represents.

For example, fixing a broken link may lead to:

Fewer visitors reaching dead pages
More users reaching a service or product page
Better internal distribution of link authority
Easier crawling for search engines
A more professional user experience

Fixing an indexing problem may allow a page that already exists to finally appear in search results.

Improving a title may help both search engines and users understand the page more clearly.

The benefit is not simply “better SEO.”

The benefit is helping the right person find the right page.

Local-First by Design

The crawler stores its working data locally using SQLite.

This means the crawl database stays on the user’s machine.

That provides several advantages:

No required cloud account
No URL-credit system
No subscription needed to reopen previous crawl data
Better control over client or internal website information
Easier experimentation for developers
A simpler setup than running several external infrastructure services

SQLite was selected because the application is intended to be easy to run locally.

A user should not need to configure Redis, PostgreSQL, Kafka, or a distributed queue before checking a small or medium-sized website.

SQLite also makes the application portable.

The crawler can store:

Discovered URLs
Fetch state
Page metadata
Links
Audit findings
Crawl events
Checkpoints
Comparison data

Write operations are controlled carefully, while the crawling workers can continue fetching pages concurrently.

Recovering Long Crawls

One of the more important design goals was recovery.

A crawler should not lose all progress because:

The application closed
The machine restarted
The network failed
The crawl was paused
The user cancelled the job
A rendering worker crashed

The crawler persists its frontier and crawl state.

It supports:

Pause
Resume
Cancel
Checkpoints
Interrupted-run recovery
Crawl history
Recrawl comparison

This makes the crawl database more than a temporary cache.

It becomes a record of what was discovered, what was processed, and what still remains.

For larger websites, that is much more useful than restarting from zero after every interruption.

Raw HTML and Rendered Content Are Different

Modern websites often rely heavily on JavaScript.

A search crawler may receive one version of a page from the server and a different version after JavaScript executes.

For example:

The server response may contain no title
JavaScript may insert a title later
Canonical tags may be added client-side
Links may appear only after rendering
Important content may not exist in the original HTML

It is tempting to render the page and treat the result as the only version.

However, that can hide useful evidence.

SEO Screaming Toad keeps raw and rendered evidence separate.

This allows the user to inspect:

What the server originally returned
What appeared after rendering
Which version triggered an audit finding
Whether JavaScript improved or damaged the page’s SEO signals

This distinction is especially useful when debugging React, Vue, Next.js, and other JavaScript-heavy websites.

Evidence Instead of Only Scores

Many audit tools present a list of problems, but it may not always be obvious why a page was flagged.

The crawler attempts to preserve evidence for each finding.

A finding can include:

The affected URL
Rule identifier
Rule version
Severity
Extracted evidence
Suggested remediation
Known limitations

For example, a duplicate-title finding should not only say that duplicates exist.

It should identify the affected pages and preserve the titles that caused the rule to trigger.

A canonical issue should show the observed canonical value and the target involved.

This makes the audit easier to verify.

It also reduces the risk of blindly applying automated recommendations.

Audit Coverage

The current audit engine checks several common areas of technical SEO.

These include:

HTTP errors
Broken internal links
Redirects
Page titles
Meta descriptions
Heading structure
Canonical tags
Indexability
Robots directives
Robots.txt
Sitemap coverage
Hreflang
Duplicate content signals
Image alt attributes
Broken image resources
Crawl depth
Internal linking
Mixed content
Selected security headers
JSON-LD structured data
Raw-versus-rendered differences

The project does not claim that every warning automatically affects ranking.

Technical findings should be reviewed in context.

For example, a missing page from a sitemap may be intentional. A duplicate title may be acceptable for certain filtered pages. A blocked page may be blocked by design.

The tool should provide evidence, not pretend to replace human judgment.

MCP Support for AI Agents

The project also includes a Model Context Protocol server.

This allows compatible AI clients to interact with the crawler through bounded tools.

An AI client can perform tasks such as:

Create a crawl profile
Preview crawl scope
Start a crawl
Pause or resume a job
List pages
Inspect links
Review findings
Explain a rule
Compare two crawls
Generate an export

The important word is bounded.

The MCP server does not provide:

General shell execution
Arbitrary SQL queries
Unrestricted filesystem access
Unrestricted HTTP requests

Instead, it exposes specific SEO and crawl operations.

This allows an AI assistant to help analyze an audit without giving it unnecessary access to the host machine.

A possible workflow could look like this:

Start a bounded crawl.
Wait for completion.
List high-severity findings.
Group issues by page type.
Explain the most common rule.
Export the results.
Compare the crawl after fixes are deployed.

The goal is not to let AI control everything.

The goal is to give AI structured access to trustworthy crawl evidence.

Crawl Safety Matters

A crawler is also a network tool, so safety controls are important.

The project includes controls for:

Robots.txt enforcement
Per-host politeness
Scope restrictions
URL limits
Depth limits
Response-size limits
Redirect validation
Timeout budgets
Retry limits
DNS and IP validation
TLS hostname verification
Crawler-trap protection

These controls help prevent a simple website audit from turning into an unbounded or unsafe crawl.

Users should only crawl websites they own or are authorized to inspect.

What About the 100M+ URL Claim?

The repository includes an experimental architecture for segmented crawling campaigns.

The idea is to avoid treating a very large site as one enormous in-memory crawl.

Instead, work can be divided into bounded segments and processed over time.

Synthetic persistence and analysis campaigns have completed at 1 million and 5 million URLs.

However, the 100M+ figure should be understood carefully.

It is a theoretical architectural target.

It is not:

A verified live crawl of 100 million URLs
A guarantee
A laptop benchmark
A claim that every website can be crawled at that scale
A promise of commercial support

Real-world capacity depends on:

Storage
CPU
Memory
Network speed
Rendering requirements
Website behavior
Crawl limits
Politeness settings

The large-scale architecture is experimental and should be evaluated separately from the normal local crawler.

What Improved on the Real Websites?

The most useful outcome came from applying the crawler to real projects.

For djai.academy, the audit helped identify technical problems affecting content discovery and page clarity.

Fixing those issues improved:

Broken-link coverage
Page metadata
Internal linking
Indexability
Search visibility
Rankings for relevant pages

For "siamesecat.cafe", the improvements were connected directly to local discovery.

A local business website needs search engines to clearly understand:

What the business is
Where it is located
What services it offers
Which pages are important
How users can visit or contact it

Fixing technical problems gave the site a stronger foundation for appearing in relevant local searches.

The crawler did not create the business value by itself.

It revealed where existing value was being hidden by technical mistakes.

Reflection:

Building and using the crawler changed the way I think about website maintenance.

A site is not finished when it is deployed.

Every new page, redesign, framework update, CMS change, or content edit can introduce problems.

Technical SEO should therefore be part of the development cycle.

A useful workflow is:

Crawl the current site.
Save the results.
Make a change.
Crawl it again.
Compare the findings.
Fix regressions before they affect users or search visibility.

This is similar to testing code.

Developers would not normally deploy major changes without checking whether the application still works.

The same idea should apply to website structure, metadata, indexing, and internal links.

Project Status

SEO Screaming Toad is currently a release candidate.

It is not a stable replacement for every commercial SEO platform.

It also does not provide the proprietary keyword, competitor, and backlink databases available in broader tools such as Ahrefs.

Its purpose is narrower:

Provide an open, local, inspectable way to crawl websites and understand technical SEO problems.

The project is MIT licensed and open to technical review.

Repository:

https://github.com/lovecatisgood-sudo/Free-Opensource-SEO-Screaming-Toad-not-Frog-tool-with-100million-url-crawl-potential

Websites used for real-world testing:

https://djai.academy

https://siamesecat.cafe

Final Thoughts

Small technical problems can quietly reduce the value of an otherwise good website.

A business may already have useful content, good services, and a strong product.

But if links are broken, pages are difficult to index, or search engines receive unclear signals, that value becomes harder to discover.

The most important benefit of a crawler is not producing more data.

It is showing developers and business owners where their existing work is being wasted.

A free, local-first crawler lowers the barrier to finding those problems.

And once the problems are visible, they become much easier to fix.

opensource` #seo #webdev #golang