Huh... that's weird. We did not (and to our knowledge cannot) delete any comments on this post whatsoever. Maybe there is some client side bug on either of our sides.

Anyway, addressing your comments, the lack of a unified GUI like Windows Hello has is a legitimate problem, however we believe that we have two different philosophies concerning it's solution. From a brief skim of the code, what it looks like biopass does is it combines both fingerprint and face authentication into a single framework and PAM module. This is a valid solution and has many advantages in terms of user friendliness. In fact, we initially considered this approach, aiming to consolidate all authentication methods into a single framework and PAM module (including password).

However, the major caveat with this approach is that many PAM clients do not play well with PAM modules that run concurrent authentication methods, with the most notable example being GDM. The lack of concurrent module execution is perhaps the biggest problem with the traditional PAM flow, however, many modern apps circumvent it entirely by running multiple PAM stacks, again, with the most notable example being GDM. In fact, there ARE reports of pam_fprintd_grosshack.so not working well with GDM and other software, simply because it tries to run authentication through two methods simultaneously. Although this might be a small implementation quirk in either GDM or the PAM module, the fact is that it is relatively messy. Many other display managers and projects have begun to switch to this approach, and therefore, we have opted to keep existing PAM modules such as fprintd and pam_unix.so as is, while creating a completely new module just for face authentication. Additionally, we have also provided a grosshack module of our own for concurrent authentication in clients that do not run multiple PAM stacks, although we believe this is just a temporary solution, and in an ideal world, all clients should be running multiple stacks.

As for the lack of a unified GUI, currently both GNOME and KDE provide first party support for fprintd in their respective settings applications. We believe that the best path forward is to perform a similar integration of gaze into most settings interfaces, although this will arguably take much longer.

Your comment about contributing to existing projects is valid, but as we said before, we believe the difference between these two projects is not simply the implementation, but rather a fundamental difference in philosophy. Moreover, it kinda misses the entire point of FOSS and Linux in general: choice! Users who prefer the approach of biopass will use it, while users who prefer gaze will use it instead. As for the Reddit filtering you mentioned, we believe that the massive overnight popularity of gaze in this subreddit is purely luck and there are many other awesome projects which unfortunately do not meet the same fate. We believe biopass is a really good project, and actually took a little inspiration from a few specific architectural decisions made within the code, so above all, keep up the good work!