hodlbod

I know we've had like a billion proposals for conflict-free lists, but I think I found a pretty clean way to fix them: https://github.com/nostr-protocol/nips/pull/2123 Follow list nuking continues to be very common. This PR basically just upgrades kind `1xxxx` into kind `3xxxx` lists in order to avoid conflicts.

I haven't laughed this hard at a hackernews post in a long time https://clocks.brianmoore.com/

Did Claude just SQL inject itself?

They did it! Going to print some of these up. nostr:nevent1qvzqqqqqqypzpqz8m7vp497agx6g7422cq8fp0tzxj87v5uyez809ypj6afg2u2rqqspyaz8ns8z27l70a63lsx4slyjl43srppshful5e4kqq5g3svvn3qtl3zdm nostr:nevent1qvzqqqqqqypzp978pfzrv6n9xhq5tvenl9e74pklmskh4xw6vxxyp3j8qkke3cezqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcpr9mhxue69uhkscnj9e3k7unpvdkx2tnnda3kjctv9uqzqrehjzlflh2fjp05rf0enwaz68sx0nuh246eeqvx75w85ec8sv36rhrts9

Freedom technology is not revolutionary. Its goal is not the toppling of established structures of power in order to replace them with more of the same. Freedom technology is the application of the balance and beauty inherent in nature to the invented realm. It is the submission of technique to the end of human flourishing, not the other way around. Freedom technology the end result of designing our artificial environment to uphold, rather than erode, the distinction between spectacle and reality, self and other. Freedom technology by definition abides by the transcendent principles that define the idea of liberty itself. Freedom technology is not merely the next step in the churn of history. It is an appeal to the highest good for man in a necessarily material world. "Gradually it was disclosed to me that the line separating good and evil passes not through states, nor between classes, nor between political parties either - but right through every human heart - and through all human hearts... And since that time I have come to understand the falsehood of all the revolutions in history: they destroy only those carriers of evil contemporary with them (and also fail, out of haste, to discriminate the carriers of good as well). And they then take to themselves as their heritage the actual evil itself, magnified still more." - Alexander Solzhenitsyn

Just released Flotilla 1.5.3 — this is a bugfix release, but I did add a space edit form which allows you to set your relay's name, description, and icon via NIP 86 (if your relay supports it). Full changelog: * Add space edit form * Improve room syncing * Return better blossom errors * Fix access restricted bugs * Add room detail dialog * Fix broken link to self hosting * Tweak shadows * Always join spaces when visiting them

Here are some things I'd like to see from the Square/CashApp team for making this stick. I'd hate to see merchant adoption stall again, especially when we have to tools to make it an every day thing: - Onboarding resources for "local guides". I am enthusiastic enough to actually go talk to the businesses in my area about accepting bitcoin, but a really crisp value proposition for businesses would be helpful (fees? UX? treasury?) - A referral program for people doing the boots-on-the ground work of onboarding merchants *and* onboarding customers. Both sides of the market have to be developed at the same time, local "guides" are indispensable for stuff like this. - A clear articulation of the value prop for customers. You don't pay card fees when you pay, and you have to pay fees to get bitcoin. What is going to make customers want to pay to convert fiat into bitcoin, only to give it away to merchants? There has to be a clear story here — maybe a 1% discount merchants can offer? I think this is a huge opportunity to move bitcoin into "medium of exchange territory" that we should be sure to avoid wasting. If Square/CashApp can leverage the enthusiasm of local bitcoiners to help nurture the network effect, that would be a huge success. nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaejuum0vd5kzmp0qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy88wumn8ghj7mn0wvhxcmmv9uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qyehwumn8ghj7mnhvvh8qunfd4skctnwv46z7ctewe4xcetfd3khsvrpdsmk5vnsw96rydr3v4jrz73hvyu8xqpqsg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q3gljvd nostr:nprofile1qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3vamnwvaz7tmjv4kxz7fwd4hhxarj9ec82c30qyghwumn8ghj7mn0wd68ytnvv9hxgtcpzemhxue69uhk2er9dchxummnw3ezumrpdejz7qgwwaehxw309ahx7uewd3hkctcqyzvrz5fj664celjqfuagq34cxdk4ghc5jjck8dhwdf3er3dwcfyvjunv3pq nostr:npub1ds3hmzemzgp9rsuvyvxqdk0y3uxnq9m903dktjxrvyfwk9w99t4sc2hzcn nostr:nevent1qvzqqqqqqypzqpxfzhdwlm3cx9l6wdzyft8w8y9gy607tqgtyfq7tekaxs7lhmxfqyd8wumn8ghj7um9dejxjapwdehhxenvv9ex2tnrdakj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7qgewaehxw309ac8yetdd96k6tnswf5k6ctv9ehx2ap0qqsgl5ewfpy5k407dcsdtfygpq4q5gsf3sga5xjspuc9h0pnxqss0sqvy5u94

I spent some time this week writing a new key rotation scheme for nostr: https://github.com/nostr-protocol/nips/pull/2114 I think it's pretty good for what it is (it improves on nostr:nprofile1qyxhwumn8ghj7e3h0ghxjme0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg3waehxw309ucngvpwvcmh5tnfduhsz9mhwden5te0wfjkccte9ec8y6tdv9kzumn9wshszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75s49cdh4's version by not requiring an arbitrary time delay). At the same time, it's riddled with very fragile assumptions about events being available, introduces a hard dependency on OTS (or some equivalent), and requires clients to constantly compute key validity. At the end of the day, what I have learned is that we probably can't realistically do key rotation on nostr in the application layer — we need some kind of cryptographic magic or strongly consistent data store to make it happen. It still might be an interesting read for the nerds out there though.

Double buffers are one of the coolest programming techniques, and are relevant more often than you would expect

This is pretty funny nostr:nevent1qvzqqqqqqypzp0mldsapt7922jms983dvte80qnwwgm4848a38l50mldn9uqzhkvqqs0aslrntumxen7ch5hyl98se7zn7n2g9cc99dj2a5x9l2grt2aslg6ry3l3