no more draft! no more optional!

Yup - it’s time. We launched optional support for NIP-42 in March of last year. I think it’s been long enough.

No idea if the clients I use support it! I'll have to check. Might be time to switch if they don't.

Along with Amethyst, Damus (TestFlight), Snort/Iris, Gossip, and I’m sure many others. Adoption has picked up a bit on both the client and relay side.

Well we won’t force anyone to migrate, but it won’t be useful anymore for anyone and we’ll encourage them to migrate. We’ve supported connecting at root for a while but it of course requires AUTH. Do you know if any NIPs exist for making a REQ for events of a specific topic or other classification? I just rolled out initial (undocumented) support for a “topic”, “sentiment”, “language” and “nsfw” REQ filters on filter.nostr.wine using our new classifier.

How can it be apart of tags if we are classifying events after they are created? I’m adding it because I want it and so do some of our users.

If I'm getting this right I don't think NIPs would be useful. I've actually always thought we could just use manually specified URL paths for this kind of arbitrary filtering. But there was also a proposal for algorithms in REQ filters which might be a good idea to revisit at some point. On the other hand many people who are interested in this kind of stuff have migrated to using DVMs instead of relay-based commands. I don't know anything, I would have to get a more concrete picture of how this works in the UI to have a better opinion.

I don’t really understand what you’re suggesting. Do you want to provide an example? As a general philosophy - I have very little interest in debating over standards and ultimately just want to adopt whatever wins out in clients. Our main long term goal continues to be interoperability as a relay provider. For now I wanted a way to access results similar to this API

Classification | nostr.wine

Documentation for nostr event classification (not currently classifying new events)

from within the relay. It’s not documented intentionally as it’s subject to change.

Hmmm, I see. I will say this is adding a few more steps and round trips for centralized classification. Instead of just adding a few labels in my database and filtering on them I now need to create and store a new event per classification. Effectively doubling my storage requirements on kind 1 notes (that’s all we are classifying for now). Then clients would query first for 1985s with a certain tag (like topic) and then for the e tagged events in each 1985? Is that the correct flow?

I actually think a DVM might make more sense than that for us with strictly the goal being interoperability with clients. But, DVMs are just REQs with extra steps for this particular use case. It’s still a centralized classification no matter how many intermediaries I add.

Yeah this conversation has gotten to be way too complicated. We are all talking about different things. I fixed the nostr.wine issue try now. Apparently I broke one mirror during a restart earlier today :(

Thanks for the heads up.

My understanding of NIP-01 is that filter tags are meant to relate directly to event tags - that’s why there is confusion.

Thank you, really appreciate that! It’s all still new and whacky but it’s been fun to tinker with. There’s so much to build still.

Yes, I could generate them on the fly but for large limits that could be pretty slow at scale without some caching. I think extending NIP-50 for this would make sense. I know there are a lot of strong feelings about that NIP already so perhaps a refining of it could expand the flexibility and options.

My use case is to offer our proprietary classifications to subscribers of filter.nostr.wine. It’s expensive to run our classifier. What’s do we accomplish by adding DVMs or other middle men? I asked previously if anyone would be interested in funding an open classification action initiative but there didn’t seem to be much interest. For now I’m moving forward with the self funded proprietary version so I can start improving the data.

I think DVMs are generally only useful if they aren’t run by relay operators and either aggregate results from multiple relays or fulfill a job outside of a web socket. Nostr.wine running a search DVMs, for example, instead of using NIP-50 when search is inherently centralized anyway is just adding extra steps without obvious gain. This feels similar to that but I could be way off?

I think the best way to decentralize this would be NIP-32 labels by several classification providers across several relays. Perhaps a DVM could help aggregate these for quicker responses. I am not sure, however, how we find people to run classification models and provide those labels publicly for free.

Ok last post I’ll bring it full circle, sorry for all the spam. I’d consider this separate to the current implementation but.. I could make a DVM that accepts event(s) as input and charges for their classification. The paid classification could get published widely via a NIP-32 event. Then we slowly build an open classification database paid for by users? Does that make any sense?

The problem with pushing custom REQ filters to the DVM marketplace is that relays will become obsolete. Once this feature is mature, and nostr adoption grows, user customizable content feeds will be what sets nostr apart and keeps REAL user content visible. Because the threat model from bots and bad actors will be always changing, end users will want to stay on top with the BEST content filters. They will benefit from sharing filters with each other, independent of the client used. If this functionality (to share prepackaged filters) is only available through DVMs, then nostr event traffic will gradually flow more amen more through these DVMs. In addition, NIP90 for DVMs specifies an event to be published for EVERY request AND response. I kinda think this is overkill for the task at hand. Just single event to publish the “filtering service offered” by a relay and another event to “subscribe” to that filter. This is the NIP needed. IMHO

I never suggested pushing custom REQs to DVMs. I don't think DVMs should be relied upon for core features of the protocol.