On a Sandy Beach

No posts for a wee while

Mike's Notes

I was on holiday for the last few weeks and am back now. There will be no blog posts, newsletters or meetings until Pipi Core is back up and running.

Update 27/05/2026

Lots of surprises. Making rapid progress. The peace and quiet are bliss.

Update 31/05/2026

The problem and solution are how things are named. Pipi auto-generates thousands of code names using multiple pattern languages, and all the naming conventions require many minor fixes for several unexpected reasons after migrating from a developer laptop to a production server environment. Everything else is absolutely fine.

Other naming problems are also being solved now, including:

The rapid development of Boxlang by Ortus has brought forward another challenge. Pipi 10 will be migrated to run on top of Boxlang in 2027 to support multiple languages, including C++, CFML, COBOL, Go, Java, JavaScript, PHP, Python, Rust, etc.
Future integration with cloud-based LLMs.
Future integrations with Office365, Google Workspace, Zoho, LibreOffice, etc.

The common solution is to create standardised naming systems that are simple, stable, robust, schema-based, versioned, self-documenting, and extensible to meet unanticipated future needs.

This is done by replacing code-based naming rules with database-driven ones that can be easily edited in the future via an admin UI.

90% of these names are internal, hidden in the closed core, and how they work and what they are will not be discussed here. The rest will be publicly and fully documented as part of the open-source workspaces for developers to work with.

Update 02/06/2026

I'm changing the disclosure boundary between the Pipi closed-core and open-source workspaces. Previously, "disclose everything unless there is a security reason not to". This is now changed to "disclose on the basis of need to know".

Closed-core accounts for 90% and open-source workspaces for 10% of lines of code, databases, etc.

This will reduce the documentation burden, given Pipi's vast scale. So, the open-source workspaces will be fully shared and documented on GitHub, etc, without restriction. This includes;

Standards schema
Ontologies
Parameters
Laws of physics
HTML + CSS
Algorithms
Module DDD models
Workflow diagrams
Documentation
API schema
UI code
etc

This also means some existing technical documentation about the closed-core will become hidden and only available internally.

Update 07/06/2026

Pipi Core is the IDE used to edit Pipi Core (AKA: which came first, the chicken or the egg?). Temporary UIs have been created and are being used across multiple engines to edit the names in use. This is much faster than directly editing data, which had to be done initially. The next step will be turning auto-generation back on. Once that's done, temporary UIs will be used to build permanent UIs. More automation will then be enabled via the UIs, and so on, as Pipi Core builds itself with a human in the loop.

Update 08/06/2026

The list of code cases available to use now for auto-generated naming, I/O translation, etc with examples, includes;

camelCase: userProfilePicture
kebab-case: user-profile-picture
PascalCase: UserProfilePicture
snake_case: user_profile_picture
SCREAMING_SNAKE_CASE: USER_PROFILE_PICTURE
Train-Case: User-Profile-Picture
flatcase: userprofilepicture
UPPER-CASE-KEBAB-CASE: USER-PROFILE-PICTURE
Sentence case: User profile picture
Title Case: User Profile Picture
middot·case: user·profile·picture
dot.case: user.profile.picture
UPPER CASE: USER PROFILE PICTURE
lowercase: user profile picture

Update 12/06/20026

Checking that these changes to variable names and internal messaging do not clash with the Gödel Machine.

Update 17/06/2026

The DevOps Engine (dvp) has unexpectedly proven to be critical to solving this puzzle. Mostly fixed last night. Watching the rather excellent live Google talk, Beyond the GPU: Maximising goodput with self-healing AI infrastructure, this morning has given me valuable insights into how to fix the remaining issues by reviewing Google HPC YAML files. 😎😎 Sometimes insights come from the strangest places.

Update 01/07/2026

The main work now is rapidly configuring Pipi for production and full autonomous automation. Using Google Search AI Mode (Gemini) and then Grammarly Pro makes the work easier and 100x faster.

I have decided to have Pipi re-render the many Ajabbi draft public websites with the new and missing developer information. (20K pages)
The website's .robot.txt file will then be unlocked to enable search engines.
The HTML will be updated to make it easier for AI to read.
This blog will be imported into Pipi, cleaned up, re-exported from Pipi, and published to Blogger via the API.
The new posts created in Pipi will return to A Sandy Beach to discuss something already built rather than being built.

Update 02/07/2026

The DevOps and IaC engines are getting rapid data model overhauls. The IaC engine is a great test for the variable names. I'm building a capability into Pipi to autonomously and automatically run OpenTofu and Ansible, initially targeting the Pipi Data Centre, then GCP and AWS for deployments. It's going very well and making rapid progress.

Update 05/07/2026

Pipi will initially run the open-source enterprise applications on Google Cloud Run and Google Cloud Storage (GCS). The code is complete and will be very low-cost to run, giving Ajabbi, a bootstrapping-purpose startup, a very long runway.

Update 18/07/2026

The job has now shifted to configuring, networking and deploying many physical servers. Installing software, including Pipi, labelling cables and rack gear, throwing out junk, tidying, etc., leaving nothing to chance. Shipping delays are holding up part deliveries.

Update 23/07/2026

On the basis of open collaboration and credits for experimentation, I was going to offer Google exclusive use of Pipi for a period (as a thank you) before Pipi open-source is donated to the Cloud Native Computing Foundation for all to use.

Pipi is designed to run massive enterprise systems for socially useful critical infrastructure on every platform in many languages and writing systems. Pipi makes these systems self-managing, resilient and adaptive. I had to solve hundreds of complex problems in parallel to make this work. (Easy for me, because I can do it all in my head visually, run simulations of thousands of components in my sleep, including the testing, then just build it and it always works. That's why no one else has cracked this.) Some days, I wake up, and the insights and designs pour out of my head like a firehose, and I can barely keep up even with 20+ drawings. There are many thousands of drawings using colour coding just like in this blog. I can remember everything I have designed since age 4 in great detail. Everything I read that's interesting gets turned into a 4d model in my head, moving; there are tens of thousands of them, never forgotten and able to self-assemble when I shut my eyes. It's how I think. I really don't understand how the rest of you can think only in words.

I'm getting exasperated with XWF. They are the external sales contractors to Google, and since 2021, they regularly contact me.

Selling GCP products (No need; I'm already convinced).
Acting as gatekeepers to any contact with Google Engineers to discuss novel integration options, which is the actual issue. How to combine Gemini (an LLM) and Pipi (non-LLM) to make something much better.
They are all very nice, but a complete waste of my time. No more XWF meetings, folks.

So, I have decided to target integration with Open Router instead of Gemini and open up the Pipi developer platform (it is big and coming 😎) to enable developers from Alibaba, Anthropic, AWS, Azure, DeepSeek, Google, IBM, Meta, Moonshot AI, OpenAI, Oracle, xAI, etc, or anyone else, to ensure integrations are optimal, 100% secure and vetted.

Pipi closed-core will never be for sale; it's getting a non-profit foundation behind it, a bit like Patagonia. I'm open to all genuine offers for collaboration and experimentation. Contact me.

Don't send sales engineers; send a senior, highly experienced engineer/architect/chief scientist who has time for an open chat without a pitch or an agenda and just see where it goes.

With hyperphantasia, plus multiple synesthesias, I think at lightning speed and draw everything fast. I love solving very hard problems that matter. I use assistive technology to write very slowly, so I prefer video meetings with good English and slides or time for quick engineering drawings.

If you want to meet in person, expect to work collaboratively at a whiteboard or blackboard like a mathematician. Plus coffee, of course. 😎

The future is open, even at the edge of chaos.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library >
Home > Handbook >

Last Updated

23/07/2026

No posts for a wee while

By: Mike Peters

On a Sandy Beach: 15/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I was on a no-coding holiday for the last few weeks to clear my mind, and it has been great. I am back on the job today.

Suspended

Until the closed-source Pipi Core is back up and running 100% on autopilot, 10x faster, the following are suspended.

New posts "On a Sandy Beach
All newsletters, including the weekly Friday Report and the monthly Ajabbi Research Newsletter.
The fortnightly online Open R&D meeting.

Rapid refocus

A new developer area with five coding screens, designed to be more productive for hypervisual learners.
A better library has been set up for my A4 drawings in ring binders, the many reference books I use, and more bookshelves are on the way.
The server rack has been moved to a better location.
The light levels have been adjusted.
A big office tidy is almost done. An office-work-only desk has yet to be set up with a cat bed included.
A separate area with no screens for the happy cat, coffee, music, reading and drawing.

Less is more

Minimise screen time to be more productive at work. The new setup is also much less tiring.

Get the job done

The good thing is that, with a holiday and lots of drawing, I now have mental clarity about what needs fixing and how to fix it. Mainly, quite delicate changes here and there, organised into a list of steps. Now, I need to concentrate on one thing only: go as fast as possible, without meetings, post-deadlines, phone calls, or other distractions.

How

1. Use an AI workforce

Be the architect, and AI fills in the dots to make it happen.

Use Google Search AI mode (Gemini) to generate 99% of the code in one-page chunks (including references) to copy and paste, then manually change the variable names and SQL. Careful, test everything, resulting in 100x faster progress. Know how everything works and rapidly raise personal skill level.

2. Then build a cathedral

Make a wooden scale model of a cathedral for the builders. Google Search AI mode (Gemini) makes each brick, and Pipi Core assembles the bricks into floors, arches, walls, and vaults...

Speed is king

With the 100x coding productivity gains from Google Search AI mode (Gemini), plus the 10x10x10x speedup of Pipi Core currently underway over the next few months, what previously took a year will be done in hours and better.

Phase transitions

Once these initial migration issues from laptop to server are resolved, further transitions can be anticipated as the number of engines rapidly increases beyond 20. Increasing the number of engines slowly changes the whole system's behaviour from deterministic to probabilistic and adaptive.

Here is a partial list of transitions expected as the number of engines increases from 0 to 200. The actual numbers are a bit of a guess.

20 engines enable Pipi 9 Core in a simple, deterministic structure.
40 engines enable a workspace with a UI for administering Pipi Core.
60 engines enable self-generation of user documentation.
80 engines enable REPL and IAC (infrastructure-as-code).
100 engines enable Workspaces for different user accounts.
Different Pipi 9 editions are made with the same engines, which recombine differently in response to the external environment.
And so on until...
200 engines self-organise into a multi-layered complex fluid structure with probabilistic behaviour and emergent properties, as engines also act as agents.
200+ engines enable Pipi 10 to interact with externally cloud-hosted LLMs, combining the very different strengths of both.

The luxury of statistics

Mike's Notes

A great article by David Court lays out a fundamental truth about the business of filmmaking.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > Compton
Home > Handbook >

Last Updated

08/05/2026

The luxury of statistics

By: David Court

Compton: 03/05/2026

Founder of Compton School, the business school for creative people: ‘The movie industry is a crucible where money and talent are refined down to their essence. It has so much to teach us about business, creativity and human nature.’

Why filmmakers can never see eye-to-eye with movie studios.

When filmmakers and studio executives come together there is always a great display of bonhomie.

Hands get shook and backs get slapped. As though they were bound together in their mutual enterprise: the movie business. Perhaps there’s some argy-bargy about profit shares but basically they are on the same page.

Yet the truth is: there is a fundamental disjunct between filmmaker and executive.

It’s not just that one is on salary while the other is eating their savings. Nor is it the power imbalance between them, or the different pathways they have followed to arrive where they are. It’s that one is operating at 30,000 feet and the other is dug in at ground level.

If you’re making a film, it occupies your entire field of view. You can’t see past it. You don’t have time or bandwidth to think about anyone else’s film. You are all in on one thing — the film you are making.

This is true financially too. You have put all your chips down on one square and you can’t take them back. Whereas the studio executive is managing a slate of films. They’ve got chips on 20 squares.

Harvard professor Mihir Desai calls this the core of finance. He starts his book The Wisdom of Finance with a story about chance and pattern. Chance is what the world looks like close up: an arena of luck, accidents, flukes, coincidences, or what the ancients called fortuna.

Whereas pattern is chance viewed over time – statistically. It’s what we notice when we study the world and keep records. It’s the view from 30,000 feet.

‘Finance, ultimately, is a set of tools for understanding how to address a risky, uncertain world’ – Mihir Desai

The study of patterns is what gave us the insurance business (the averaging of bad luck), portfolio theory in finance (strategic diversification) and the studio slate (the search for a hit). These are all methods of managing risk, of taming fortuna.

But our filmmaker has wandered into a casino and bet everything on single spin of the wheel. Their risk is irreducible. They don’t have the luxury of statistics.

So for all the backslapping, the studio executive and the filmmaker are really two different species. Different stakes, different aims, different view of the world.

For our filmmaker, chance is the whole point. The risk is not to be managed but to be taken.

This post is the first in a series I plan to publish based on my reading – the insights I’ve gathered and think worth sharing.

Context Engineering for Coding Agents - Fausto's Amsterdam workshop

Mike's Notes

The MLOps Community is fantastic, and it has a regular newsletter from Demetrios.

100% better than anything coming out of NZ or Australia. I attend MLOps events remotely whenever possible. Now I know where to find the talent capable of working on Pipi in future.

This is taken from a recent newsletter. Interesting how deterministic and probabilistic contexts are handled in generative AI.

All Pipi Engines are both deterministic and probabilistic as required.

The April 21 2026, MLOps Community Netherlands workshop video and slides are available.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > MLOps Community
Home > Handbook >

Last Updated

10/05/2026

Context Engineering for Coding Agents - Fausto's Amsterdam workshop

By: Demetrios Brinkmann

MLOps Community: 07/05/2026

Demetrios founded the largest community dealing with productizing AI and ML models. In April 2020, he fell into leading the MLOps community (more than 75k ML practitioners come together to learn and share experiences), which aims to bring clarity around the operational side of Machine Learning and AI. Since diving into the ML/AI world, he has become fascinated by Voice AI agents and is exploring the technical challenges that come with creating them.

Fausto's workshop focused on the part of agent systems you can control: what gets injected into the context window, when it gets loaded, and what should live somewhere else. You are not training the model on a daily basis, so the engineering work shifts to managing context, memory, tools, and retrieval.

His rule of thumb was to keep context usage under 25%, regardless of whether you are working with a 200k or 1M token model. Past that, things get slower, more expensive, and more error-prone, with cleaner options than letting the context window bloat.

The lens for the rest of the talk was a brain analogy. Attention is finite, memory shapes attention, and knowledge does not get embedded in a vacuum. An agent will only notice the right things if you have given it the right priors.

From there, Fausto split context into three categories.

Deterministic context includes CLAUDE.md, project rules, hooks on lifecycle events, auto-memory, and scheduled loops. His point on rules was especially practical: coding conventions belong in path-scoped or file-extension-scoped rules, not dumped into CLAUDE.md.
Human context covers chat turns, slash commands, and references.
Probabilistic context covers sub-agents, retrieval, MCPs, skills, and observers. Sub-agents are useful because they do not inherit CLAUDE.md, memory, or the default system prompt, which makes them better suited for specific non-coding tasks. Skills are markdown plus optional scripts, and can also wrap calls to other models when Claude cannot handle the job. Fausto's example was routing native video analysis through Gemini.

Two practical tips came out of this section. Turn on deferred tool loading, a single flag that reduces what gets injected at session start. And lean toward project scope over user scope for skills and MCPs, so the agent has the full descriptions it needs to choose well at runtime.

The second half made the case for treating long-term memory as a folder of markdown files rather than defaulting to a vector store, inspired by Karpathy's wiki memory idea.

The structure is an index plus raw source files, processed summaries, and a policy that decides what to ingest and retrieve. Concepts that recur get weighted up. Concepts that go unused decay over time. An observer agent watches the session and either pulls relevant knowledge into the active context or pushes new findings into the wiki.

To show the difference in practice, Fausto ran two Claude Code sessions on the same cellular automata task. Same model, same skills, same sub-agents, same CLAUDE.md. The only difference was that one had a populated wiki and the other did not. Under a five-minute timer, the wiki run pulled the concepts it needed and produced a working visualization. The default run fell back on parametric memory and live search, then ran out of time.

Context Engineering for Coding Agents: Hands-on Lab + Agent Build-Off

21 April 2026

Prosus NV

Gustav Mahlerplein 5, 1082 MS Amsterdam, Netherlands

A hands-on workshop on configuring Claude Code for real work.
Claude Code is powerful out of the box. But there's a gap between using it and mastering it. Closing that gap is mostly a matter of context: what the agent knows, where its memory lives, which rules it follows, and how its output gets verified before it ships.

This workshop is three hours of hands-on practice to optimize your Claude environment. After a short primer you join a pre-assigned team and build out a Claude Code setup in a prepared sandbox — working on memory, rules, hooks, retrieval, and prompt quality. In the final stretch we drop an unknown technical drawing on the screen and your system gets one run at it. Scores go on a live leaderboard, winners are announced in the room.

What you'll practice

Shaping what the agent sees and remembers
Writing rules and hooks that actually fire
Designing memory so it finds what matters
Judging output before it leaves the loop

Format

One continuous team build, one unknown challenge, one live leaderboard, closing with pizza and drinks. — The system you build in 60 minutes is the score you receive.

Agenda

5:00 PM — Walking dinner & Drinks
please be on time :)
5:30 – 5:45 PM — Welcome by Prosus
Opening and framing for the evening.
5:45 – 6:00 PM — Opening
6:00 – 7:00 PM — Theory + Mini-Demos
7:00 – 8:00 PM — Build Lab

Six phases: mission lock, sandbox orientation, second brain, skills + guardrails, self-test, freeze. Teams build their Claude Code system against the run contract. Facilitators float; the deck runs a silent timer.

8:00 – 8:15 PM — Drawing Reveal + One-Shot Run
An unknown technical drawing is broadcast into every team sandbox. Each system gets a single run. Whatever it produces is what gets scored.
8:15 – 8:20 PM — Processing Break
Last runs finish, evaluator collects output.
8:20 – 8:30 PM — Live Leaderboard + Winners
Scores land on screen. Jury walks through the top runs and the most interesting architectural choices.
8:30 – 9:00 PM — Pizza + Networking
Pizza, drinks, Q&A.

Who this is for

Technical practitioners who have already used Claude Code (or a comparable coding agent) and want to push past the default setup. Comfortable on the command line, and with Github, fluent enough in Python to read and edit a small repo.

What we provide

A pre-configured cloud sandbox per team, with Claude Code installed and API access included. Minimum requirement is to have a Claude Pro account — and bring your laptop.
Registering is not a confirmed seat — we curate the room and send confirmations separately

Delivered by Fausto Albers · GenAI R&D, AUAS · WonderWhy.ai

YouTube 2:27:28

3 constraints before I build anything

Mike's Notes

Note

Resources

https://jordanlord.co.uk/blog/3-constraints/

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
Home > Handbook >

Last Updated

08/05/2026

3 constraints before I build anything

By: Jordan Lord

Jordan Lord: 07/04/2026

Building radically simple, open tools and worlds through constraint-driven engineering.

These are the 3 constraints that I use before I start building anything. I'm a believer in constraints as an enabler for creativity. Constraints help us collapse the search space, and figure out innovative solutions to problems.

I've been a builder for 10 years, and I've built products that went nowhere because they were either too complex or had no identity. These are the constraints that I landed on after making those mistakes.

One page or it doesn't get built

This constraint limits complexity and ambiguity.

Write a one pager for all of your ideas. Your one pager captures your north star. It's non-negotiable, precise, ambitious, and lean. Once your one pager is written, it is applied to all different types of communication. Share it as a memo for investors, contributors, team members, friends, or family. Working collaboratively on a product, there will always be contention points and conflict, it can sometimes be difficult to know what battles to pick. If it's not in the one pager, then it's either not worth fighting over, or the one pager ought to be amended to include the thing. Not only is a one pager useful for communication, it's useful for organising your own thoughts. If you can't fill one page, don't fill the gaps with fluff, it means you're not ready to build. First research, plan, prototype, then write the one pager again. Iterate. If it requires more than one page, it's too complex, don't build it.

The core tech must be separable from the product

This constraint limits you to ideas that have real leverage and originality.

Develop a core piece of technology that supports your product and is not the product itself. The core tech is a method, skill, tool, or even product that supports what you're doing today but must survive without it. It's a type of reusable IP. Why? Separating the core tech forces you to think beyond the product that you're building. Products pivot in direction all the time, while your core tech is constant and compounding. Compounding efforts have non-linear gains over longer time horizons. Linus Torvalds developed git to improve the Linux kernel development workflow. HashiCorp has HCL (HashiCorp Configuration Language). Google has Kubernetes. But you don't need big tech resources to build core tech, it could be a library that you extract from your codebase, or even a methodology that you refine and commit to. Your core tech is your long term commitment. It is independent of your product's direction. However, it must be aligned with you or your company's long term vision. If your idea doesn't enable core tech, then it isn't high enough leverage.

One defining constraint must shape the product

This constraint limits feature creep and forces identity.

Define your own constraint that is front and centre to your product. That means the user sees and interacts with it all the time. It is obvious and it is what gives your product identity. A good constraint gives your product a feel, it permeates through all parts of the user experience. Minecraft is built entirely from blocks. IKEA is flat-pack, self-assembly furniture. The constraint that you choose limits scope by reducing your decision space, enabling you to concentrate on the problems that really make the difference. If you don't choose a constraint, or choose a bad constraint, you will build a bloated product that will try to do everything. The design of your product will "fall out" of a well-designed constraint. Like in your product, your constraint must be front and centre in your one pager.

Closing Rule

When it comes to deciding what to build, if it fails any of these constraints, then I don't build it.

Everything to Gain from Thriving Southland

Mike's Notes

My notes from an all-day workshop organised for farmers, which I attended yesterday.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > Thriving Southland
Home > Handbook >

Last Updated

08/05/2026

Everything to Gain from Thriving Southland

By: Mike Peters

On a Sandy Beach: 07/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I attended the all-day workshop "Everything to Gain" on 6 May 2026, held at the Ascot Park Hotel in Invercargill, New Zealand. Organised by Thriving Southland.

It was a day full of informative speakers on the global agricultural market, attended mainly by working farmers.

I learned a great deal from the objective data presented and from chatting with the farmers at our table. Hard times are ahead.

Thinking visually while listening

I mentally ran the Workspaces for Agriculture, testing the model assumptions against what I learned.

I also did a brain dump by creating 12 A4 drawings and solving the problem with variables in the current Pipi Core buildout.

Lessons I learned

Shifting a working Pipi 9 from a laptop to a data centre led to several unexpected consequences.

I underestimated the impact of

The naming, generation, and pub/sub of variables.
Host environment.

OS
Java
CFML Engine

Needing to turn Pipi into 4 separate role-based editions, which then exposed some hidden problems.
Adding a nest structure between Pipi and the host environment.
The impact of all of the above when each engine can pub/sub and be both deterministic and probabilistic, with multiple copies of each engine, and many in different locations.
Path length constraint in Windows vs Linux.

This very hard problem can only be solved by running a simulation of all 18 engines in parallel and watching the interaction. Lots of feedback loops.

Yesterday, a lot of progress was made visually, answering these questions. The variable-naming convention used for 12 months has held up, despite some earlier false flags.

More work is needed on variable distribution rules (messaging) for automation.

Global
Local
etc

Today I did another 8 drawings. They were of the Messaging Engine (msg) routing variables between the engines in both deterministic and probabilistic modes.

I will sleep on all this for a few days to see if anything else pops out, then commit it to code.

The woes of sanitising SVGs

Mike's Notes

MIT Scratch is a really great way to learn to code visually. A great article by Thomas Weber about some things with SVG use that need fixing.

Resources

References

Reference

Repository

Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
Home > Handbook >

Last Updated

07/05/2026

The woes of sanitising SVGs

By: Thomas Weber

Muffin Ink: 11/04/2026

Worked on TurboWarp, Scratch Addons, forkphorus.

Scratch has a long history of SVG-related vulnerabilities. The source of these is that Scratch parses user-generated (ie. attacker-controlled) content into an <svg> element and appends it into the main document for various operations (eg. measuring SVG bounding box in a more reliable way than viewbox or width/height).

No matter how briefly the SVG remains in the main document, this is an inherently unsafe operation. Scratch's approach to making this safe has been to build increasingly complex infrastructure around parsing the SVG and the markup within to remove dangerous parts.

I think Scratch's approach to SVG sanitization is doomed. To explain, we have to take a trip through the history of SVG sanitization in Scratch to see how well it has worked so far.

2019: XSS via <script> tag

In 2019, a few months after the initial release of Scratch 3, Scratch discovered that SVGs can contain <script> tags that Scratch would cause to be executed when the SVG loads. This is known as an XSS.

In Scratch terms, an XSS allows an attacker to take actions on behalf of anyone that loads their project. For example, the attacker can post comments, delete projects, or otherwise try to take over the victim's account. In Scratch Desktop, XSS is elevated to arbitrary code execution because Scratch Desktop enables Electron's dangerous Node.js integration feature. (TurboWarp Desktop has not enabled that feature since v0.2.0 from March 2021)

Example from Scratch's test suite:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
<circle cx="250" cy="250" r="50" fill="red" />
<script type="text/javascript"><![CDATA[
alert('from the svg!')
]]></script>
</svg>

This was fixed by using a regular expression to remove script tags.