So I built Piruetas (it means pirouettes in Spanish - she chose the name btw).
It's a day-per-page diary with rich text editing, drag-and-drop image uploads, auto-save, public share links, and a clean mobile UI. It can be set up for Personal or Multi-user usage via docker compose deployment.
She seems to like it so I decided to give back to the community and make it available for everyone (after some QA)
Live demo: https://piruet.app (login: demo / piruetas — data resets every 30 min!) GitHub: https://github.com/patillacode/piruetas
There’s one case where it gets super popular, or attacked by spammers/bots, and the site becomes more effort to operate publicly than you want to do for free.
In another case your girlfriend stops using it, as well as some family, and the continued maintenance over the years feels like it isn’t worth it (because there is always maintenance.)
Either way you might want to shut it down, and promising “forever” to users feels problematic when you’re not being finically incentivised to keep it running. With the financial incentives it’s much easier to pass the burden on to someone else if you can’t run it for whatever reason too.
My intention, the meaning of "forever free", is that I will provide the service for anyone and everyone that cannot self-host themselves, but of course, if I don't have money myself to rent a server, for example, and I have to shut the app down I would inform the people using it. This is more or less expected from a free app in my experience and there is a paragraph in the terms related to this, under "NO GUARANTEES"
What I want to say though is that I won't charge users for as long as the app lives, if the app dies for whatever reason I will try to inform users to export their data and find a better place I guess.
Piruetas is pirouette, as in what a ice skater might do.
In Spain Spanish I never heard them called anything else than "chupachup" (regardless of brand), guess it's a bit of a "Kleenex/facial tissue" syndrome going on there.
Piruletas were the flat ones, either circular or heart shaped.
For some reason car manufacturers have this issue
Mitsubishi Pajero (renamed in Spain).
Ford Pinto (renamed in Brazil).
Toyota MR2 (renamed in France although slightly different issue).
Honda Fitta (renamed in Scandi countries)
I still laugh every time I see one though, which is almost every day...
The rest wasn't my choice, we just did a few tests and my gf chose the palette you see today.
Having said that, you got a point and I didn't even realize it until you mentioned it.
----
I had some time to look into this, I think it is partially valid.
The pypi.org and pythonhosted.org calls happen only at docker build time when dependencies are installed, the running container makes no calls there.
The ko-fi badge image (storage.ko-fi.com) is a real runtime outbound request though, every page load fetches it from their CDN.
That's fair criticism and it has an easy fix which is to self-host the image, which I'll do like I do with the rest of things, like fonts.
Thanks again!
We had many years of applications from the dial up error and prior that didn’t assume constant connectivity and we all survived.
Even an OS enforced blend of oauth style initial permission and LittleSnitch where the user is asked what they consent to at first launch would be fine.
Since then I just gave up on web based tools for notes. I just want to save my notes and be able to recover them when things go wrong. A simple directory with markdown files and hugo blog allows me to do that.
OP how does your app store the journal entries?
Self-hosted: your data lives entirely on your own machine/server and obviously I never see it. That's the primary privacy model the app is designed around.
piruet.app (my hosted instance): you're basically trusting me. (I know, trusting a random stranger on the internet... right?)
Other things I can tell you: Passwords are bcrypt-hashed and I can't recover them, but journal entries are stored in a SQLite database on the server. There's no at-rest encryption of content, so in principle the server's administrator could access the entries. I don't do it on principle and there's no infrastructure set up to do so, but I can't make a technical guarantee of that.
If you just don't trust the person hosting it, I'd honestly recommend self-hosting yourself.
At-rest encryption of entries is something I'd like to add, it's just not there yet. In the meantime, piruet.app is best treated as a demo/trial environment rather than a permanent home for sensitive writing.
If you have thoughts on how to approach encryption in a way that doesn't break usability (search, rich text, etc.) I'd genuinely love to hear them.
"one entry per day" takes on a whole different meaning that way.
Rolling out now...
Also a bit confused about self-hosted vs “free”.
If someone finds it useful and want to collaborate with the project they can tip me on ko-fi.
