Is there some kind of public/reference-able version compatibility matrix between /e/ OS and Nextcloud? So far I’ve been having my phone talk with my own self-hosted Nextcloud (to sync calendar+contacts+notes) and it’s been working great (/e/ OS 3.2 on a FP4 connected w/Nextcloud v31 stable running from community docker image), but I figure at some point they’ll fall out of API compatibility and things will break. I am running upstream/actual Nextcloud, not this fork. I’d guess the webdav / webcal stuff is pretty stable (in the senses of both not changing and few bugs), but still, I just want to do a little research and be prepared.
No formal announcement has been made that it’s officially being discontinued…but it’s up to you if you want to be like me and remain committed to the platform that’s still on v26, which is several revisions out of date. I love self-hosted my /e/Cloud server, but it’s up to you how you define “supported”, because my assessment is that it’s in a bit of a grey area at the moment.
For folks connecting with other Nextcloud instances/installs, what versions are known to work?
I’ll let others chime in if there is more formal experience, but I would submit that the way to maintain the highest level of compatibility, is to remain lockstep with the version of Nextcloud that Manoj lists in the weekly updates.
What might we do to ensure our /e/ OS phones continue to work with our Nextclouds?
I’m open to a better answer to this question as well, but I think it is going to vary a bit regarding how one defines “work”…I think that Nextcloud has enough first-party apps to get your PIM data synced reliably independent of the OS (how would you do it on a Pixel?), but OS integration might have a better answer.
Yes, it is supported by /e/OS. And yes, it is a few versions behind because the development team has not started work on it. Will share the feedback with the team and get back with their response.
I wouldn’t worry about APIs (only Notes uses one) or protocols (decade old standards) - this is pretty stable in both Android and server side.
The challenge I see in /e/OS is how the move to SSO will be integrated into the davx/k9 forks, if you can generally opt out client side and do regular auth or just put SSO into your own mix or the selfhost package. For the latter openid/oauth2 endpoints would need to be a user config, not hardcoded. Maybe takes a few iterations to be selfhost friendly after introduction, let’s see. To take away worry here: using the “regular” davx webdav account type is probably an opt out to any new auth flows that murena integrates.
You can follow along in /e/s gitlab for that SSO work, it makes lots of sense to do it but isn’t easy work.
