Oddbean new post about login | logout I am asking once again for the clients to utilize moderation headers that we publish with every media upload to nostr.build! Now it is just mostly wasted effort and useless to the users. 😭😭😭 https://i.nostr.build/0UtYT3uVP6UBRavs.png
Did any clients ask for this?
Yes, and we had it already so was easy to add. Damus mainly
I think supporting custom stuff for nostr.build doesnt make sense for any client. The same goes for any other image host
How can they be utilized?
Anyway you want. Want to allow user to hide content if it is below certain safety margin, can do. Want to have a warning before the image is revealed, do it. Damus now blurs images and video from accounts that you don’t follow, it could show the ones that are moderated as safe. You have the info, you do whatever you want with it.
Nice! But is this a NIP? No one likes to code things that only work in specific vendors.
There is no NIPs for http requests, afaik. I can create one but will it fly? 🤔
Who knows. I didn't even know these existed. Your appeal to get clients to do it goes much further when there is documentation for it in a common place. Even if it is just a pr.
Makes sense. Not sure how to NIP it though, maybe a common NIP for HTTP headers with some predefined prefix? I am open to suggestions
@fiatjaf do you have suggestions about this?
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. @mplorentz @rabble
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. https://github.com/atrifat/nostr-filter-relay/issues/18
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
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.
I’ll propose a PR to add trusted npub in the nip96 JSON. Probably a list of them, to allow rotation, etc
@The Fishcake🐶🐾 You can take a look at kind 1984s published by @Tagr-bot 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.
Maybe an optional add-on to NIP96?
These are added asynchronously, so cannot return them during upload, but if that’s ok to specify as a header returned when URL is served, then maybe OK. It should probably be optional too.
123
456
