Get the top HN stories in your inbox every day.
geokon
stinos
I hear you on the bugs, but my main problem with it is that the search just never seems to return what I need. I don't know if it's me but I usually end up searching the internet for 'best foss android <thing>' or so.
Let's see: search for ssh (with the intent of finding an ssh client, that's not too far fetched?), these are the top matches: HACS Hackspace Access Control System, KOReader Ebook reader, AVNC VNC client, FTPClient an (s)ftp client, Linux command library, MultiVNC, SshDaemon.
So that last one is the only one which effectively has SSH in the name, and then I guess that FTPClient would be something I might want to see as well, and then the VNC clients perhaps.
So maybe 'ssh client' then? Yeah no, KOReader still first, then AVNC, FTPClient, SSHDaemon, ....
Ok, I get it, search is hard, and I assume they intentionally didnt want to sort by number of downloads (?), but what it does now is close to useless.
linker3000
Have to agree that the search function is pretty dire; it only seems to work (mostly) if you already know the name of the application for which you are searching, which defeats its purpose.
berkes
Even worse if you search for terms like "git", "github", or "issues", terms that almost every app uses somewhere in their description or metadata. I would expect this to be trivial to fix. At least my experience with Algolia, Elastic, Meilisearch and even PG fulltext search make me believe it would be doable.
philipphutterer
This! And I thought I'm just too stupid to use this search, ha! Search is hard, for sure, but come on. But you actually reminded me to just use Google Dorks for that with inurl:https://f-droid.org/packages/.
urgent_skittle
Sounds very familiar. I switched to Foxy Droid, an alternative F-Droid client, years ago partly because its search functionality is miles ahead of the official F-Droid app. The popular and newer Droid-ify and Neo Store are forks of it I think, so should offer the same improvements.
Top results for 'ssh' in Foxy Droid: ConnectBot (SSH client), SshDaemon (ssh server), RSSAid (RSSHub... nothing to do with SSH), Easy SSHFS (Sshfs with ssh client), Trigger (open doors via SSH), FiSSH (SSH authentication via fingerprint), TeamBot (SSH client), SimpleSSHD (SSH server), etc.
stinos
Those results do look spot on. But I just installed Neo Store inspired by comments here, and it shows none of the apps I currently have installed through F-Droid..
hilbert42
"...It's been years since the UI update and it's always been amazingly buggy"
Being buggy is only one aspect, the other was the annoying change of UI that presents apps in rows of large, gawky icons instead of the previous efficient rows of title text each headed by a small icon (as say in Windows 'List' mode).
Unfortunately, this leaves me stuck on ancient version F-Droid 0.102.3.
When looking for an app this new large-icons mode is much less efficient, especially so if one's in a hurry and doesn't know what the icon represents (as one would expect with a new program).
I'd have thought the large-icon disease would have remained quarantined within the Microsoft and Apple worlds but unfortunately the contagion's now spread to Linux and even infected the F-Droid app on Android. It ought to be resisted on the grounds that there are so many new icons about that their once great benefit has been deprecated (text again conveying a deeper understanding).
I've no objection to those who find large icons an acceptable work framework but developers shouldn't change UIs just on a whim. If they so desire a change let them provide it as an option—i.e. a UI revamp should allow users to select the old one as an option (we've all seen this UI nonsense before with MS Windows, the F-Droid app is about the last place I'd have expected to get infected).
roytam87
if you prefer old f-droid interface, you can try foxy droid https://f-droid.org/en/packages/nya.kitsunyan.foxydroid/
hilbert42
Update. I like it, it's very similar to the old F-D v0.102.3 mentioned. Reckon I'm not alone, seems Foxy Droid's author shares similar views. Thanks. :-)
hilbert42
OK, will do. Currently trying Neo Store which has also been suggested.
mcsniff
I quite like Droid-ify as a better front end for F-Droid, I don't even bother downloading the main client anymore.
hilbert42
Thanks, I'm now inundated with F-Droid client alternatives.
When so many other clients have sprung up in response to F-Droid's painfully awkward UI one would reckon they'd rethink the change. This is yet another another instance of where developers think that they know best or where they impose their own personal preferences on users but get it completely wrong.
I note that it's not just the number of newly-available clients that have solidified my view, I was very surprised by the number of upvotes I received to my post. Seems many of us think alike.
F-Droid people please take note.
Hasnep
I recommend NeoStore [1], which is an alternative frontend for F-droid. I can't say it never crashes, but I prefer it to the F-droid app.
[1] https://www.f-droid.org/en/packages/com.machiav3lli.fdroid/
orra
From what I was reading recently, NeoStore is also the F-Droid client which supports automatic upgrades on Android 12, without root.
Hasnep
Yes, but it has the limitation that it can only automatically update apps that it installed. So if you've already installed an app through the F-droid app, you can either uninstall and reinstall an app using NeoStore or manually do the first update through NeoStore and then all subsequent updates will be automatic.
This is the reason I use NeoStore to install apps like NewPipe on my family members' phones. Before, when Newpipe broke they wouldn't know how to update it, now it just stays updated all the time.
rollcat
The lack of automatic updates/upgrades in F-Droid is what keeps putting me off. I completely understand people who want more control over when and which apps get the updates, but this is not a good policy for the general case: I trust the developers of the apps I install from F-Droid to provide me with security, stability and performance updates much more than I distrust them to pull the rug from under my feet.
I also don't think an alternative-to-the-alternative is the right solution. I didn't even know NeoStore or Aurora existed before now, and frankly I don't want to know the difference. F-Droid is already extremely niche, compared to the Play Store. It needs to play every strong card it has available at hand, rather than proliferate the fracturing.
cf100clunk
Here's NeoStore's GitHub project page:
lalopalota
Haven't used NeoStore, but Aurora Droid works well for me.
cf100clunk
I switched from Aurora Droid to NeoStore and prefer the latter's speed. Of course now that F-droid has made this change Aurora Droid may improve if/when it adapts.
aorth
Looks nice! Unfortunately they don't support repositories that use plaintext HTTP. I get the idea, but my repository is private and only accessible over my personal Tailscale network so that's annoying.
m-p-3
I'm curious to see how fast NeoStore will switch to the new format.
dugite-code
My understanding is that a lot of the bugs you'll encounter are because of androids aggressive power management features killing off background tasks with F-droid being particularly susceptible due to it being designed to work without the google play services.
glenstein
>I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues
I've used Fdroid for years, downloaded and updated apps hundreds of times across multiple devices and never encountered a single thing you described.
Death, taxes, and people confidently generalizing from one-off cases of highly unusual experiences.
>I didn't realize the app was still being worked on.
By my count there have been three new updates to F-Droid just this year that were not alpha updates, and if you use F-droid these updates show up. If you use F-Droid, I don't know how you could possibly look at your app updates and not realize that is indeed being developed unless you're in the 99th percentile of highly unusual use cases. And if you're an unusual use case you shouldn't be generalizing from it.
lucideer
> Death, taxes, and people confidently generalizing from one-off cases of highly unusual experiences.
I've used F-Droid for years and my experience matches the gp. I've read many reviews saying similar. Friends to whom I've recommended it have told me similar in person.
It seems yours is the highly unusual experience here.
glenstein
Sure, and I have friends who use it who don't report these issues, and my subjective assessment of reviews is that this isn't the predominant experience being reported, despite your protestations to the contrary. The 'data' here is miscellaneous anecdotes from an internet comment section.
But let's just observe the claim that F-droid supposedly isn't being updated. You can see that F-droid is being updated if you... look at which apps are being updated. Is looking at which apps are updated also a 'highly unusual experience' ?
pmontra
I installed an app with F-Droid yesterday. I went thought downloding, installing and came back to the app screen of F-Droid. The button was still "Install". What would normal users think, unless they already went through that many times? They would think that the installation failed and they would download the app again.
mhitza
Ah yes, the user in the free/oss ecosystem for which all software works perfectly. :)
I'm not sure if F-Droid is the buggiest app, but aside from the above 100% percent bug, had all the other issues the previous user mentioned.
glenstein
Interesting that you and gp both are not seeing Fdroid update itself. Sounds kind you must both be using a custom repository that excludes updates to the F-droid app, since you've both had that same experience.
distances
I guess you have enough answers, but I agree with the others. It's a very, very buggy app. It does the important task that it promises so we all love it despite its flaws. But if this was a commercial app, the rating would probably sit somewhere between 1 and 3 stars.
glenstein
And again, as I said to others, the idea that F-droid is not updating itself is almost self-evidently false, the issues people have reported with not being able to update apps involve some elementary conceptual errors that are being erroneously attributed to the app that have been explained by some comments here, and lastly subjective reports from people in a comment section are not a sound basis for generalization.
iopq
It's because my connection sometimes drops packets, so the download can become frozen because it never truly began
If your connection has 0% packet drop then you may never experience an issue
bunabhucan
It won't update itself from 15.6 to this new release on my phone. It keeps re downloading the files.
glenstein
Just worked for me without issue on the first try. On both my phone and my tablet.
efreak
I don't encounter all the same bugs gp does, but I do encounter several on a regular basis. These issues show up regularly on both my tablet and my phone, and they showed up regularly on my previous phone and two tablets over a range of ~5 versions of Android (8-12)
1. Every so often I turn on my tablet or phone and see a notification that fdroid has crashed, asking me to submit the information (I used to, I don't anymore). I wasn't using fdroid recently, I don't leave it open in the background; the only background task it has is fetching update lists and downloading new versions to install later. If it crashes, it loses the downloaded updates.
2. Occasionally fdroid crashes on start, providing the same notification as above. Force-stopping the app and removing the activity from recents is the only way to get past this--if I force stop and restart from recents, it crashes again. If I remove from recents and don't force stop, it crashes again. I'm guessing whatever parameters it launched with are causing the crash to happen again.
3. The background service frequently stops while updating package lists (not while downloading packages). The notification remains. This is regardless of whether the update is manual or automatic; there is no foreground update. At 11:00pm I regularly have a non-dismissable sticky notification, last updated at 5:00am, that fdroid is updating repos. Tapping it does nothing, I have to open the fdroid app, which may or may not crash on opening. If it crashes, the only way to reset the notification is to force-stop it. This is also the only way to open fdroid after such a crash (see #2). While I have no confidence that the crashing issue is fixed, it sounds like the new index is intended to prevent repo updates from taking this long. Personally, I'd prefer to just download an SQLite file directly from a server and just dump that in the app to query.
4. After downloads are complete, the download list frequently doesn't update. I can initiate the install from either the page for that specific app or from the download notification, but the main downloads list just shows that it's still downloading.
5. Not really a bug so much as missing feature: there's no way to do partial update checks. No way to check for updates to a single app without downloading the entire repo. I know there's an update available for X Y Z apps and want to update them on the bus, but because #3, 30 minutes is likely not long enough to do so. There's also no way to check a single repository for updates, and trying to bypass this by toggling that repo off and back on causes fdroid to update all repos in the order they were added. If I want to install an app from a new repo, I have to wait for all my other repos to finish updating first.
6. I have ~10 repos in fdroid. I regularly get a notification that the format is incorrect or the server couldn't be contacted or some such. It doesn't tell me what repo that is. My only option is to go through and toggle all my repos off, enable them one at a time, and
I've mostly given up. I can't get the latest update for apps from the website because fdroid doesn't make that available, I can't install updates automatically because I'm not rooted (and thus can't just trust that it'll eventually succeed in installing). I used to run my own fdroid repo for these apps; I don't anymore, because it's not worth the effort to try and get fdroid to install them.
It's not because I'm using some obscure hardware or ROM; I've had these issues with: Nexus 7 lineage, Nvidia shield lineage, Moto G6, Moto G6 lineage, Samsung A32 stock, Samsung Galaxy Tab S6 stock. Fdroid is usually the first thing I install after getting a new device or after rooting a device; I've had fdroid crash on the third time starting it on a brand new device, before I've done more than enable adb to install fdroid.
*This is _not_ a one-off case, this is an ongoing issue that I've had for years at this point*
Instead, for the few apps I actually care about keeping up to date, I use Obtainium, which checks GitHub releases (among others) instead of fdroid (it can check fdroid's website, but that's not kept up to date). As a bonus, this also allows me to keep track of apps that aren't included in fdroid (mostly Tachiyomi forks). Obtainium can't check for updates for individual apps without fetching and parsing the entire catalog, because fdroid only provides a full catalog (see #5)
glenstein
I'm just going to note that Hacker News seems to attract people in the 99th percentile of unusual use cases. And that's fine in and of itself, but there seems to be a lack of perspective that leads to people in generalizing from their unrepresentative use cases. I would be willing to bet anything that the vast majority of users are not people who have 10 repos. Do you disagree?
As for your numbered points, I would say that a occasionally experienced 1, and never experienced two, three, or four.
I've used F-Droid on a Moto G, a Moto G3, Moto Z 2 3 and 4, a Moto E, a Nexus 7, a Pixel C tablet, across numerous versions of Android and Lineage OS. I've installed and uninstalled F-Driod dozens of times and installed and uninstalled hundreds of apps over several years across somewhere between a half dozen and a dozen devices. I've probably used at most 3-4 repositories.
So, what does all of that mean? Well, nothing other than that I can't confidently generalize from a one-off anecdote. Even if I'm really really personally convinced that my anecdote is the most important anecdote to end all anecdotes.
The problem is that internet comment sections are driven by psychological forces that don't necessarily translate into data from which it's safe to draw broad generalizations.
soiler
Weird, I've never had an issue except with trying to open updates from the notifications dropdown.
geokon
I think if you live close to their servers maybe most of the issues would not be noticeable. If the app downloads and installs while you have the app page open then it seems to go smoothly. From Asia, I always get DSL speeds and need to leave the app/phone open for an extended amount of time to download even the smallest app
Out_of_Characte
Im european and the app still worked perfectly fine when my data bundle ran out and I had to finish downloading data/apps on 4kbps.
cypress66
Yes, fdroid is by an order of magnitude the buggiest app I have.
abdullahkhalids
Every few months, the app starts to crash constantly. Meaning, I open it, it crashes, then for some reason starts up again on its own, crashes again, and the cycle continues.
I usually have to restart my phone, uninstall the app, and reinstall again from scratch.
tommica
F-droid is an amazing project, and I am so glad it exists, because there are so many useful apps that people have made there that make my phone experience enjoyable.
JaggedJax
My F-Droid would not auto-update, attempting to manually get the update through the app refused to load at all, and downloading from their homepage gave me an old version. I had to download the specific version directly from their package page via a browser: https://f-droid.org/packages/org.fdroid.fdroid/
This seems to have resolved the self-auto update issue I had as well. I can now see the F-droid client page from within the F-droid client itself.
It's great to see F-droid client updates. The app can be clunky at times, but they are doing great work with maintaining the repo. I feel like a better client experience would draw in and keep more users, so every step in that direction is appreciated.
BlueGh0st
For anyone else following these steps:
Be sure to scroll down to click "Download APK" below the version that you want to download, and not the giant "DOWNLOAD F-DROID" button right above it.
This was a bit confusing on mobile before I came back and scrolled down the page some.
efreak
> downloading from their homepage gave me an old version.
This is because the FDroid website does not expose the latest version of apps. The website itself is a static Jekyll website, and I've never found any information to indicate that the app listings aren't part of that, apart from them being missing from the source repos (which they would be if it's generated from the index at runtime).
eointierney
Thank you!
F-Droid is one of those projects that adds so much peace of mind and usability to my computational life. It is a must-have.
stefan_
Just used it again today when some service asked me to use one of these generic 2FA OTP token apps. It first recommended the Microsoft one but that one literally wouldn't work unless you accept transmitting usage data, for a kind of app that is both calculator-levels of complexity and uniquely ill suited to transmitting any data. Found something simple and perfectly good working on FDroid.
Waterluvian
I’m trying to understand the JSON merge patch RFC the post refers to.
How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing?
Edit: oh, it’s in the RFC. I just missed it:
“ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explicit null values. The merge patch format is not appropriate for all JSON syntaxes.”
So it remains simple without any sort of DSL needed to describe changes like “remove this key” by somewhat hijacking ‘null’. Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.
entropicdrifter
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.
To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
Waterluvian
In some cases true. In my case, I don’t allow keys to come and go: they’re always defined. The JSON schemas validate that. But I use null to describe “there is no value for this key yet” (such as dateDeleted). If I were to implement merge patching, maybe by turning on a flag in my given framework, I’d be in for a surprise about what my null values now mean (that the schema catches immediately and never makes it to prod.)
I’m of two minds. I like how simple it is. But they’ve basically ignored a problem because the solution is complex. And so they’re hijacking a data type in a rather perilous way. Maybe they should have specified a magic string value that is treated as “DELETEME” ;)
mattashii
> and therefore the value is null
That depends on the interpreter: A good implementation of json distinguishes between defined and undefined keys in the object. Think hasattr(obj, "key") in python, or undefined != obj["key"] in js.
Waterluvian
Gosh. If “undefined” was part of JSON and it was always 100% semantically identical to “this key doesn’t exist on this object” then I could see myself not hating “undefined”. Unfortunately “undefined” in javascript isn’t even the same as “key doesn’t exist.” It’s just another null type.
Etheryte
I think the main point here is that key present with a null value and key not present are two distinct states and squashing them down into one loses that information.
entropicdrifter
Right, but my main point here is that if your business logic cares about the distinction, you've created a pointless footgun 99% of the time. If you care because you're worried about formatting issues or string corruption, there are a million better ways to check for those.
pserwylo
Congratulations team. I was involved in the project for quite some time years ago. Indeed I ported the original “Read the full index.xml into Java memory using a giant DB class” with the first “Stream entries from XML into the database, and make use of ContentProviders” because they seemed like the “Android way to do things” at the time. I also worked on the migration from XML to JSON metadata. At the time this was done, we needed to updated the metadata format to support internationalisation of metadata and the inclusion of images.
To see Torsten and others working on replacing my crufty-passed-their-use-by-date ContentProvider code with a modern Kotlin + Room implementation is heart warming. If any of you are reading this, please accept my deepest sympathies for having to pull that code out and rework it - that is not something I would have enjoyed doing! It is even better that it all lives in libraries that other clients can adopt if they choose so they don’t need to reinvent the wheel.
For those interested, yes, I am also responsible for writing the bulk of the code for the “new” (now several years old) UI in the offical client which often gets maligned on HN (and this thread is no exception). At the time I did my best to fight off edge cases and quirks of the Android system. F-Droid needs to ask Android which apps are installed and what their signatures are, then cross verify that with its own database to tell you whether updates are available. It also needs to know whether new apps have been installed outside of F-Droid since last time you opened it, etc. It also needs to pass downloaded .apk files to the system and request for them to be installed, then wait for confirmation from the system. The API’s Android provide for this kind of work, but they always seemed flakey, unwieldily, and slow to respond. The whole experience is full of race conditions, and each bistro seems to handle it ever so slightly differently.
I am still proud of how much we managed to achieve, and I’m also very pleased with the fact we were able to do so much great work around internationalised metadata, screenshots, encouraging donations to app developers, etc. But I’d be lying if I said I wasn’t still a little disappointed that I couldn’t iron out all of the kinks.
Life circumstances meant that I drifted away from the project and no longer contribute (other than via Liberapay donations to the wonderful fdroiddata team). However I would love to revisit the project in the future to see if I can address some of those edge cases to ease the user experience for all of us. You may have noticed that for such an amazing project, used by many people (not just the client, but the entire infrastructure), there has been comparatively few contributors. Despite that, I am still extremely fond of the value they bring to the Free and Open Source ecosystem.
david_allison
Thank you for everything that you've done! The Android ecosystem is uniquely hostile, and it's hard for an outsider to understand the public and private battles that you've inevitably faced over the years.
WeylandYutani
Less hostile than iOS? How does F-droid work over there?
machinawhite
More hostile than Windows for sure. F-Droid does not produce high quality hardware to go with it.
never_inline
I think GP meant development complexity.
eighthave
Hey @pserwylo, great to hear from you, and I especially appreciate your message here with the background. And I'd like to highlight your point that there is much less contributor time than people imagine. If anything, the F-Droid client UX design process back in 2016 has proven to be an immensely efficient exercise it putting together a UX that still works decently. Plus we managed to predict that bottom nav would rise in popularity and those sliding sidebars, which were recommended back in 2016, would fade.
You're of course welcome to contribute again! The hard part is that app stores are large and complicated apps, when done fully, so that makes it hard to contribute to. We do mark issues with "first-timer" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... and "help-wanted" https://gitlab.com/fdroid/fdroidclient/-/issues/?label_name%... if anyone is looking for a place to jump in. I think we can also see this in all the various other clients like G-Droid, M-Droid, Foxy, Droid-ify, NeoStore, etc. Many rapidly stop being maintained, and others leave out key functionality like localization and automatic mirror selection because it is a lot of work to implement. The new libraries should make it a lot easier for forks to implement these features.
ptx
What is (or was) the benefit of using ContentProviders compared to accessing the database directly? They seem useful for exchanging data between apps, but I can't figure out what their role is when they're internal to the app (not exported).
Is it just that they're required for using CursorLoader, so that you can easily load things in the background without having to create a custom Loader implementation? And they're basically just a fairly inconvenient database abstraction?
pserwylo
When faced with the previous system [0] - where full table scans were the norm and filtering/sorting was done in Java afterwards - we certainly could have gone to proper database queries. I think it is mostly the first thing - that we wanted to move into the background instead of full table scans on the UI thread, and indeed CursorLoaders were an agreed upon way to do that with the (then, relatively new) RecyclerView.
But yes, you are correct that they are indeed an inconvenient database abstraction.
The only thing I will say is that despite the crummy abstraction, we did put the effort in to have good test coverage of each ContentProvider. It took a while to get the infrastructure up and running so that we even could test them, but once the plumbing was added, it became simple to add new tests to ensure they worked as expected.
This is important when you need to take into account things like "Get me all the apps, but filter on category, and then also limit those Apps to ones for which they have at least one Apk which is installable on my hardware, meets my AntiFeatures requirements, and then also pull back data about whether there is a version that can be upgraded to or not based on currently installed apps. I fell in love with the SQLite explain output. I found it really good at explaining what was going on with these mildly complex joins - much easier than the MySQL explain output I was familiar with.
[0] - https://gitlab.com/fdroid/fdroidclient/-/blob/b3773a156121cf...
NovaDudely
Geez, time does fly. The last time I briefly spoke to you (FSM event) you were still working on Fdroid.
andyonthewings
I found that my fdroid has not been updated to the latest release mentioned in this post (1.16). I opened it and pulled down to refresh, but it didn't show any available updates to fdroid. I opened the fdroid info page in the app, and at the bottom I saw 1.16.1 was available but 1.15.6 (the installed version at time) was labeled “suggested”, not sure what that meant. I selected 1.16.1 and it installed and ran smoothly anyway.
pbhjpbhj
Same behaviour for me, but I chose not to install. I like to wait a while (couple of weeks at least) unless critical security bugs are indicated.
undefined
franky47
> stronger digest algorithm for repository signing: We now use SHA256 instead of SHA1 for the index signature
Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions. They provide integrity, not authenticity.
For this kind of thing (a central authority signing and public clients verifying), you'd need a public key signature scheme, like ECDSA or EdDSA.
dspillett
It isn't common to encrypt or sign the full content using asymmetric encryption.
For encryption you usually pick a large random key for symmetric encryption, encrypt the body with a strong symmetric cypher and that key, and encrypt the symmetric key with your asymmetric method and the intended recipient's public key.
For signing, you use a suitable secure hash function to produce a digest of the content, when sign the digest using your private key. Choice of digest function is as important as your choice in encryption method as an exploitable issue that allows you to generate the same digest for different content means that the signature, while secure in itself, is worthless because what has been signed is no longer effectively deterministic.
tl;dr: So when they say “digest algorithm for repository signing” they don't mean that they are using the SHA256 result as a signature, but that they use SHA256 to generate the digest that is then signed.
franky47
Both ECDSA and EdDSA hash the message internally before signing. The only advantage of signing a pre-hash, other than convenience of computation (eg: if a streaming implementation of the internal pre-hash is not available) would be to allow checking integrity without authenticity, which makes little sense.
dspillett
Perhaps they are using the hash output for quick corruption tests as well as signing for authenticity?
And if they are computing a hash for that anyway, the computation saving from signing the hash not the whole content might be worthwhile?
undefined
kapep
> Neither SHA-1 nor SHA-256 are signing constructs, they are hash functions
Well that's why they said "stronger digest algorithm". As far as I understand, the repository index is hashed (now using SHA-256 instead of SHA-1) and this hash is then signed as usual, using whatever public key signature scheme they are using.
bheadmaster
The usual process of signing a bunch of data is to hash it and then encrypt it with public key encryption, so the hash function is as important as the public key encryption scheme.
If the hash is weak, an attacker may be able to construct compromised data that hashes to the same hash, and the whole signature becomes worthless.
kseistrup
I gave up using the F-Droid app a long time ago. I tried a few alternatives and settled for Droid-ify: https://f-droid.org/en/packages/com.looker.droidify/
lenkite
Why not just use a SQLite db ? Far more size efficient than JSON.
Egoist
My Client didn't receive the update even after refreshing the repository.
I was able to get the new version by searching for F-Droid and going to the "versions" section and click update on the latest version
undefined
RicoElectrico
It shouldn't need to download the whole repo index for a mobile app store. It's a flawed assumption to begin with.
Aachen
I've got mixed feelings about that as well, but on the whole it's about even and I'm not sad that the search is local and instant. It's not that big a deal to me to download a few megabytes on top of the f-droid apk.
Then again, to download anything (including screenshots and other app info, let alone the app itself) you need a server connection so it's only mildly useful to not have to ask a server. And the search algorithm is... nonexistent I think is the most correct word to use. You get what you ask for. The top three hits for "camera" are Telegram and two identical looking SIP clients, of course. (There's not being influenced by algorithms and there's this.) I wonder if te project would accept a better algo if I'd contribute one; I've made one before at work for a not dissimilar dataset so I have some notion of what works, though it's not rocket science anyway.
jeroenhd
It's not strictly necessary, but if the entire repo can fit inside 8MiB of compressed data I can understand why they chose this rather than server-side search. That's "three clicks on Twitter" in terms of data, not exactly the end of the world, though less is always better. F-Droid's main servers are always overloaded anyway, so just sending a nice and cacheable compressed archive seems like a fine trade-off to me.
gnramires
It would be nice to use some kind of delta compression to only download latest changes. There could be a version-stamp on your local data, the client would send the timestamp to the server, and it would send a delta from your version to current version of db (easy to cache). Integrity checks would be important I think.
ptx
That's essentially what they're announcing, isn't it?
blendergeek
Offline search and metadata is a really nice feature to have. I'm glad it is present and I'm happy to see it being improved rather than abandoned.
rakoo
I don't won't to be tethered 24/7 to the internet to use my mobile phone. Data exchange isn't free, both in money and in environmental impact. That's a flawed assumption to begin with.
izacus
You're talking about an app store here though - by definition it needs to retrieve the app itself and assets related to each entry (e.g. screenshots), so it's not like you're achieving anything useful by downloading the database offline.
This isn't something like a news reader.
rakoo
It is useful to me. It allows me to search for apps while offline, and wait for non-metered data to actually download it; it's something I find myself using a lot
never_inline
On the other hand having to download all app details at once takes many MBs, not always fast. You can instead cache details of some applications.
I think homebrew moved away from repository approach too.
rakoo
I usually update repos while on wifi, then search, then use wifi again to download. I like the flexibility of not having to be connected, my phone has more than enough storage space to store a few MBs of repo database
justsomehnguy
Then you would need to check every app on the phone against some server.
Your assumption on how it works is flawed to begin with. Check the comment from one of the original authors https://news.ycombinator.com/item?id=35003844
notepalf
I believe the whole repo is also used to check available app updates
Get the top HN stories in your inbox every day.
I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100% (I managed to get past 200% the other day). If you leave FDroid in the background or lock your phone then it's almost guaranteed to not work
I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues