You could publish the results of your classifications as NIP-32 labels tagging the image hashes directly and let clients subscribe to those.
I think nos.social is doing something similar, so we almost have a protocol already. nostr:npub16zsllwrkrwt5emz2805vhjewj6nsjrw0ge0latyrn2jv5gxf5k0q5l92l7 nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240
Oh nice! I’ll take a look! Thank you! 🙏🏻
There are examples of NIP-32 implementation that were used and published in nfrelay.app . It has been discussed with nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs . Maybe, can be used as some references.
One issue is that it is all about publishing something to the relay, and have it disassociated from the media. It’s much simpler if the info is in the header (HTTP) so any client can use it at any time.
If you have the file hash and the labels that reference a file hash then you can opt to not even download the media beforehand. Saves bandwidth for everybody!
Good point. It’s just how to publish the info once we have it. Who signs the event. Which key should the client trust for this info. It is not generated synchronously, and HTTP has a HEAD method that is cheaper than relay queries
nostr:npub137c5pd8gmhhe0njtsgwjgunc5xjr2vmzvglkgqs5sjeh972gqqxqjak37w You can take a look at kind 1984s published by nostr:npub12m2t8433p7kmw22t0uzp426xn30lezv3kxcmxvvcrwt2y3hk4ejsvre68j to get an idea of what we are doing. They should all be published to relay.nos.social.
The main downside of doing it this way is that the client has to search for labels referencing content and that gets complicated. Like do you wait to display the content until you are sure there aren’t any labels? How can you be sure there aren’t any? But in practice it has been working pretty well.
