If the target server is compromised or taken by LEA the data is gone.
That's true for any client that sends data to a server including your browser, email client or any other app. Colota doesn't operate a server. If you're concerned about server compromise, that's a server-side hardening question (disk encryption, access controls, etc.) that's outside the scope of a client app.
Laying the responsibility into the hands of the user is not ok for such an data aggregating service. Such highly critical, private and intime data should be protected and secure by default.
Colota is not a data aggregating service. It's a local-first app. By default, no data leaves your device. You choose if and where to send it. That's the opposite of aggregation. It's the user being in full control, which is exactly what self-hosted software is for.
Not even transport encryption is enforced in the project. At first glance, http is allowed on local connections?!? Generate a self signed SSL cert on start and pin it in the app. Easy.
It is. HTTPS is enforced for all public endpoints. HTTP is only allowed for private/RFC1918 addresses. Forcing TLS on 192.168.x.x would require every self-hoster to set up certificates for their LAN, which is a real barrier for the target audience. Colota already supports self-signed certificates if you install the CA on your device.
It is no excuse that other services do not follow these state of the art protection measures.
I didn't say that as an excuse. I explained why a client app that supports multiple independent backends can't enforce payload encryption. Each backend would need to implement the same decryption. That's a technical reality, not a lack of care about security.
Also again, a server is optional. It works offline and you can just export files with the data from the app.