3 ms·

I'm developing such an app. I'm excited to get to the network connectivity part so I can see how much I've saved by making the client smart. I think I'm going

I'm developing such an app. I'm excited to get to the network connectivity part so I can see how much I've saved by making the client smart. I think I'm going to be able to get away with just running the server for 36 minutes a day (three minutes every hour). The client will know to sync data during those time windows. 1hr of latency is fine for a lot of things if the client is smart about what it caches.

triyambakam 4y ago
What is the app?
- __MatrixMan__ 4y ago
  It's a protocol for crowd sourced annotation data. So an example app that uses it would go something like this: Suppose you have a food allergy, and you have a reaction to something in a restaurant. You want to leave a note on that menu item "contains allergen XYZ" but you don't want to write on that menu, you want to annotate all such menus. You'd take a picture, OCR happens, some algorithm thinks about line wrapping and renders it as a list of strings, and then a rolling hash identifies the "features" among those strings (any substring hashes to a 16-bit integer, the ones where the first 8 bits are off count as features). Then you "paint" the menu entry in the color "contains allergen XYZ". The features that are nearby your "brushstroke" (i.e. text highlighting) are stored in a table for that "color" which is eventually synced with other users. Later, someone else who subscribes to that "color" and has a trust relationship with the first user can scan the menu, follow the same process to find the features, which are used as indices to look up the brushstroke. Then they're able to see the annotation left by the other user as an overlay on the image they queried with: supposing they have the same allergen, they now know to avoid that item. I'm calling the whole scheme Semantic Paint and the index-friendly-feature-finder Gnize (like cognize now, recognize later). It's meant for local-ish use by small-ish communities, so the data you actually have to store on your device is pretty small and restricted to colors that you've chosen and other users you've explicitly (or transitively) trusted . And you're communicating over spans like weeks or months, so it's not a big deal if it takes a few days for one brushstroke to make it to another user's device. It's not like they notice its untimely arrival, it just goes in a feature database for later query. I also thing it might have applications in genomics/proteomics, e.g. annotate a gene.
  - triyambakam 4y ago
    Wow, fascinating. Thank you for detailing that. Do you have somewhere to follow its development?
    - __MatrixMan__ 4y ago
      I'm tickled to that you're interested. "I have this cool idea involving algorithms on strings" isn't exactly everybody's favorite conversation. Here's the old version, hardly even proves the concept: https://github.com/MatrixManAtYrService/gnize https://github.com/MatrixManAtYrService/gnize Python was giving me trouble though, so I'm switching to Nim for performance reasons, and also because I can compile it to C, objective-C, and JavaScript for use by a wider variety of clients. It's just an empty shell right now but that project will end up here: https://github.com/gnize https://github.com/gnize and hopefully soon.
      - triyambakam 4y ago
        > "I have this cool idea involving algorithms on strings" isn't exactly everybody's favorite conversation. Haha yeah I get you. I wouldn't have expected it would be for me either but the approach and use case you shared is really cool. Thanks for the links. It will be neat to see the development in Nim, as well.
        cb321 4y ago
        You both might be interested in this little Nim program "framed" to frame & digest text for near-duplicate detection: https://github.com/c-blake/ndup/blob/main/framed.nim which does a rolling hash with the late Bog Uzgalis' Buz Hash which is (IMO) about 10x simpler than Rabin fingerprinting. It's really just xor out old, xor in new. In my context of near duplicate detection I worry about false negatives as well as false positives and displaying near-bys to the user & such. So, things are set up for random seeds for very independent framings & digests (to avoid unlucky ones). { This is very different from the more common "backup/rsync/transfer" context of "content-based slicing" aka "content-defined chunking". }

triyambakam 4y ago

What is the app?

__MatrixMan__ 4y ago
It's a protocol for crowd sourced annotation data. So an example app that uses it would go something like this: Suppose you have a food allergy, and you have a reaction to something in a restaurant. You want to leave a note on that menu item "contains allergen XYZ" but you don't want to write on that menu, you want to annotate all such menus. You'd take a picture, OCR happens, some algorithm thinks about line wrapping and renders it as a list of strings, and then a rolling hash identifies the "features" among those strings (any substring hashes to a 16-bit integer, the ones where the first 8 bits are off count as features). Then you "paint" the menu entry in the color "contains allergen XYZ". The features that are nearby your "brushstroke" (i.e. text highlighting) are stored in a table for that "color" which is eventually synced with other users. Later, someone else who subscribes to that "color" and has a trust relationship with the first user can scan the menu, follow the same process to find the features, which are used as indices to look up the brushstroke. Then they're able to see the annotation left by the other user as an overlay on the image they queried with: supposing they have the same allergen, they now know to avoid that item. I'm calling the whole scheme Semantic Paint and the index-friendly-feature-finder Gnize (like cognize now, recognize later). It's meant for local-ish use by small-ish communities, so the data you actually have to store on your device is pretty small and restricted to colors that you've chosen and other users you've explicitly (or transitively) trusted . And you're communicating over spans like weeks or months, so it's not a big deal if it takes a few days for one brushstroke to make it to another user's device. It's not like they notice its untimely arrival, it just goes in a feature database for later query. I also thing it might have applications in genomics/proteomics, e.g. annotate a gene.
- triyambakam 4y ago
  Wow, fascinating. Thank you for detailing that. Do you have somewhere to follow its development?
  - __MatrixMan__ 4y ago
    I'm tickled to that you're interested. "I have this cool idea involving algorithms on strings" isn't exactly everybody's favorite conversation. Here's the old version, hardly even proves the concept: https://github.com/MatrixManAtYrService/gnize https://github.com/MatrixManAtYrService/gnize Python was giving me trouble though, so I'm switching to Nim for performance reasons, and also because I can compile it to C, objective-C, and JavaScript for use by a wider variety of clients. It's just an empty shell right now but that project will end up here: https://github.com/gnize https://github.com/gnize and hopefully soon.
    - triyambakam 4y ago
      > "I have this cool idea involving algorithms on strings" isn't exactly everybody's favorite conversation. Haha yeah I get you. I wouldn't have expected it would be for me either but the approach and use case you shared is really cool. Thanks for the links. It will be neat to see the development in Nim, as well.
      - cb321 4y ago
        You both might be interested in this little Nim program "framed" to frame & digest text for near-duplicate detection: https://github.com/c-blake/ndup/blob/main/framed.nim which does a rolling hash with the late Bog Uzgalis' Buz Hash which is (IMO) about 10x simpler than Rabin fingerprinting. It's really just xor out old, xor in new. In my context of near duplicate detection I worry about false negatives as well as false positives and displaying near-bys to the user & such. So, things are set up for random seeds for very independent framings & digests (to avoid unlucky ones). { This is very different from the more common "backup/rsync/transfer" context of "content-based slicing" aka "content-defined chunking". }