Nextcloud-notes: Files app is not available in F-Droid

Created on 22 Dec 2019  路  12Comments  路  Source: stefan-niedermann/nextcloud-notes

After upgrading to 2.0.1, the Notes app refuses to work if the Files app is not installed (for some reason? It makes no sense to require external apps, but whatever...). However, the Nextcloud Files app is not available on F-Droid, so those of us who do not have the Play Store installed and prefer to keep our devices as libre as possible cannot use this app anymore.

I'm stuck using 1.0.1 until this dependency/regression is fixed.

Most helpful comment

I think this discussion is taking a destructive direction. I would kindly ask you to be a little more respectful to people who spend their free time to try to develop something that satisfies many thousand users.

So: You have the option to create tickets with constructive, concrete proposals or directly cobtribute via pull requests. Noone will force you to use this free app at all. You can also stay on version 1.0.1 or even fork the app.

But please, be more polite and constructive, comments like yours are hurting and are deconstructive.

All 12 comments

Dear @EmberHeartshine,

sure it's available on F-Droid: It's simply the official main Nextcloud app: https://f-droid.org/en/packages/com.nextcloud.client/

There are several reasons, we are doing that:

  • Its way more secure, since not every app (like Notes) has to store passwords or tokens on your device. In fact the Notes app does not know any secrets beginning with version 2.0.0 and cannot leak any sensitive data therefore 馃敀
  • The network stack of the apps is now identical: No problems with self signed certificates, 2nd factor auth or any network related problems anymore 馃殌
  • Way less maintenance for Notes: We have more time to focus on the important stuff instead of reinventing the wheel the nth time 鈿★笍

The only Nextcloud app I have on my device is Notes. This is an absurd workflow I've never seen in any other app ecosystem.

Don't want to reinvent the wheel? This is reinventing the wheel. Android already has a centralized credential store in the form of the account manager. Any app in a given ecosystem can create a handler for a given account, which is then accessible by any app in the ecosystem and doesn't require you to install an app you don't use.

As much as I don't like using Google as an example (since I don't use their services anymore), they actually got it right. You don't need the Google app (or Drive, or YouTube, or...) on your phone to access a given service. Install the app of the service you need and it can initialize the account on your device. Then if you install any other Google app, it asks for access to that account via Android's account storage.

Shared credentials.

Sure, but maintaining the network stack needs much of time and is very error prone. Most bug issued were caused by self signed certificates and handling 2nd factor related stuff.

We thought much about it and went to the conclusion that most nextcloud users likely will have installed the files app, too.

Since it is free, i don't see any negatice consequences of reusing it.

You don't have to actual use it, but it makes much stuff for us way easier and leads to more time for maintaining and developing new features which are actually relevant for the notes use-case. :)

"Let's install another app on an Android device to satisfy dependency problems that haven't existed in the history of the platform" -No one, ever

We all would be very happy if you could provide some constructive ideas or code in order to improve the library we are using: https://github.com/nextcloud/Android-SingleSignOn

I don't know what you'd expect to be constructive apart from "the same thing every other multi-app ecosystem does".

I've been using OwnCloud/Nextcloud for going on a decade now (I have caldav events going back to 2010!) and I, as a non-programmer, have never once been asked to explain basic Android conventions to Android programmers. I just don't understand the thought process behind "not reinventing the wheel" when that's literally what you're doing.

What I wanted to say: This app uses the Single-Sign-On library from Nextcloud (reasons for this where shown by @stefan-niedermann). That library requires the Nextcloud files app to be installed. If you have ideas on how to fix this, open an issue on https://github.com/nextcloud/Android-SingleSignOn . That's the place, where this could be improved.

That library requires the Nextcloud files app to be installed.

Point to one other app that uses this convention and why this is a better way than what every other ecosystem does and has been proven to be equally secure.

Point to one other app that uses this convention and why this is a better way than what _every other ecosystem does_ and has been proven to be equally secure.

Why should I do that? I wrote:

If you have ideas on how to fix this, open an issue on https://github.com/nextcloud/Android-SingleSignOn . That's the place, where this could be improved.

Again: please be more constructive!

You're asking for constructive criticism on a system that is flawed by design. It's like asking what's wrong with using mayonnaise as thermal paste: nothing about it helps and everything about it hurts.

This isn't the dark ages of Linux 0.8.x dependency resolution. Compiling libraries directly into the package is the standard on Android. Why is it so difficult to do what every other developer seems to do just fine?

I think this discussion is taking a destructive direction. I would kindly ask you to be a little more respectful to people who spend their free time to try to develop something that satisfies many thousand users.

So: You have the option to create tickets with constructive, concrete proposals or directly cobtribute via pull requests. Noone will force you to use this free app at all. You can also stay on version 1.0.1 or even fork the app.

But please, be more polite and constructive, comments like yours are hurting and are deconstructive.

@EmberHeartshine I see your frustration about having to install multiple apps. And I see your point by saying that google is making it better than us since you can use their app without having to install any other app. So let me explain some differences / limitations we were facing when we tried getting a similar approach working for nextcloud.

While Google Apps can simply share a token to be able to access services such as Youtube, Drive, etc., Nextcloud apps can't. The reason behind that is, that we don't have a single API endpoint in the nextcloud world. Apart from the information about the tokens, apps also need the information about which endpoint to speak to as most users are hosting their nextcloud on their own server. Furthermore some users are using self-signed certificates or proxies that they go through. So what @stefan-niedermann already tried to explain on a very high level, our network stack needs to be able to handle many more edge cases then what google services do. And until now, every nextcloud developer had to implement this logic him-/herself. Also from a user perspective, for each app you had to re-enter all your credentials and server information over and over again which was quite frustrating..
When we tought about how we can get a more unified user experience, we were facing two options:

  • create a network library that handles all the network logic and share the account data via tokens (as google is doing it). However there are major problems with this. First of all, most nextcloud apps don't have the same signing key, thus they can't share information / tokens. Secondly apps need to know about each other. I'm not exactly sure how google is doing it on "non-google" devices but as soon as you setup your phone, there will be at least one google account created by the system. And there is already logic associated to it. At nextcloud we don't have that option which makes it quite difficult to implement something similar. If you want to read more about it, I kindly ask you to read through the open and closed tickets in the Android-SingleSignOn repo that @stefan-niedermann mentioned. There are also many issues around the Android-Authenticator API which made use not go this way..

  • Instead we decided to use the network stack of the official nextcloud files app. This way we don't rely on the buggy build-in Android Authenticator and it is way easier for third party developers to start working on apps for nextcloud. Plus we can create a way better user-experience by providing custom dialogs while selecting accounts etc. which we can't if we were relying on the official Android-Authenticator. Plus many more advantages that you can read about in the issue tracker and the readme of the Android-SingleSignOn repo. The only downside of this approach is, as you already mentioned, that you have to install the Nextcloud Files App.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

danicotillas picture danicotillas  路  7Comments

KopfKrieg picture KopfKrieg  路  6Comments

OpenWick picture OpenWick  路  4Comments

awolfman picture awolfman  路  6Comments

KopfKrieg picture KopfKrieg  路  4Comments