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.

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.

If someone finds it useful and want to collaborate with the project they can tip me on ko-fi.

Rolling out now...

----

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!

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.

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

Comments URL: https://news.ycombinator.com/item?id=47985210

Points: 65

# Comments: 48

Because of that I found myself repeating the same steps over and over again when setting up new Python projects. Same song & dance.

I wanted a way to automate the setup for new projects, so I created ppieces.

Comments URL: https://news.ycombinator.com/item?id=39431006

Points: 1

# Comments: 1