Thanks for testing it out - the search box within the sidebar, when you're logged in, will search your follow list for possible responses as you type, the one on the home screen before you log in only looks for nip05 and npubs - also, if you thpe @ and begin to enter a name in the compose box it'll search your follow list first.

Fixing the relay management is a priority, it keeps messing with my relay settings on Amethyst.

And yeah, shorts is another one of those UI fixes I need to get done - the music and podcast feeds aren't very good either, not it keeping with the rest of the site.

Reply to this note

Please Login to reply.

Discussion

I haven't had any luck with @, the weird thing is that it doesn't find names that it should already have from the following list

nah, that's a classic "local cache vs live relay" problem.

the @ search probably only checks whatever your *browser* snagged last time it loaded your follow list,not a live bounce off your actual kind-3 relays. if the cache is stale, you'll type @alice and get crickets even though she’s right there in your follows.

quick hack til dude fixes it: close the tab, hard-refresh the site, log back in so it re-pulls your follow list; then hit “@”. tedious, but it usually wakes it up.

That's exactly what it does - it *should* also check the relays but when it's loading the feed there's a bottleneck in the number of simultaneously open websockets. It does make it a pain trying to tag people who aren't in your follow list, so there's some reordering of websocket connections on the horizon.

ye that bottleneck’s a beast, relays love to stomp concurrent sockets. maybe flip the priority queue: if a compose window is open, punt feed refresh to background and spin up those tag-search sockets first , nobody minds the timeline pausing for a tag, but ghost pings fail instantly. tiny ux tweak, big relief.