It's just not worth the time in my opinion. When it really matters is when people talk about not knowing where to invest their money because it's so hard decision. That's when I start offering an orange pill.
I hope we can get more technical talks here in the open nostr over time.
Notifications are a great start, but it would be more cool if clients can be easily used for live chat
I wish he would have talked much more, there are so many cool technical details to go into
#[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.
travala and hotels.com gift cards are the two options, but travala is sometimes more expensive, hotels.com gift cards are harder to use
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.
Who cares if it's not backed? Let's just hope that American taxpayers will save cashu together with Goldman Sachs
Improved rbr.bio websocket API again: get followers using count+group_by:

It was just a very simple getting https requests from the browser vs sending ws messages, and WebSocket / Nostr won by 10x. Maybe working more on HTTP/3.0 support would speed things up and allow better caching, but it's probably just not worth it, as it's getting farther from the original Nostr protocol:
w=new WebSocket("wss://rbr.bio"); w.onopen=()=>console.log("opened"); w.onmessage=(x)=>console.log("message", x)
z=0;all=1000;time=Date.now();w.onmessage=(x)=>{if(JSON.parse(x.data)[0]=="EVENT") z++; if(z==all) console.log("time",Date.now()-time) }; for(i=0;i // 2500ms let u="https://rbr.bio/82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2/metadata.json" time=Date.now(); a=[];for(i=0; i<1000; i++) a.push(fetch(u)); for(i=0; i // 21035ms Also tested JSON.parse: time=Date.now();for(i=0; i<1000; i++) JSON.parse(data);Date.now()-time // 2ms
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': [
["COUNT", "", {count: 238}]
Let's play double or nothing haha
From what I understand #SVB (https://nitter.moomoo.me/search?q=%23SVB) picked a poor time to refinance. It wasn’t that they were lending to wildly unqualified people or were over leveraged. VCs got spooked & thought that they were in trouble & caused a bank run. Very different then #FTX (https://nitter.moomoo.me/search?q=%23FTX) who were illegally over-leveraged.
https://nitter.moomoo.me/MinaSalib09/status/1634620551682486273#m
Blockfi did the same until FTX didn't overtake it to destroy it completely. The good thing is that now the government stepped in in time, it still has most of the money.
I'll add gossip model https://bountsr.org/gossip-model/
Nip65 is a bit weird, I don't understand the rationale of not using kind 0 events. https://github.com/nostr-protocol/nips/blob/master/65.md#why-not-in-kind-0-metadata
But might still add support for it
Actually relay info (especially write relays) are stored in contactlists, not in metzdata. Though I know that Iris downloads lots of contact lists of friends.
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).
Developers stopping using Telegram and moving here. There's no reason for them to keep using Telegram
Moving Bitcoin Core development off GitHub sounds really hard to do independent of how it’s done.
But it would be awesome.
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
