suggest VS lldap

You are welcome. Thanks are too rarely offered. :-)

You may also be interested in word stemming ( such as used by snowball stemmer in https://github.com/c-blake/nimsearch ) or other NLP techniques, but I don't know how internationalized/multi-lingual that stuff is, but conceptually you might want "series of stemmed words" to be the content fragments of interest.

Similarity scores have many applications. Weights on graph of cancelled downloads ranked by size might be one. :)

Of course, for your specific "truncation" problem, you might also be able to just do an edit distance against the much smaller filenames and compare data prefixes in files or use a SHA256 of a content-based first slice. ( There are edit distance algos in Nim in https://github.com/c-blake/cligen/blob/master/cligen/textUt.... as well as in https://github.com/c-blake/suggest ).

Or, you could do a little program like ndup/sh/ndup to create a "mirrored file tree" of such content-based slices then you could use any true duplicate-file finder (like https://github.com/c-blake/bu/blob/main/dups.nim) on the little signature system to identify duplicates and go from path suffixes in those clusters back to the main filesystem. Of course, a single KV store within one or two files would be more efficient than thousands of tiny files. There are many possibilities.

As jamra correctly points out, the entry point to this (which gets a lot of traction on HN) is indeed attacking a strawman tutorial-written-on-an-airplane algorithm. So, the 1M speed-up is majorly over-hyped.

That said, the technique is not wholly without merit, but does carry certain "risk-reward" trade offs related to latency in the memory/storage system because of SymSpell's reliance upon large hash tables. For details see https://github.com/c-blake/suggest

Good to hear, I think it'll make many users happy. For me, I've migrated back to Authelia. I moved to authentik because at the time Authelia had no user management. After all of authentik's sharp edges, I've found lldap[0], and was able to implement a pilot in a few hours. I haven't looked back, since everything was converted.

[0]: https://github.com/lldap/lldap

I wrote LLDAP (https://github.com/lldap/lldap) after struggling to install and configure openLdap on my homelab.

I've recently installed and configured LLDAP (Lightweight LDAP) - More details here if you've never heard of it before: GitHub - lldap/lldap: Light LDAP implementation

I've an LLDAP instance running to make managing users easier.

I'm trying to integrate LDAP into my small homelab but I'm extreme noobie in it. So far I've tried: 1. OpenLDAP - not so resource heavy but I found it difficult go get working correctly with NextCloud, Keycloak and Jellyfin. Maybe someone could recommend an easy to follow guide? 2. LLDAP - honestly it's almost prefect. Nice clean UI, great guides how to setup with everything I need, but it's a read-only LDAP, so I cannot create or manage users with Keycloak or NC, that's about the only downside and probably bugs me more than it should. 3. 389ds - has everything I need (and probably some more), super easy to setup with this guide but the elephant in the room is that it uses 700MiB of RAM (whereas LLDAP uses only 7-8MiB). That's a big difference which really makes me question whether I want to use this particular solution.

Note that if you want to use KeyCloak for the OpenID but want to still have a LDAP source of truth, you can use LLDAP + KeyCloak together, with LLDAP as the source of truth and KeyCloak giving you the fancy features: https://github.com/lldap/lldap/blob/main/example_configs/key...

To be fair, their respective documentations (here and here) are pretty comprehensive.