best settings for optimal battery?

[humpty]

@andreasdueren findmy is on android? unless you mean the google one? if so, that's a hard pass I'm running grapheneos...

[andreasdueren]

@humpty https://www.cloudron.io/store/#app/findmydeviceserver its a bit tedious to set up but if you get it right it works pretty well.

[humpty]

@andreasdueren ah thank you

[andreasdueren]

@humpty No problem

[humpty]

btw, any way to do the ESS migration without the CLI thing? I couldn't npm/wtv that other dependency thing to install right. I tried it on pop_os. I installed Ubuntu today so I'll give it another shot later though.

[andreasdueren]

@humpty Unfortunately we need the CLI because we need to interact with two isolated containers to merge data. Running in either web terminal won't work. Are you running windows? The CLI on macOS has been pretty solid for me.

[humpty]

@andreasdueren yeah I'm on windows but i fired up a spare laptop that has pop_os on it (22.04 iirc). When that didn't work, I got Ubuntu desktop 26.04 installed today, but didn't try the CLI stuff yet. Even if I get the CLI to work. I had issues with my matrix server OIDC related stuff. I'm worried it's not going to go well. I'm going to check if I can export rooms and just import them manually into the new ESS.

Thinking down the line... what would happen to an existing ESS app once Cloudron picks it up and adds it to the official store? Will I have to reinstall and do a restore backup?

[andreasdueren]

@humpty

@humpty said:
I'm worried it's not going to go well. I'm going to check if I can export rooms and just import them manually into the new ESS.

Something going wrong is possible. But unless you skip the backup, the worst case is, that your users need to login when you roll back. However, I did one test run with users, rooms and various devices and had no issues.

Thinking down the line... what would happen to an existing ESS app once Cloudron picks it up and adds it to the official store? Will I have to reinstall and do a restore backup?

should they decide to support this officially, this would probably be the easiest way to migrate (unless they change something mayor in the package). This would mean

• shutting down the app
• taking a backup
• uninstalling/moving to different domain
• installing official package
• importing backup

Which would only mean downtime for users during the process, but overall a simple and low risk process. The initial migration to the complete package is the tricky part.

[andreasdueren]

@humpty said:

I had issues with my matrix server OIDC related stuff

This may be worth throwing at an LLM. Have you tried troubleshooting your config file with a good model?

[humpty]

@andreasdueren iirc I did compare it to a config of a fresh install and fixed things up but I didn't go into the database end of things. Currently, there's no OIDC working. We can log in via username/email and that works fine. Honestly, it seems easier to extract the key info from rooms that I want and start fresh with a new matrix/ess app. But, I do have a LOT of rooms as I've been using it as a journal/note-taking app (totally replaced Joplin over time).

[humpty]

The OIDC issues happened when I switched from one host to another AND moved the app across Cloudrons that didn't have the exact same users so it messed up the mapping. I think it's seppuku time for the old app

[andreasdueren]

@humpty said:

@andreasdueren iirc I did compare it to a config of a fresh install and fixed things up but I didn't go into the database end of things.

I'd be careful messing with the database. Went down that rabbit hole once while I was working on getting the whatsaoo bridge working. What a mess.

Currently, there's no OIDC working. We can log in via username/email and that works fine.

Are you saying the Element X app? This is by design and the general limitation of the current package. That's one reason why I worked on ESS, now even QR code login works.

Honestly, it seems easier to extract the key info from rooms that I want and start fresh with a new matrix/ess app. But, I do have a LOT of rooms as I've been using it as a journal/note-taking app (totally replaced Joplin over time).

Again, not sure if this is the best solution. Let me know how that went if you do go down that path!

The OIDC issues happened when I switched from one host to another AND moved the app across Cloudrons that didn't have the exact same users so it messed up the mapping. I think it's seppuku time for the old app

This sounds like it can be nicely consolidated though. Just delete the users which don't exist anymore.

[humpty]

@andreasdueren said:

This sounds like it can be nicely consolidated though. Just delete the users which don't exist anymore.

If I do that then all the data/rooms will be lost to us I think. As for the login, it's not Element X specific. IIRC, the original app was OIDC based and that got messed up with the transfer I mentioned. To regain access, I simply had to reset the password for each user and then I could log in with user/pass and that kept all the rooms and user data intact. Lately, I've been having issues with notification and delayed delivery. Then, I saw your ESS package on the forum and gave it a try. Delivery works fine AND we can finally call each other. I knew using Matrix as a note/journal app would come back and bite me in the a55.

I think I'll try the following in this order:

• copy paste the sensitive data that I really care about
• try looking to manual export of all rooms
• if none exist, try the CLI method (it's above my pay grade hence the reason it's lowest in the list)
• if that fails, rage, nuke the old server, and start fresh

[andreasdueren]

@humpty I'd actually flip your list upside down, because option 2 is a trap: Element's room export is HTML/JSON for reading only. There is no way to import it into a new homeserver. Room history, media, and encryption state can't be rebuilt from it. For someone with lots of journal rooms that path ends in copy-paste hell or data loss.

Meanwhile your OIDC worry is smaller than you think for the wizard path:

• The migration copies the whole Synapse database and converts it. Your users log in with passwords today, and password hashes migrate 1:1 (verified in my end-to-end tests). Broken/stale OIDC mappings from the old cross-Cloudron move just become dead links on those accounts; they don't block anything, and the built-in dry-run would flag it if the converter objected.
• More importantly: rehearsal mode exists exactly for your situation. The old app stays online and completely untouched. The wizard copies everything to a throwaway ESS install, runs the full conversion including a dry-run first, and then verifies the result automatically: user count, devices/sessions, password hashes, signing key. You can't log into the rehearsal copy with a client (it stays deliberately offline, since it carries your real server name on a temporary domain), but the point is that the entire conversion runs end to end on your real data. If your old OIDC weirdness would break anything, this is where it surfaces. Worst case: it fails, you've lost nothing, and you post the error here.

On a migrated install: the migration writes legacy-passwords.yaml, and render-configs.sh then renders the MAS config with passwords.enabled: true plus two schemes:

• v1: bcrypt (with the old Synapse pepper if one existed) — so every imported Synapse password hash verifies as-is
• v2: argon2id — MAS transparently re-hashes to the stronger scheme on next successful login

So a user with no OIDC link logs in with their old username/password exactly as before; nothing to reset. Users with a Cloudron OIDC link get both options (SSO button and password, if they had one). Your stale OIDC external_ids remain the only wrinkle, they become dead upstream links in MAS, but they can't lock anyone out since password auth stays enabled. The draft reply's claim stands as written.

So my suggested order:

1. Copy-paste the truly irreplaceable stuff (cheap insurance, keep that step)
2. On the fresh Ubuntu: sudo npm install -g cloudron, then cloudron login my.yourdomain.com. That's the whole CLI setup. If pop_os failed it was almost certainly an old node version; Ubuntu 26.04 ships a recent one.
3. Run the wizard in rehearsal mode (option 1 when it asks). It holds your hand through every step.
4. Check your rooms on the rehearsal target. If it's all there, do the real thing with a fresh target. If not, nothing was harmed and I'll help debug.

Nuking should stay exactly where you put it: the rage option of last resort

[humpty]

@andreasdueren Thanks for your patience on this I'll give it a shot soon!