New milestone in rbr.bio development: threading in the feed view of a person mostly works. Also view as is implemented for fun. The goal of the feed view was to be a simple, self contained, but flexible implementation that is able to recursively load all parent events, merge threads, reorder threads (right now based on newest timestamp in the thread that is shown). I'm planning to add minimal client features for playing with it better (like / reply / follow / login / maybe photos, make it super interactive, for example guarantee to show events from people that I replied to in a thread), but not planning to make it a client, as I'm more interested in creating a library for all clients that need feed support, which means that it has to be super flexible (showing comments, likes optional, recursive previous events optional, 100% customizable html / css). One more thing that *has* to be flexible is ranking: first I'm planning to play with ranking myself, but make sure it's pluggable as well. With generic timeline the ranking function is easy-to compose (just take the minimum / maximum score of 2 threads when merging 2 threads into 1), but I'm not totally opposed to having much more complex ranking functions as well if they make sense and practical (that need all events in a thread and other metadata to compute a ranking function). As I want to use Nostr as a Telegram / WhatsApp / HackerNews replacement for myself, my main ranking criteria will be the probablility that both I want to comment on a thread, and also I'm getting a comment reply. I know that many people care about likes / zaps, I care more about comments.

More fun is coming on rbr.bio, I'm constantly improving threading, showing comments and likes. I want to make it perfect before adding ,,view as'' support (which is basically the following page). What's fun is that I really don't want to do a client, but I feel that it's easier than hacking on another. I just wanted to do my own ranking for nostr, but there are lots of requesites to get ranking right. If it works well, I'd like to make a ,,nostr rendering engine'' available as a library for clients, as I'm trying hard not to go on the full client route. https://rbr.bio/npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m

rbr.bio initial data loading is much faster now. Check out https://rbr.bio/npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m and start browsing. It's still not perfect (still relying on info.json somewhat), but writerelays and metadata for user are loaded first, and cached (using caching of RelayPool). I also added merging of posts with replies that are in the same thread. This will help a lot when viewing more complex interations in the future.

#[0] it was great to meet you in person, our discussions started a lot of thoughts for me. I think bandwidth and retrieval improved a lot, so while there are ways to improve caching, I believe that right now improving ranking is getting more important for improving user experience. After merging threads well, I want to focus on ranking by people who I like and especially people who I comment to and they comment / like back. And want to rank even higher threads with multiple comments by close people. I think it's awesome because it incentivizes people to comment in threads that are interesting to them, and also incentivizes public high quality discussions.

Uvita

A siginficant bug fix is out again in rbr.bio UI, the feed is getting data much more stable now, and rbr.bio is getting faster again (although it's not as fast as I want it to be yet): http://localhost:5173/npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m The next things I want to achieve are getting rid of all http dependencies (and using just wss), and getting threading shown nicely, recursively fetching all events that are replied to, and merging the same thread when it comes up multiple times.

Improved rbr.bio websocket API again: get followers using count+group_by:

You can now use wss://us.rbr.bio and wss://eu.rbr.bio to get number of followers using NIP-42

Upon doing a bit of benchmarking I realized that using https as well for rbr.bio was is the wrong way to go, so I'll switch to using wss and nostr standard for my light client. It also means that I'll implement NIP-45 for COUNT to get number of followers with this query: ["COUNT", "", {kinds: [3], '#p': [<pubkey>]}] ["COUNT", "", {count: 238}]

Rbr.bio is slowly improving: a serious bug in RelayPool was fixed that made messages shown at the wrong place (thanks to #[0] for finding the bug, it took some time for to fix it). At this point rbr.bio's feed is starting to be similar to Iris feed, althouth there are differences. On some queries rbr.bio is even faster, like this on my feed: https://rbr.bio/npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx vs https://iris.to/odell@werunbtc.com One more thing: some of the functionality of rbr.bio was moved to RelayPool, for example you can now subscribe to filters that contain authors without manually setting the relays to use (it will query rbr.bio for the write relays).