81–90 of 93 posts
Earlier quoted context omitted.
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.
Macaroni doesn't fix speed. It fixes who holds the keys — and who gets sued. That's the point.
"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.
Saying that this doesn't use a backend is like saying serverless app doesn't run on a server
Earlier quoted context omitted.
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…
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.
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…
Earlier quoted context omitted.
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 underestimat…
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.)
When docs say "no backend", but git (GitHub) is actually your backend :/
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…
The GitHub-specific adapter is now one of several.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.