Nice idea. I recently published an article with a different twist. Static Vite+React site but all the backends are via OAuth PKCE and your customers bring their own. https://type2fun.net/infinitely-scalable-personal-apps I like the idea of building apps but skipping the infra burden/costs.
I wonder why this type of deployment is not more popular - pushing all resources inside a single HTML file, with a script tag, and inline resources as blobs.
- 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.
I do this whenever possible. As a separate issue, I also aim for <50KB whenever possible, e.g. I made a multiplayer browser game in 32KB and a LLM UI in 20KB.
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/
I made an interesting chat system too: A way to sneak chat messages in through images for places where they otherwise wouldn't exist... pretty different.
It just looks like a funny slop project if you read the English readme, but reading the Russian PHILOSOPHY.md [1] (auto-translated [2] if you don't read Russian) makes you realize that there's probably something more than "let's implement a messenger using git remote as a storage", knowing how popular messenger apps are getting blocked in Russia.
>Macaroni Messenger is not a political statement.
>We are not trying to circumvent restrictions.
>We are not trying to circumvent restrictions.
>We are not trying to fight the laws.
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.
It's kinda implicitly obvious that a messenger needs some kind of backend. Though admittedly using Github as a backend is such an unusual choice that I would consider it equally important to mention.
Looking at the source I don't think that's true -- it's using GitHub specific APIs to read/write files. It's not standard git so any remote wouldn't work, and the mechanics are more akin to a key-value store than git really.
Not to say you couldn't add a generic git protocol to this, just that that's not being done here.
> 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.
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."
- 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.
Not a problem if you're deploying a single file
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...
[1]: https://opensource.google/documentation/reference/patching#f...
But what if that's exactly what I want to do?
https://github.com/kristopolous/image-chat
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.
[1]: https://github.com/vanyapr/makaroshki/blob/main/PHILOSOPHY.m...
[2]: https://github-com.translate.goog/vanyapr/makaroshki/blob/ma... (Google Translate)
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.
https://pastebin.com/raw/EPtJM5Dp
Claude loves this dumb word "burn". Recently it even said "burn a TOTP" as if they are finite.
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.
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."
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.
https://news.ycombinator.com/item?id=48487542
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?