So tired of hearing about the price of eggs. I'm VEGAN.
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!
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: https://gitlab.com/soapbox-pub/nostrify/-/commit/6a51c3f8a73c8a9f852a46d57119afdd4bc25b53 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.
You can get a 24TB hard drive off Amazon for less than $500. The blockchain is already nearly 1TB - I had to upgrade the drive in my laptop to use it anyway.
I think delaying the problem would have been good, since Bitcoin still isn't even close to hitting the point of being used as an actual currency. But that is a lost battle.
The point is that Lightning is a premature optimization. If people were using Bitcoin to buy coffee so much it congested the network, then it would be a great problem to have. We would be a great shape in terms of adoption. But people are not even ready for that yet. We're like 20 years in the future, and sometimes I think we have to step back and look at today.
Almost nobody is using Nostr, and even among the people using Nostr a very small percentage actually send zaps. The reason is because it's too hard. So if you're argument is that nobody will do it, that's already the current situation.
Here's my controversial opinion. Firstly, Bitcoin Cash was right - their solution would have at least stopped the bleeding temporarily.
Secondly, I send Bitcoin all the time and pay less than $1 in fees, and it confirms within the next block. You can even choose to pay lower fees, and who cares if it's slow, it's a donation.
But if nobody else would support doing it on Nostr, there's no point. Or maybe I should just do it and prove everybody wrong. 🤓
I'm only following peer pressure. Truthfully I think the best solution would be to do away with Lightning and integrate Bitcoin natively. Everyone I've told about this seems to think it's a bad idea. But you know what, I don't want you to zap me 2 cents, I want you to zap me $5, so I think this would actually solve everything.
This is true, but a couple dozen Cashu mints that require no authentication or KYC already exist: https://bitcoinmints.com/?tab=mints
NWC is only used by Alby AFAIK. The only reason to favor Cashu is the current ecosystem that supports instant anonymous wallets.
Found it: https://github.com/cashubtc/nuts/blob/main/05.md
You can "melt" a token to pay an LN invoice. To convert to Bitcoin you can plug in an LN invoice from boltz.exchange
This also makes it possible for "nutzap" wallets to do "regular zaps", by getting the invoice and then "melting" to it.
I think it's actually even possible to receive NIP-57 zaps, with a small glue layer between LNURL and the Cashu mint. The server needs to associate their Cashu mint somehow, then it give them a Lightning address. The LNURL call will make a proxy request to the "mint" endpoint internally to generate LN invoices.
This ecash thing is neat, but the main problem it solves for me is a unified API for Lightning providers, so users can switch between them.
Found it: https://github.com/cashubtc/nuts/blob/main/05.md
You can "melt" a token to pay an LN invoice. To convert to Bitcoin you can plug in an LN invoice from boltz.exchange
This also makes it possible for "nutzap" wallets to do "regular zaps", by getting the invoice and then "melting" to it.
I think it's actually even possible to receive NIP-57 zaps, with a small glue layer between LNURL and the Cashu mint. The server needs to associate their Cashu mint somehow, then it give them a Lightning address. The LNURL call will make a proxy request to the "mint" endpoint internally to generate LN invoices.
Is that a standard part of mints, or do you mean like send the owner an email?
If you receive nutzaps, how can you get it into a regular Bitcoin wallet? Interested in both theoretical and practical, but mostly practical.