Following the topic of FHE for quite some time and I am always hoping that we get some breakthroughs regarding speed. Seeing how this can be applied to CRDTs another awesome topic, is really cool, even if it still more theory than practice :-D

yes, it is an android version of birdNET as stated on the github page https://github.com/woheller69/whoBIRD

Loving these kind of apps :-) I personally use WhoBird, which runs complete local on your android device, so it works also when you don't have internet and is available on fdroid (https://f-droid.org/packages/org.woheller69.whobird/). Will give merlin a shot as well to see how it compares

Merlin also works offline. I use it all the time out in the mountains.

AFAIK WhoBird uses the same model (or at least, also developed by Cornell), but for me, Merlin is still better at identifying multiple birds at once.

whoBird is only working with audio (and not photos) though

yeah seems like at least for many that is the case. I wasn't aware that so many engines are using bing! under the hood. Afaik qwant uses their own thing and that startpage is using google under the hood, but that might have changed

Mhm tested in ff and chrome and it works fine in my site. Does it mean that the filters do not at all on your site? What setup are you using? Ty for the feedback :-)

uh ty that's a pity - will fix it

FYI: code in github, see https://github.com/GRBurst/hnjobs

Seems like wbaltv.com has some geo restrictions... "Sorry, this content is not available in your region."

So during migration both schemas are valid if I understood correctly?! It would be awesome if "during migration" could be lifted to a point where it is possible to keep both schemas (old and new) for as long as I want and do migrations/transformation of incoming request (like queries) on the fly. Then I could map my different api version to different schemas and these on the fly transformation would be able to take care of the rest in many scenarios :-)

This is actually the case, old and new schemas are available and working until you complete the migration, and you can run this step whenever you want.

The aim is not to deal with conditional logic in the app dealing with both schemas, but having an old version of the app linked to the old schema and the new one using the other.

so if I want to sunset my api version X in 1 year for whatever reason and I am able to support an old schema X, which api X maps to, for that time period without any hassle (and not only during migration), this would be a much bigger feature / USP for me then everything else mentioned. I am really curious to look deeper into this :-)

I had the same thought; eager to see if anyone can explain why this wouldn't work, or (better) how they're already doing this today.

For those use-cases I use entr (https://github.com/clibs/entr). In what sense does watchman differ to it? Didn't see anything related to this at first glance :-)

The page linked above says:

> WARNING: This is a (possibly outdated and/or unmaintained) fork of https://github.com/eradman/entr .

OP did say he did this for learning purpose.