> 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.
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.
You're quoting me back at me. The quote is still correct. The backend doesn't exist. The messenger works. If that breaks your mental model of how software should be built — good. That was the point.
> torrents need trackers but we still consider them peer to peer
false. there's DHT and we sometimes exchange magnet links with friends and trackers are optional. trackers just allow it easier and at scale.
> crypto needs nodes but we still consider them decentralized
It's only decentralized when somebody doesn't get to control enough nodes. Even if it was decentralized, it's apples to oranges. It's not serverless or peer to peer and this messenger is not distributed.
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'm not advocating this development approach, but I also think some of your reasons aren't particularly robust when scrutinized.
> 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.
If you need a build script, your app is probably too big to be a single .html already.
> 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.
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.
Alright, this is pretty cool. I don’t see any reason for it to be a single-file web app, though!
Going through your article on the topic [0], I think the only strong point that SFWAs have which SPAs don’t is: “you can download and run them completely offline”. This highlights the best use case for SFWAs – it is something that you might want to download and run offline. Hypervault [1] is a better example here, IMO.
SFWAs do have drawbacks, mainly the inability to cache things independently (it’s all-or-nothing), or to download things in parallel. So basically it boils down to two questions:
• Is my app something users would want to run offline?
• Will I update it frequently enough for the cache problem to matter?
If it still makes sense to distribute your app as an SFWA, but you have to use a bundler, you can have the best of both worlds by making two builds: one as an SFWA, and one as a “traditional”, chunked static SPA. It should be fairly easy (just make two different configs, building from the same source).
Pretty graph! iOS Safari, takes just under a second probably to load each time I pan across the graph. Wonder what it’d take to bring it all the way to smooth scrolling—too demanding on resources?
Looking again, figure it has to do all the math again with each pan/drag, so minor latency makes sense.
This is an example of a single html-file that I serve: https://basketball.4e4.in
It weighs in at around 30 KB including a favicon, and it's quite functional.
In this case, it's 45kbyte over the network. Instead of very impractical, we might agree that it can be not ideal for many apps, but it's an interesting and valid way of "packaging" a tool / service.
If someone chooses this deployment method, it's likely that they have the ability to design with minimal resources.
My take: hitting three API endpoints doesn’t require a bundler or 400 MB of node_modules — most apps, especially hobby single‑page projects, can and should be built without a framework.
Or as an SVG file. I have an interesting experiment that puts a sprites sheet, CSS and even some scripting in the favicon file. Since every browser wants some type of favicon anyway, why not overload it with fun stuff?
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.
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/
The closing </html> tag is mandatory because Macaroni Messenger plugins are inserted immediately before it. This is the convention defined by the plugin system.
I made an interesting chat system as well: A way to sneak messages in through images for places where they otherwise wouldn't exist... pretty different.
> The Hippocratic License is an ethical software license created to ensure that open source software is not used for harmful purposes, aligning with human rights principles
The paragraph doesn’t really explain the rationale for forbidding WTFPL and even Public Domain and CC0? They’re all fine for commercial use, aren’t they?
I find it funny, but prefer just MIT or CC0. I like the idea of the GPL for core OS components you don't want to be locked down by anyone, but for everything else, unless you the developer intend to monetize so you can maintain it, MIT is fine (even if you intend to monetize it can be fine too).
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."
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.
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.
There is a popular view in Russia, including within the software developers communities, that "politics" is something bad and dirty; people often ban "politics" in group chats and forums.
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.
Thanks for clarifying, that's a pretty good summary. Russian developers experienced the same "HN is not for politics" kinds of reaction on Habr (russian HN, more or less) a decade ago, until politics came for them and Habr died. Before that, "being outside of politics" was a stance some people identified with because back then Putins regime didn't repress as much and the situation was "stable". Seeing a take like that still having its followers after our autocracy matured even more is disheartening and sad.
documentation was updated in the last few days. You might want to read the section about the funny legal collision this architecture creates — not sure, but it might apply to other jurisdictions too, not just Russia. Either way, it's an interesting side effect of using generic git hosting as a message transport.
The paradox is that Macaroni Messenger is absolutely a joke project.
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.
It does kinda make sense... until it doesn’t. It is a cool project from a tech standpoint, but it’s not practical when we have, well, email? (This is discussed elsewhere in the comments already, of course.)
That’s exactly what I thought after posting — so now it supports end‑to‑end encryption without a handshake. Still a single HTML file. Still no backend.
Nice idea. I would have expected it would use WebRTC for p2p client-to-client connection. A noted related project is Trystero [0] that uses all sort of external services to allow client-to-client discovery (such as Nostr, BitTorrent, Supabase etc.) - maybe a future project to combine the two.
This is not a bad idea ... for public team communication. This pretty much solves the "Discord is not documentation" and the dataloss in forum problems. If the communication was stored in the same place as the repostory, you are guaranteed to have saved and searchable messages. As a side-effect, AI can read all the past discussions for better "1000% vibecoding"
to paraphrase what he said, "instead of K9s, PostgreSQL, Redis, Oauth, WebSocket Gateway, Service Discovert; we're going to use git, html and json", I had a panic attack as soon as I read that.
<critique>
OP keep saying the backend implementation doesn't matter, it can be trivially switched to something other than Github. It's not. The whole app you write revolves around Github's HTTP endpoints. There's no actual provider-agnostic Git operation in the code (for that you need to use isomorphic-git [1]). So a much more apt title for this should be: "Macaroni - a chat UI in a single HTML file that stores messages data in a Github repo"
</critique>
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.
You might have heard of other languages. They tend to import words but adapt spelling and pronunciation. Sometimes even meaning. Your own language has them too. I also bet you spell quite a few place names and countries according to tradition, not by any official spelling.
"Sending a message to your mother should not require infrastructure comparable to a small bank."
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.
That’s fair criticism of the current implementation.
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.
> 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.
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.
I don't think this was meant to be taken as seriously as you seem to be taking it
I'm directly addressing arguments made by the person I responded to. I'm not going to be taking you seriously, because you are not.
Email and SMS are faster. Also monitored, moderated, and mined.
Macaroni doesn't fix speed. It fixes who holds the keys — and who gets sued. That's the point.
If I use Outlook 365, Microsoft holds the keys. If I use Github, Microsoft holds the keys.
[dead]
Saying that this doesn't use a backend is like saying serverless app doesn't run on a server
We don't say no backend — we say not our backend.
You explicitly stated that "The backend does not exist."
You're quoting me back at me. The quote is still correct. The backend doesn't exist. The messenger works. If that breaks your mental model of how software should be built — good. That was the point.
...and that's why I've always hated that name
torrents need trackers but we still consider them peer to peer
crypto needs nodes but we still consider them decentralized
direct tcp/ip communication still requires routing but etc
> torrents need trackers but we still consider them peer to peer
false. there's DHT and we sometimes exchange magnet links with friends and trackers are optional. trackers just allow it easier and at scale.
> crypto needs nodes but we still consider them decentralized
It's only decentralized when somebody doesn't get to control enough nodes. Even if it was decentralized, it's apples to oranges. It's not serverless or peer to peer and this messenger is not distributed.
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.
It's very impractical.
- 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'm not advocating this development approach, but I also think some of your reasons aren't particularly robust when scrutinized.
> 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.
If you need a build script, your app is probably too big to be a single .html already.
> 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.
https://fuzzygraph.com is a 1.4Mb Single HTML file that I have a build script for (https://github.com/calebmadrigal/fuzzygraph).
Alright, this is pretty cool. I don’t see any reason for it to be a single-file web app, though!
Going through your article on the topic [0], I think the only strong point that SFWAs have which SPAs don’t is: “you can download and run them completely offline”. This highlights the best use case for SFWAs – it is something that you might want to download and run offline. Hypervault [1] is a better example here, IMO.
SFWAs do have drawbacks, mainly the inability to cache things independently (it’s all-or-nothing), or to download things in parallel. So basically it boils down to two questions:
• Is my app something users would want to run offline?
• Will I update it frequently enough for the cache problem to matter?
And it’s up to you to find the balance here.
[0]: https://gods.art/articles/single_file_web_apps.html
[1]: https://gods.art/articles/single_file_web_apps.html#hypervau...
---
Actually I’ve just thought of something.
If it still makes sense to distribute your app as an SFWA, but you have to use a bundler, you can have the best of both worlds by making two builds: one as an SFWA, and one as a “traditional”, chunked static SPA. It should be fairly easy (just make two different configs, building from the same source).
The biggest thing for me is how durable it is as an SFWA (avoiding software rot)
Pretty graph! iOS Safari, takes just under a second probably to load each time I pan across the graph. Wonder what it’d take to bring it all the way to smooth scrolling—too demanding on resources?
Looking again, figure it has to do all the math again with each pan/drag, so minor latency makes sense.
> "can't reuse a stylesheet, script or image on a different page (each has to have their own copy)"
Not a problem if you're deploying a single file
This is an example of a single html-file that I serve: https://basketball.4e4.in It weighs in at around 30 KB including a favicon, and it's quite functional.
Nice. Is the spacing like this on your end? Some overlap- https://i.ibb.co/3m9JKmC1/Clock-Alignment.jpg
In this case, it's 45kbyte over the network. Instead of very impractical, we might agree that it can be not ideal for many apps, but it's an interesting and valid way of "packaging" a tool / service.
If someone chooses this deployment method, it's likely that they have the ability to design with minimal resources.
My take: hitting three API endpoints doesn’t require a bundler or 400 MB of node_modules — most apps, especially hobby single‑page projects, can and should be built without a framework.
Or as an SVG file. I have an interesting experiment that puts a sprites sheet, CSS and even some scripting in the favicon file. Since every browser wants some type of favicon anyway, why not overload it with fun stuff?
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.
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/
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...
Would be nice if you could make a version people can run in their browser..!
I've been trying to advocate for Single File Web Apps. I even tried to create a wikipedia page (https://en.wikipedia.org/wiki/Draft:Single_File_Web_Apps), but it keeps getting rejected.
I created a couple Single File Web Apps: https://fuzzygraph.com and https://hypervault.github.io/.
1. Start an SFWA competition as a joke. Then watch the submissions come in. First year it will be a handful. Second year it will be heavy.
2. Publish sfwa articles on wikia. Blog the development process.
3. A show page for sfwa creations.
Maybe the ideas above should be in reverse order?
I have an article on sfwa's here: https://gods.art/articles/single_file_web_apps.html. Still hasn't been enough to get past the wikipedia pedants.
You just described the Macaroni plugin system — plugins are literally appended as <script> tags before the closing </html> tag.
Note that you don't actually need a closing </html> tag.
The closing </html> tag is mandatory because Macaroni Messenger plugins are inserted immediately before it. This is the convention defined by the plugin system.
saludos desde cuba
I made an interesting chat system as well: A way to sneak messages in through images for places where they otherwise wouldn't exist... pretty different.
https://github.com/kristopolous/image-chat
I'm a fan of the license. https://www.wtfpl.net/about/
Besides other fun things about this license, using it effectively forbids Google employees to send patches to your projects. [1]
[1]: https://opensource.google/documentation/reference/patching#f...
TIL
> The Hippocratic License is an ethical software license created to ensure that open source software is not used for harmful purposes, aligning with human rights principles
The paragraph doesn’t really explain the rationale for forbidding WTFPL and even Public Domain and CC0? They’re all fine for commercial use, aren’t they?
Only a guess, but it could be because WTFPL is effectively very similar to having no license at all from what I gather
I thought they were basically BSD/MIT but even less annoying.
I find it funny, but prefer just MIT or CC0. I like the idea of the GPL for core OS components you don't want to be locked down by anyone, but for everything else, unless you the developer intend to monetize so you can maintain it, MIT is fine (even if you intend to monetize it can be fine too).
> changing it [the license] is allowed as long as the name is changed.
But what if that's exactly what I want to do?
Then it's allowed.
"Single file" is a bit misleading when it requires Github to do anything.
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.
And its why we cannot have nice things. This is likely a TOS violation of github.
That’s fair, although GitHub is just the default transport because it requires zero setup.
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.
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."
I think it's pretty clear from the readme that this is a humorous proof of concept more so than anything someone should seriously use.
True, but imagine this use case:
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?
That’s literally what release 1.03 enables.
From the translated readme:
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
[flagged]
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.
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.
[1]: https://github.com/vanyapr/makaroshki/blob/main/PHILOSOPHY.m...
[2]: https://github-com.translate.goog/vanyapr/makaroshki/blob/ma... (Google Translate)
>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.
There is a popular view in Russia, including within the software developers communities, that "politics" is something bad and dirty; people often ban "politics" in group chats and forums.
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.
Thanks for clarifying, that's a pretty good summary. Russian developers experienced the same "HN is not for politics" kinds of reaction on Habr (russian HN, more or less) a decade ago, until politics came for them and Habr died. Before that, "being outside of politics" was a stance some people identified with because back then Putins regime didn't repress as much and the situation was "stable". Seeing a take like that still having its followers after our autocracy matured even more is disheartening and sad.
> Seeing a take like that still having its followers after our autocracy matured even more is disheartening and sad.
I suppose it’s more of a CYA nowadays than that. (Well, at least one can hope.)
Here's the translated version I got (GH translate didn't work for me for some reason).
https://pastebin.com/raw/EPtJM5Dp
Slightly better translation: https://markdownpastebin.com/?id=fb9680965f42433fb3a4c6bf7a0...
documentation was updated in the last few days. You might want to read the section about the funny legal collision this architecture creates — not sure, but it might apply to other jurisdictions too, not just Russia. Either way, it's an interesting side effect of using generic git hosting as a message transport.
The paradox is that Macaroni Messenger is absolutely a joke project.
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.
It does kinda make sense... until it doesn’t. It is a cool project from a tech standpoint, but it’s not practical when we have, well, email? (This is discussed elsewhere in the comments already, of course.)
That’s exactly what I thought after posting — so now it supports end‑to‑end encryption without a handshake. Still a single HTML file. Still no backend.
Nice idea. I would have expected it would use WebRTC for p2p client-to-client connection. A noted related project is Trystero [0] that uses all sort of external services to allow client-to-client discovery (such as Nostr, BitTorrent, Supabase etc.) - maybe a future project to combine the two.
[0]: https://github.com/dmotz/trystero?tab=readme-ov-file#how-it-...
> so the first screen does not burn unauthenticated GitHub API rate limit.
Claude loves this dumb word "burn". Recently it even said "burn a TOTP" as if they are finite.
This is not a bad idea ... for public team communication. This pretty much solves the "Discord is not documentation" and the dataloss in forum problems. If the communication was stored in the same place as the repostory, you are guaranteed to have saved and searchable messages. As a side-effect, AI can read all the past discussions for better "1000% vibecoding"
You might find this branch interesting:
https://github.com/vanyapr/makaroshki/tree/macaroni
Turns out the messenger wasn’t enough, so now it also stores its own lore.
When docs say "no backend", but git (GitHub) is actually your backend :/
Not mine lol
Seems kind of similar (at least in purpose) to giscus, a commenting system powered by GitHub Discussions.
https://github.com/giscus/giscus
to paraphrase what he said, "instead of K9s, PostgreSQL, Redis, Oauth, WebSocket Gateway, Service Discovert; we're going to use git, html and json", I had a panic attack as soon as I read that.
Reminds me of a time when it was possible to "deploy" single HTML files via shorturl services by using base64 URI scheme
I laughed at the 1000% vibecoded badge
So now I have something to slap on my experimental vibe coded projects readme documents.
That README got a few solid chuckles out of me. :) Really cool project imo
<critique> OP keep saying the backend implementation doesn't matter, it can be trivially switched to something other than Github. It's not. The whole app you write revolves around Github's HTTP endpoints. There's no actual provider-agnostic Git operation in the code (for that you need to use isomorphic-git [1]). So a much more apt title for this should be: "Macaroni - a chat UI in a single HTML file that stores messages data in a Github repo" </critique>
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.
Fixed last night.
The GitHub-specific adapter is now one of several.
So, browser = Java Runtime; uber HTML = applet?
please do not propagate errors ... it is "Maccheroni"
You might have heard of other languages. They tend to import words but adapt spelling and pronunciation. Sometimes even meaning. Your own language has them too. I also bet you spell quite a few place names and countries according to tradition, not by any official spelling.
Yes!
Now we need to build a messenger that uses pastebin exclusively as the backend.