DeepSeek

I bet Zelda Chuanshou Shiguang Zhi Di blew their fucking minds when they were finally allowed to play it.

So tired of hearing about the price of eggs. I'm VEGAN.

It's an SOS flare. View quoted note →

Thousands of hours have been wasted on bloated JSON logging frameworks in JavaScript. Yet this is all that's needed. You just define the type of your logs, and then wrap `console.log` with the type.

I am excited to start developing features again, to make the community aspects of Ditto shine. This issue has been holding me back. Some big changes are coming soon! View quoted note →

I want to tell you why #Ditto was slow and how we fixed it. There were 2 issues: Postgres performance and nip05 lookups. Postgres performance was caused by profile lookups, eg: { kinds: [0], authors: [a, b, c, d, ...] } The issue was ORDER BY clauses on those queries. This caused Postgres to do a "sequence scan" instead of using the correct index: "nostr_events_replaceable_idx" UNIQUE, btree (kind, pubkey) WHERE kind >= 10000 AND kind < 20000 OR (kind = ANY (ARRAY[0, 3])) I actually fixed this already last year, and then reverted it in the last few months due to a bad decision. 🤦 See:

GitLab

NPostgres: speed up queries of replaceable events by restoring conditional sort (6a51c3f8) · Commits · Soapbox / Nostrify · GitLab

Standards-oriented Nostr interfaces and modules in TypeScript. https://nostrify.dev

and https://habla.news/u/alex@gleasonator.dev/nostr-filters-limit Logging query errors exposed this. This is why logging matters, people! Now I am switching Ditto to use JSON logging and incorporating Loki + Promtail so can easily track these problems in the future. As for nip05 lookups - Ditto actually does nip05 verification in realtime as feeds are being rendered. This is obviously very bad. It does have an in-memory LRU cache, but restarting Ditto resets it. As a result, feeds can take up to 3 seconds to load (that's the timeout I set for fetching nip05). And if fetching fails, usernames are not displayed correctly. To solve this (with a bandaid solution), I configured squid (HTTP proxy) to aggressively cache nip05 responses with this: refresh_pattern /\.well-known/nostr\.json 3600 0% 259200 I also had to configure Ditto and squid with self-signed SSL certs so it can mitm and actually cache: http_proxy="http://squid.lan:3128" https_proxy="http://squid.lan:3128" DENO_CERT="/etc/ssl/certs/squid.crt" My TODO is to cache nip05 verifications in Postgres, to solve the root problem for self-hosters and increase performance even more. tl;dr Ditto is fast now.

No, you're supposed to rebuild the internet.

Guys, Ditto is fast now.

Oh my god I finally got squid caching to work and it's so fast

I have a squid kid, and a squid parent. Sometimes the kid kills the parent and sometimes the parent kills the kid. And I have a demon opening my logs. This sounds nonsensical but it's actually computers.

Btw the Mostr Bridge has been updated to block porn content on the relay, to the extent that it's possible.

If you receive nutzaps, how can you get it into a regular Bitcoin wallet? Interested in both theoretical and practical, but mostly practical.

Working on a new layout for #Ditto

On Nostr everything is backwards, so as a client you can actually get DoSed by a server. Therefore before you can implement Outbox you need to implement rate-limiting of relays.

Spent 8 hours debugging performance issue, it was because I blocked the port on my own firewall.

Whenever I am looking at my server logs, the performance is fine, perfect, impeccable. Whenever I turn my back it starts breaking in ways I can't observe later.

The American election is dialectics enshrined in law.

When I was a kid I listened to Metallica, and I thought I was very cultured because I listened to music from 20 years ago. But to my surprise, kids today aren't listening to 50 Cent, they're still listening to Metallica, now 40 years old.

This is getting ridiculous. https://www.reddit.com/r/glutenfree/comments/1i6z8j6/should_rglutenfree_remove_links_to_twitterx/