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.
Adam Ritter | rbr.bio
aritter@iris.to
npub1dcl4...x5ey
Creator of rbr.bio and nostr-relaypool-ts
#[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.
UvitaA 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).
New feature for rbr.bio: showing a basic feed.
I’m now running a light client that showcases how to get data from rbr.bio.
Here’s an example:
https://rbr.bio/npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m
The source code is in my light-nostr-client repo.
#[0] #[1] #[2] #[3]
rbr.bio update: It wasn't setting CORS headers correctly for JSON files. Now you can use json services from any web page
New features for developers in rbr.bio: info.json gives back the information presented on the page on an author (and a bit more): metadata, contacts, number of followers, metadata and write relays of followed authors.
This makes easier to develop a very light client. Making changes in the server code HTML all the time doesn't make sense for me for developing, but this can be used by other clients as well.
#[0] https://rbr.bio/ has now a list of the 100 most followed followers shown for users as well (no pagination yet)
rbr.bio has now search functionality. Also service is more stable, and data is updated every hour. As I would like it to be the best generic contacts and metadataserver, the data has to be live of course.
The next steps for rbr.bio are search in UI, decreasing RAM requirements at startup, data freshness and load balancing between US and EU servers