especially would want your opinions: @The Daniel 🖖 @Karnage @hzrd149 @Yonle @𝚁𝚢𝚊𝚗 🏴‍☠️🎶 @雪猫 @Laeserin @npub10npj...tl5h

I don't like how relays are free. They should all be paid relays.

I don't like how we have to fetch users nip 65 list of relays just to attempt to connect to ded relays

cute. 😂

pain points? cost of compute being infinitely inflated by advertising revenue models and LLMs.. to get nostr to a price point that makes any sense requires being really scrappy with your burn rate, cost, and software efficiency. search is insanely computationally expensive.

Discovery is usually hit or miss. It’s nearly impossible to find anything by semantic search, especially a post by a specific user within a specific time frame. And nothing says broken like nearly zero search results for topics that are trending across the internet.

I like how this community isn't contains Twitter idiots, This isn't commercial project, just keep it as it is.

I believe search is important, but Nostr is weak in search capabilities. We have more historical data than current data. 1. Keyword Search 1-1. Keyword Search within Nostr I think we need more relays that support NIP-50. We had relied too heavily on wss://relay.nostr.band/ . I also feel that the inconsistent implementation of queries is complicated. Of course, I understand that implementing search is so difficult... 1-2. Keyword Search for SEO To increase users, we need traffic from search engines. However, search engines do not interpret WebSockets, and distributed data is perceived as duplicates. 2. Find Relays I'm looking for search relays and default (starter) relays, but I feel it is difficult to find. This is because I don't know the status of the relays. For example, are they publicly available, or can I integrate them into my client? 3. Monetizing Relays I'm also concerned about the difficulty of monetizing relays.

thanks to the relay developed by opensats, anyone can execute one without much effort, achieving decentralization in the control of publications. although I would say that when it comes to servers for media files, if more work is needed, the IPFS network can help anyone run their own nodes without having to do all the work that normally involves just exposing a server.

handling the amount of concurrent queries

The data is spread over so many relays and querying them all, individually, takes so long and half time out. Trying to find anything is a total PITA because there are no combinatorial filters. I have to fetch a bunch of events and sift through them, client-side, with SQL. Which means my apps all cache like crazy. That deletion happens too slowly. They almost all delete, now, but they must be using cronjobs, or something. That they don't regularly poll other relays for newer versions of addressable events, so that my profile pages through versions, when I refresh. That they don't handle all uppercase and lowercase-letter filters and instead throw errors. No full-text search, on most of them.

Also, just, their machines are too limp. People only want to use surplus compute and I can practically hear the gears turning, even when the filter is something standard and common, like kind:pubkey:d-tag. And their shit goes down — and stays down — or rate-limits, even if you just send one req per second. Or it returns frantic TOO MANY REQS messages.

Second the SEO. Search engines and AI chats and sitemaps are the main ways anything gets found, on the Internet. Even if I know a note exists, I can't Google to find it. That's why we're working to get away from websockets with stuff like #decentnewsroom. But a relay could also host an SSR website, where you could see full threads. Then outsiders could stumble across it and lurk.

DN has the main content SSR and the threads from relays, which is a good balance.

Also, we could link to each others' webpages.

Yes, people should own their relays.

I am considering a program where large scale users could register for higher limits. For Bostr this should only affect public instances. And higher limits will be available in general, which should allow running personal instances with 0 issue In that case, I’d want some way of passing a rate limiting identifier down (like hashed version of user IP/PK) so that if someone is abusing the proxy, only the abusers can be blocked

these are good points. For discovering search capable relays you can use NIP66 for that, we just need more people running monitors to help this bootstrap but there are already quite a few. For monitizing relays, this is where I think it shows that many search related relays struggled to monetize and then some of them died. I think that it is better for nostr to start with localized search. Eg, if a client downloads so many events it should also be able to search them. Same for smaller relays, like back in the day when you went to a specific site to search for a specific thing (stackoverflow, wikis, project specific forums). Building one big search and attempting to offer it for free seems like it will lead to capture based monetization strategies which nostr is better off avoiding. Mastadon, Discord, these do not lump everything into a global search, but can provide very useful localized search despite this. So then NIP66 can act as sortof a distributed 'directory' of smaller or specialized searching (or any other kind of relay discovery)

I’m running a client-localized search specifically for long form articles on #decentnewsroom I don’t think anyone even knows it’s there 🤷🏼‍♀️

Decent Newsroom

Search - search - Decent Newsroom

Search for hidden gems on Newsroom

I’m actively avoiding claiming and chasing global discovery. The only way to handle decentralized sources I have come up with so far, is to invite writers to sign up to be actively included by telling me exactly where their content is supposed to be, so I can fetch their content from their relays and also give them some feedback if it fails.

I’m mostly bothered by latency. I’m running a client that does event lookups server-side, trying to serve a pool of users simultaneously, reusing connections and collating reqs. I’m still tweaking the whole thing, and can’t claim to have it all figured out, but it seems to me that relays are aimed at browsers requesting latest events, and my typical filters by a/A, d, etc tags take a long time to resolve.

do you have the title-d-tag filter?

On my blog, I just pull articles from a preset set of relays, so if you want the search to cover it, publish there (such as wss://theforest.nostr1.com). Search is always a subset of relays and there is no way for a search to have the full set (as not all relays are public and discoverable).

I pull articles actively from a configured set of public relays, theforest included. The thing is, we’re swimming in test content and auto-imports. What I’d prefer is to have the authors that actually expend effort on their content to have a way to signal that.

The main search input looks for matches in the title, summary and content of the articles.

Yeah, I've been thinking about maybe hiding the latest articles feed and just showing the manually-curated category articles. But I am finding articles for the curation in the feed, so I've left it, so far. I added a magazine-tree editor, by the way, that handles categories, subcategories, and article editing. You have to create the top-level magazine index someplace else, but you can add to it and edit it, from there. After I made it, I saw that you already had one. 😂 Oh, well. Mine is more compact, so that's sort of nice, for editing a magazine I've already made because I can just scroll down to the category I want to change, enter the naddr, and press a button.

ah it wasn't if you filtered the d-tags there are 4 tags slug title, nanoid, uuid and timestamp

Haha, of course I have an editor for the magazines. But apparently it’s totally obscure🙈 I also have the shortcut in the article pages. If you log in, you can add an article to a chosen category with one click.

If I understand correctly, you’re asking about spacific tags? No, it’s more content oriented than that. I haven’t seen much content with specialized tags like that, and not enough searches to see a need to extend further. Do you have a specific problem looking for something?

Ah, nice. That is clever! Also like that I can get the URL from the ...more menu on the article. Getting from URL bar doesn't work well on mobile. If the logged-in person is the magazine npub, maybe render an edit-icon button and give it a prominent border, or something. Idiot-proof it some more. If I am looking at my own magazine, it's primarily to edit, not read.

There’s ‘My magazines’ list you can access from the menu, with prominent edit links 😂 But you have to get there first 🤪 And there’s an edit action in the magazine … menu, if you find it 😅

no problem

Things are slow and inconsistent

Yes. This also goes with most services as well. For example, my rate limits are targed for end-users. I can't really know the difference between a central server proxying requests on behalf of a bunch of users or a single end-user. In this case, hosters will either need a contract for a bigger pipe from relays, or they will need to keep relays synced on-prem.

Could you list a few example filters?

I do have a local relay that aggregates from multiple public relays, but I’m deliberately limiting the scope of kinds I’m pulling in. But I am being oportunistic about events that don’t fall into my immediate sphere of concern, and those I try to fetch on demand, when they come up. So I might find a highlight, then look for the article it’s referencing. Of find a nested kind:1 in an article and try to fetch that, then it’s comments/thread. It all revolves around articles, so I’m not storing all possible kind:1s, for instance. I’m trying to scale it down enough so I don’t have to negotiate with relays for extra access, so I can keep my client resilient to decentralization of relays and do outbox. On the other hand, I’ll invariably end up with most traffic going through major relays, so yes, we’ll likely need to coordinate that.

I'm using filters like `kinds=[30023];authors=N1;#d=N1`, `kinds=[1111];#a=N1`, `kinds=[1111,9735];#A=N1`, and `kinds=[20,21,22,9802,10015,30023,34235,34236];authors=N1;limit=100`.