Oddbean new post about login | logout We are going to start transitioning filter.nostr.wine to require NIP-42 AUTH soon. If your client still doesn’t support AUTH - please encourage the developers to add it!
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.
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.
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.
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 nostr:note1aej3d6n9twm7y8vgvq8dq5aahhy0wkc900xpdh8n8a7rsxm0msdspyrf85
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.
ok so why the extraneous prefix string then, surely it's fine to just add it to the filter keys? you could even add just one, and make them tags then
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 https://docs.nostr.wine/api/classification from within the relay. It’s not documented intentionally as it’s subject to change.
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.
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 nostr:note1aej3d6n9twm7y8vgvq8dq5aahhy0wkc900xpdh8n8a7rsxm0msdspyrf85
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 https://docs.nostr.wine/api/classification from within the relay. It’s not documented intentionally as it’s subject to change.
so you don't have to search for the events you search for the classifications! you make them and publish them to the database i remember when nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq0npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qwsscer introduced me to the filter system of strfry and i realised that the event motif has uses outside the events that are sent between client and relay, they can be relay internal only, they can be meta-events, as nostr:nprofile1qyf8wumn8ghj7u3wd4kx26m49ejx2a30qyghwumn8ghj7mn0wd68ytnhd9hx2tcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qpq80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsgqvarw is talking about yes, this is a better solution, more scalable and more interoperable
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.
I think that is the correct flow, yes. Let's summon @hodlbod But you don't have to store anything, you can generate these events on the fly upon seeing a REQ. I am now thinking that another option we have is to specify these extra meta things on NIP-50. Like the search string could have a "category:nsfw" segment and then the relay interprets that in any way it wants.
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.
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.
also i hate the whole concept and terminology of DVMs there is no insert coin, it's not a vending machine i've seen several things in my time working as a nostr dev that tell me that relay data stores have almost infinite potential and flexibility if you have the imagination
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 :(
i was never unclear that i meant FILTER tags, you just didn't catch it that's something you can easily add to a random new NIP that augments NIP-1 the internal tagging system is internal, it's irrelevant, except that it relates to the clients requesting it, so it's FILTER tags not EVENT tags
I think that is the correct flow, yes. Let's summon @hodlbod But you don't have to store anything, you can generate these events on the fly upon seeing a REQ. I am now thinking that another option we have is to specify these extra meta things on NIP-50. Like the search string could have a "category:nsfw" segment and then the relay interprets that in any way it wants.
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.
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?
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?