I’d caution against your “free forever” offer. Most people tend to backtrack on it.
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.
Thanks for the feedback, I appreciate that you are looking out for me really.
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.
> it would be “piruletas” (at least in Spain Spanish).
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.
The funny thing is that I am Spanish, and I tricked myself because we discussed between "piruletas" and "piruetas", and I had the message prepared before the name change, my bad.
To be honest, my non-negotiable was that it needed to have some orange, but that doesn't work very good with a calm, minimalist app, so it remained as the accent color.
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.
Nice, simple, light and dark theme, a calendar.
I would remove the internet checks for your storage.ko-fi.com and it did some calls on pypi.org and files.pythonhosted.org.
All it needs should be on the docker by default. But that is just me.
I find our standards and norms around network access to be unacceptable. Programs shouldn’t access the Internet without opt in by the user either as a setting or a UI interaction.
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.
I used memos which has similar feature set. One day I lost my hard drive and I had to restore from s3. Turns out the backup I had was incompatible with latest version of memos app.
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.
Since this is largely/almost entirely for private data with occasional publicly accessible content through share links, this is a good candidate to be rebased onto remoteStorage, which gives you auth and storage for free, and there's always an escape hatch for the user to have access to their data—and permit other apps to access it, too.
Very nice! The diary app market is super saturated, but diaries are such a personal thing that there's never really too many, since everyone has different requirements. I did try many, but also decided to build my own. I should be done soonish, I really need it haha
People usually put pretty intimate private thoughts in diaries so I'm curious how your app handles preserving each user's privacy. Are files encrypted or only stored on a user's local machine or something?
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.
I’d caution against your “free forever” offer. Most people tend to backtrack on it.
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.
Thanks for the feedback, I appreciate that you are looking out for me really.
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.
Pirueta is not lollipop in Spanish, it would be “piruletas” (at least in Spain Spanish).
Piruetas is pirouette, as in what a ice skater might do.
> it would be “piruletas” (at least in Spain Spanish).
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.
Well, we would refer to chupa-chups (brand) to the ones with a ball head. And Kojaks if they had gum inside.
Piruletas were the flat ones, either circular or heart shaped.
What about the classic heart-shaped bright red "piruleta" from the "fiesta" brand?
That's a piruleta. The spherical ones are chupa-chups.
The funny thing is that I am Spanish, and I tricked myself because we discussed between "piruletas" and "piruetas", and I had the message prepared before the name change, my bad.
That's a lucky escape.
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 would like to add Nissan Moco (snot/mucus in Spanish) to that list.
That's where LLMs with web search enabled help to check for dangerous project names in other languages.
You don’t need LLMs for this (or most things suggested in HN comments). http://wordsafety.com/ has existed for years.
They don't have "etron" thought, which might explain some poor naming by Audi ?
Hyundai Kona (renamed in Portugal to Kauai)
Wholesale accepting all of the stock Opus colors is certainly a choice.
To be honest, my non-negotiable was that it needed to have some orange, but that doesn't work very good with a calm, minimalist app, so it remained as the accent color.
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 don't know, I thought the design looked really nice.
Nice, simple, light and dark theme, a calendar. I would remove the internet checks for your storage.ko-fi.com and it did some calls on pypi.org and files.pythonhosted.org. All it needs should be on the docker by default. But that is just me.
Thanks for the feedback! Appreciated!
----
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!
I find our standards and norms around network access to be unacceptable. Programs shouldn’t access the Internet without opt in by the user either as a setting or a UI interaction.
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.
I used memos which has similar feature set. One day I lost my hard drive and I had to restore from s3. Turns out the backup I had was incompatible with latest version of memos app.
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?
Entries are stored in a SQLite database, and uploaded images sit on disk under the configured DATA_DIR. Both are in a single Docker volume.
Since this is largely/almost entirely for private data with occasional publicly accessible content through share links, this is a good candidate to be rebased onto remoteStorage, which gives you auth and storage for free, and there's always an escape hatch for the user to have access to their data—and permit other apps to access it, too.
<https://remotestorage.io/>
Very nice! The diary app market is super saturated, but diaries are such a personal thing that there's never really too many, since everyone has different requirements. I did try many, but also decided to build my own. I should be done soonish, I really need it haha
People usually put pretty intimate private thoughts in diaries so I'm curious how your app handles preserving each user's privacy. Are files encrypted or only stored on a user's local machine or something?
There are two cases:
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.
Read this as "dairy app" and had so many questions
LOL
"one entry per day" takes on a whole different meaning that way.
The demo doesn't work (invalid account when using the creds mentioned on the homepage)
Thanks for the feedback, I figured it out, I guess I forgot about the trolls...
Rolling out now...
I just tried it demo/piruetas and it works, can you double check?
Can confirm that that username and password are not working in the login page.
I have tested many times, I have asked other people too... I cannot replicate what you are experiencing, sorry.
Have tested again and it's working for me now.
(Firefox Android)
Edit: It was firefox, it doesn't work on firefox!
I use firefox and I have e2e tests that work in firefox, feel free to create an issue in the github repo explaining a bit what is not working for you
Same issue for me.
Same. It just doesn’t work.
Also a bit confused about self-hosted vs “free”.
You can self host the app yourself or use the free hosted one I provide
same
How do you monitize the hosted version?
I don't, I just wanted to give back to the FOSS community.
If someone finds it useful and want to collaborate with the project they can tip me on ko-fi.