Ente-IO

[MickLesk]

community-scripts/ProxmoxVE#373

Application Name
ente io

Website
https://github.com/ente-io/ente

Description
Ente is a service that provides a fully open source, end-to-end encrypted platform for you to store your data in the cloud without needing to trust the service provider. On top of this platform, we have built two apps so far: Ente Photos (an alternative to Apple and Google Photos) and Ente Auth (a 2FA alternative to the deprecated Authy).

Due Diligence

[MickLesk]

Despite self-hosting (if I haven't done anything wrong), there is a 10GB limit on photos. Wtf? @community-scripts/contributor

[CrazyWolf13]

@MickLesk a quick google search led me to this: ente-io/ente#2193

[MickLesk]

Wtf 😄

[CrazyWolf13]

I think maybe because it's literally the exact source code of their hosted variant :D

[tremor021]

ente admin update-subscription -a <admin-user-mail> -u <user-email-to-update> --no-limit

[dramikei]

Hi, is this being worked on?
I am willing to contribute if theres a draft PR/branch etc :)

[MickLesk]

Its already in this Repo, but not done. Currently Not worked on

[dramikei]

Went over the install scripts and made a list of things that are pending in order to get a clean installation:

1. Backend's IP needs to be hardcoded via NEXT_PUBLIC_ENTE_ENDPOINT and NEXT_PUBLIC_ENTE_ALBUMS_ENDPOINT env variables. Currently we set them as http://localhost:8080 and http://localhost:3002 respectively. This wont work, since these URLs are used by the Frontend when accessed by a browser. They need to be the IP of the LXC containers or the public URL for the backend.
   1. The frontend is built into html, which means if user changes the LXC's ip manually or via DHCP, they'll need to rebuild the frontend and move everything again to /var/www/ente/apps/* directory manually
2. We currently don't install ente cli as part of our install script, we should add it as it is helpful in upgrading the account's subscription to unlimited (as mentioned by @tremor021 )
3. Once the initial User account is created, we need to verify the email using the verification code generated. That cannot be completed unless we setup SMTP, or by digging through the backend (museum)'s logs.
   1. Ente CLI does not support creating user accounts, which means we cannot automate creating a default admin account whatsoever.
   2. Since we cannot have a default admin account, it means we cannot elevate the account to unlimited subscription automatically as well, user's intervention is needed
   3. Ente Cli is basically an API wrapper for museum, and it relies on keyring to store/fetch secrets. We don't install keyring as part of our install script. Although there seems to be a way to bypass it by using an env variable (refer: CLI: Allow setting secrets path via env var ente-io/ente#2426) but storing secrets in a txt file for an application that boasts E2EE seems like a flaw than a solution. I haven't tested it out yet.

I feel, we can get Ente working quite easily, @MickLesk has done a lot of the hard work already, there are a few quirks which we cannot resolve unless Ente team improves the self-hosted user experience like allows admin user creation via ente-cli, or by creating a default admin on museum setup. Maybe even a seed-data SQL script would be helpful. Without which we cant ensure a smooth unattended installation experience (which i would prefer tbh)