Live data from Hacker News

Macaroni – a single HTML file messenger

github.com

31–40 of 93 posts

Re: Macaroni – a single HTML file messenger

#32
post #3

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…

>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 i…

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.

Re: Macaroni – a single HTML file messenger

#34
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-...

Re: Macaroni – a single HTML file messenger

#35
post #31
post #13

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...

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?

Re: Macaroni – a single HTML file messenger

#36

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.

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.

Re: Macaroni – a single HTML file messenger

#37

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…

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.

Re: Macaroni – a single HTML file messenger

#39
post #35
post #31

Earlier quoted context omitted.

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...

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 thought they were basically BSD/MIT but even less annoying.

Re: Macaroni – a single HTML file messenger

#40

"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 al…

> 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.

Post reply on HN