Nostr Web Client

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

Rif'at Ahdi R 1y ago 💬 1

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.

https://github.com/atrifat/nostr-filter-relay/issues/18

Reply to this note

Please Login to reply.

Discussion

The Fishcake (nostr.build) 1y ago 💬 1

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.

fiatjaf 1y ago 💬 1

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!

The Fishcake (nostr.build) 1y ago 💬 1

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

fiatjaf 1y ago 💬 1

Publish it with a key owned by the nostr.build service specifically for these matters and tell clients what that key is so they can trust it.

The Fishcake (nostr.build) 1y ago

I’ll propose a PR to add trusted npub in the nip96 JSON. Probably a list of them, to allow rotation, etc