Thanks @gael. So this is almost the same software as runs in ecloud.global, but when running is completely separate and unrelated to ecloud.global? No /e/ account is needed to run the self-hosted version at all?
This makes me think about what Mozilla are doing with their IoT project WebThings Gateway. They produce an image which will run on a raspberry pi and as part of the initial set-up the user can create a domain at *.mozilla-iot.org. The RPi tunnels to a Mozilla server which only hosts the IP address for this domain; all traffic is tunnelled back to the RPi. This approach removes the hassle from the end user of having to register a domain name, get a static IP address from their ISP, configure their router, etc. If someone wants to run the Webthings Gateway without using the mozilla-iot.org domain name then they can reconfigure the RPi to do this.
In a later phase, would /e/ consider doing this? For example you could allow people to create domains *.ecloud.global (for example), provide the IP address and tunnel but running the server would be the user’s responsibility. The /e/ account could still be used for logging into both ecloud.global and the self-hosted version, with no need to mess around with different accounts on the smartphone. I can see how this might complicate the process of providing services for this account in ecloud.global, but maybe instead of providing the full service you can provide an encrypted cloud backup service for key data which the user consider wants to keep available if their server crashes. Maybe the data could be encrypted with a private key which only the user should know, this would help reassure people that /e/ aren’t spying. The initial setup process for the self-hosted server could ask if there is a backup in ecloud.global that the user wants to restore. Or even without a cloud backup the initial set up could ask the user if they want to download all the data from the ecloud.global servers which currently exists for that account, so that the self-hosted server can take over from the cloud server more easily (otherwise transporting data between the two could be messy, especially emails).
Please excuse the brain dump; once I started typing I could foresee lots of possibilities!