Macaroni – a single HTML file messenger(github.com) |
Macaroni – a single HTML file messenger(github.com) |
To that end, requiring the use of GitHub for your application to work is a dead end.
"Macaroni Messenger is a distributed messaging system"
No.
"The backend does not exist."
Unless by "backend" you mean the underlying infrastructure and server logic you've made the clients depend on for the exchange of messages to happen.
The idea isn’t that transport magically disappears. The idea is that users don’t have to deploy, operate, pay for, or even think about transport.
GitHub happens to provide one out of the box, which makes the proof of concept extremely easy to try.
If I need to run databases, message brokers, servers and monitoring just to send my mom “please cook macaroni”, I’ve already lost interest.
It's sharing this advantage with every other free, third party managed communication service I can choose to depend on. It's also sharing the weakness that it puts me at the mercy of whatever third party I am relying on. It introduces a new weakness in that the third party being relied on here never intended for their infrastructure to be used in this way.
> If I need to run databases, message brokers, servers and monitoring just to send my mom “please cook macaroni”, I’ve already lost interest.
So don't. To that end, what specific problem does this address that other free third party communication service providers don't? My mother will have seen my email or SMS before you have instructed your mother on how to join GitHub and get an API token. We don't even need to agree on or stick to a provider.
That might just be an aesthetic choice on my part, but I often find that I am able to implement all the features I need in surprisingly few lines of code. e.g. the first version of my LLM UI was 200 lines and quite usable for my purposes.
And my OpenClaw clone was 50 lines. Just a Telegram wrapper around Claude, but turns out that's all I needed.[0]
Also no dependencies, frameworks, libaries etc. Not a hard rule, but I find that they add negative value about 90% of the time, at least at my scale.
There are dozens of us! :)
[0] Of course, "Claude Code" isn't 50 lines. Except, it turns out you can replace it in about 50 lines. From the SWE-bench folks: https://minimal-agent.com/
To this I added the missing outer loop (so it's actually an agent a human can use) and vendored in a microscopic llm lib (yay no deps). https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee3...
- you get a slower first load (cannot progressively fetch resources as they're needed) - can't reuse a stylesheet, script or image on a different page (each has to have their own copy) - can't cache commonly used files - can't make granular changes to specific parts of the code. user has to reload everything each time. - can't set a proper content security policy
And many more! It's cool for a tiny demo but for anything serious you wouldn't want a single (extremely ugly) HTML file.
> can't reuse a stylesheet, script or image on a different page (each has to have their own copy)
Isn't the point of a single HTML file that you don't have different pages that would need to reuse those assets?
> can't cache commonly used files
You can still cache the HTML.
> can't make granular changes to specific parts of the code
Pretty sure text editors can edit text regardless of whether it's a single file or multiple files.
> can't set a proper content security policy
I'd have thought a single page HTML file could negate the need for a CSP since you no longer have any resources accessible via a URI that you need to limit access to.
> you wouldn't want a single (extremely ugly) HTML file
Ugliness a subjective.
---
I think your first load point is the strongest one. But I'd also throw in "it's harder to develop a good single page HTML"
You could probably mitigate some of that difficulty by having a build script (like static site compilers) but then you have to ask yourself if you're introducing more complexity than you're attempting to solve.
Not a problem if you're deploying a single file
If someone chooses this deployment method, it's likely that they have the ability to design with minimal resources.
Sure the JavaScript won't load in CSS or favicon mode, but it can be loaded into the Dom as well as exist in the CSS.
In my SVG file I have lots of CSS variables generated by the JavaScript, then saved as a big list in the SVG, enabling light/dark mode things. SMIL animation too.
This experiment is based on what you described, an all in one HTML file.
In that experiment the CSS was getting clumsy due to the amount of SVG I had in there, so I put the CSS in the SVG for fun.
As for why, I am creating a modern version of an Embroidery sampler. These existed from centuries ago and served as a portfolio of sorts plus a reference on different stitches, such as how to do the alphabet.
So my SVG sampler has examples of how to do tricky things in SVG, with all of it human drawable and readable, so no massive paths, just simple primitives, clipped, masked, transformed and cloned to create all my icons, logos and clipart.
I hope to make SVG samplers a thing, so one SVG file and one HTML file to illustrate how it all works.
To be honest it has been an excellent learning experience and I can now do so many things with just the MDN reference for SVG as my guide.
[1]: https://opensource.google/documentation/reference/patching#f...
[0]: https://github.com/dmotz/trystero?tab=readme-ov-file#how-it-...
[1]: https://github.com/vanyapr/makaroshki/blob/main/PHILOSOPHY.m...
[2]: https://github-com.translate.goog/vanyapr/makaroshki/blob/ma... (Google Translate)
I'm sorry to say this, but this whole thing reeks of vibeslop, and not just the code. The docs, the readme, even the replies of OP are at least Claude-assisted, if not fully Claude-generated.
And I'm trying not to be derisive about LLM generated output anyway. LLM generated output can be sane and meaningful and to the point. This is just a questionably-cool tech demo dressed up under a sensationalistic title.
The protocol itself isn’t tied to GitHub and works with any Git remote.
If GitHub ever decided this wasn’t an acceptable use case, swapping the remote would be trivial.
Claude loves this dumb word "burn". Recently it even said "burn a TOTP" as if they are finite.
A messenger file with hardcoded settings and a hardcoded PGP key, stored on a USB stick.
You send a message.
Then you physically destroy the USB stick.
The client, the key, and the configuration are gone.
At some point the joke starts looking suspiciously like a dead-drop communication protocol.
How do you like that, FBI?
Macaroni Messenger is not a joke. It simply refuses to complicate solutions unnecessarily.
That's why some technical decisions might look like a joke.
Sometimes it really is a joke. But most of the time, it's just the simplest working option.
Not to say you couldn't add a generic git protocol to this, just that that's not being done here.
> If GitHub ever decided this wasn’t an acceptable use case, swapping the remote would be trivial.
Nope.
From the README:
"GitHub is the only working write provider right now. GitLab, GitVerse, Gitea, Forgejo, and other git hosts are protocol targets for future adapters. Today they are not finished write adapters."
This is talking politics without talking politics. The project literally attempts to circumvent russian censorship restrictions and their spirit. This is either a joke the file talks about or naive CYA.
Cool project nevertheless, I like idea of an utility SPA distributed as bare HTML file that doesn't even require a web server.
As a result, a highly technical person might work on a very complex solution to circumvent the restrictions but will declare (and probably even truly believe) that they are not making a political statement – as opposed to, for example, attending a protest, which is definitely considered a political action, or supporting a politician.
But once you reduce everything to Git + JSON, adding things like PGP, age, signatures, encrypted attachments, or end-to-end encryption becomes surprisingly easy.
Which makes it even funnier.
At first glance it looks like a toy.
After a few minutes you start asking:
“Wait… why does this actually make sense?”
I think the protocol is a bit underestimated. People see the joke before they see the architecture.
There are some surprisingly interesting properties hiding behind the absurdity.
Maybe it’s a hidden gem.
Or maybe I’m just rationalizing a messenger implemented as a single HTML file.
> You can still cache the HTML.
But then any time you update any part of the app, the user has to re-download the whole thing. It is also a problem with many traditional frontend builds, but if you carefully split it into chunks, you can update parts of the app while most of it stays cached.
See e.g. Linear’s approach to vendor dependencies: https://performance.dev/how-is-linear-so-fast-a-technical-br...
---
The strong point of single .html apps is, of course, that you can run them locally without setting up a web server or anything, and deploy anywhere you want by just uploading it. But it is a fairly niche thing IMO.
I suppose it’s more of a CYA nowadays than that. (Well, at least one can hope.)