I still have not tried logseq, but I am impressed, it looks real promising. Congratulations and thank you for such a useful software.
I would like to request an effort to respect average users who stick to Software Freedom and are not able to easily compile the code. The only option they see now is to download and execute a binary (not even signed) from the website, so they reject it because it generates a distrust very similar to that of proprietary software.
It would be nice if logseq was available on the official repositories of GNU/Linux distributions (we normally trust package maintainers of our communities). It would be useful for updates too.
It would be nice if software on the website was OpenPGP-signed (especially by someone we could know or trust, or has signatures from someone we could trust). Or at least its checksum.
It would be nice if there were an easy step-by-step guide on how to compile the software from source code.
However, that’s only the third option in preference (sorry, didn’t mention preference in my previous post) and I think they don’t look easy to follow for an average user, they look like instructions for developers.
Granted, in my use case NixOS we have a repackage of the AppImage distribution, but with such complex software a build script is really demanding, still needs Electron 25, but that’s what we have nowadays.
But they publish the checksums, don’t they? See the latest GitHub release with SHA256SUMS.txt
Validating signatures are a hard problem, as all development is centralized on GitHub, I don’t see a problem in trusting the releases published through it. Could be better? Don’t know, even Debian and Linux have problems with mananing trust.
Logseq is already available on FlatHub. Notice that while in the past Linux distros packaged everything, from libraries to applications, today there are too many apps to package, that’s why we have Flatpak. Logseq being available as Flatpak is exactly how things should be and Linux distros should focus on libraries, system stuff like desktop environments and core applications.
That said, the Logseq team should point to FlatHub as default installation method for Linux, instead of AppImage.
Unfortunately Logseq is not in the verified_floss Flathub subset. It is only in the floss subset, because it was not “published on Flathub by its original developer or a third party approved by the developer”
pei@compu:~$ flatpak remote-add --if-not-exists --subset=verified_floss flathub https://flathub.org/repo/flathub.flatpakrepo
pei@compu:~$ flatpak remotes
Name Options
flathub system
flathub user
pei@compu:~$ flatpak search logseq
Name Description Application ID Version Branch Remotes
Logseq A local-first, non-linear, outliner notebook for organizing and sharing your personal knowledge base com.logseq.Logseq 0.10.3 stable flathub
pei@compu:~$ flatpak install flathub com.logseq.Logseq
Looking for matches…
Remote ‘flathub’ found in multiple installations:
1) system
2) user
Which do you want to use (0 to abort)? [0-2]: 1
error: Nothing matches com.logseq.Logseq in remote flathub
pei@compu:~$ flatpak install flathub com.logseq.Logseq
Looking for matches…
Remote ‘flathub’ found in multiple installations:
1) system
2) user
Which do you want to use (0 to abort)? [0-2]: 2
error: Nothing matches com.logseq.Logseq in remote flathub
pei@compu:~$
About FlatHub, I mentioned it many times on Discord that they should adhere to FlatHub’s verification program, but they have other priorities.
About F-droid, same, but recently when I pointed out they need to publish the client-side code of Sync to be added to F-droid, a dev quickly published the needed source code. But Logseq is still a complex app to package and F-droid has some strict requirements when building (F-droid rebuild from source code everything). So let’s wait until some experienced F-droid contributors figure this out.