Avatar
jleger2023
597b42de56a9e0c19ee2d0cde5797dd58d48ce8dd25c732b4c873af11161f9fd
#Bitcoin 25+ year dev NostrGram (Nostr client): https://nostrgram.co/ YouTube: https://youtube.com/@regardingbitcoin Substack: https://jonathanleger.substack.com
Replying to Avatar Melvin Carvalho

Yes, that's RFC 69 not NIP 69 which is something else

https://github.com/nostr-protocol/nips/pull/320

I dont even know what an RFC is, just be aware there's a naming clash

Kind 6969 I think is unique tho

There's also https://github.com/nostr-protocol/nips/pull/148

Poll and vote event

Apologies for the confusion by calling it NIP69.

FYI I'm working with #[0] to implement #[1]'s NIP69 for Nostr polls where you ⚡ to vote. I love the idea. Will be working on it this week.

Goodnight everyone. More building to do tomorrow. 🛌

Have fun at Nostrica folks. Wish I could be there.

Ok, rebuilding the full text table now. It's not as large (~5 million records rather than 22 million) but will still take a couple of hours.

The NostrGram events table rebuild is complete. Dropped the table size from 56gb down to 16gb 🤯. Indexes are all rebuilt and should in some performance increases. Not with full text search though. That's a separate table that I also need to rebuild now that so much spam has been cleared out of the database.

Listened to #[2] on a long drive this afternoon. Excellent as always. Best macro analyst in the space for sure.

It's *supposed* to fallback to that automatically. I'm trying to troubleshoot why it's not for some folks.

The paid relays are "pay to write" not "pay to read". If there are any that are also pay to read I'm not aware of them.

FYI rebuilding the NostrGram events table in the db. It's been updated a few times with new indexes and deletes of spam and such so I'm rebuilding the table, which rebuilds the indexes. That will shrink the database size and increase index performance so it should be faster once it's done. While it's rebuilding NostrGram may be a little less responsive though. The rebuild will take a few hours.

It uses a caching server that indexes events from about 150 relays for performance and aggregation and being able to load events from a single server instead of a dozen or more relays. It writes to relays in the usual way though.

FYI I'm writing a script that keeps your 10 most recent Kind 3 events (following list) but deletes any that are older than those 10. The 10 lets you restore your following should you lose it. Kind 3 are *space hogs* are constitute about half the current database size while most of those records are unused.

Are you saying you should be able to accept a badge without displaying it?

I am the dev team lol. It's a one man show. I'm not trying to set the client apart from others to be honest. I'm just making the client I want. As it turns out a lot of people want what I want, too, and have made lots of suggestions for things I didn't know I wanted until they suggested it. So it's evolving with the user base.

I'd love to think everybody will run a relay some day, but as a dev I've worked with normal users for 25+ years and know that the majority never will. Most people simply aren't capable or inclined.

I've been too buried in coding to listen to many podcasts lately, but when #[2] is on it's a priority to listen. She's the best macro analyst in the space imo.