A: Shortly to say, web link is tested by local "hash" file.
1) In server, there is a crawler to watch Hack News API item changes. When pop a new story, it will be built into bloom filter, whose hash algorithm find here , where
"number of hash functions" is 8 The above factors make sure the probability of false positive is low enough. Then the bloom filter size should be (distinct link count) * 2 Byte, which is small enough for current hacker news total count (~2M), then package into a local app should be works, size should be ~4MB.
"number of bits to allocate" is 16 * (link count)
2) The bloom filter data will be incrementally sync into client (the browser extension), you can also manually sync by click .
3) When end users open a link in browser(current only chrome), the extension will format the link address, and tested by bloom filter.
4) If test result is positive, extension will continue to start a HTTP call to find the link score. The score will be shown in extension badge.
5) If user popup the extension, extension will continue to load hacker news items detail.
Basically, there is an assumption that hacker news links should be very small part of the total visiting links.
Comparing the other naive method - check in server side for every visting link, the above method will make network communication less, calcuate much more fast. Actually, you will find the extension change the badge color very quickly (should always faster than the page loading), which give you a choice to know what HN are talking about the coming page.