Nice pictures.

You can't, you have to trust the archiver, as with anything in Nostr.

Yes, I think it's a good idea to experiment with it. The code didn't change and hopefully it still works. I just moved it to that other place.

We can't fix all the broken things Nostr is trying to fix while at the same time being afraid of offending some misguided prejudices of so-called "normies" (who are never actually called into the debate themselves, by the way -- and of course they can't be, since at the time they get to the point where they can have an opinion they're by definition not "normies" anymore).

Apparently I have free access to Primal Studio and I had no idea. I'm feeling like an influencer now. I'm influencing so much. Look at these crazy influence numbers:

Ladybird, if it ever gets finished (well, it will never catch up with all the thousands of Chrome new APIs, but maybe it will get to 90% and become usable), will be so comparatively slow and memory heavy that only the idealistic "web" enthusiasts will use it, so I don't know that improves anything upon the current situation. Which is good, we can abandon this failed "web" project and move on to the next idea: https://joeyh.name/blog/entry/WASM_Wayland_Web_WWW/

Yes, I do expect that. That is the entire point of allowing users to publish their stuff elsewhere and having clients automatically use other relays. And also making possible for people who want to have their face scanned to continue to use some compromised relay if they want.

It's too unfinished still. The best thing you can possibly do to help now is to create articles with links to other articles and so on. Having more content would probably incentivize the creation of better clients. I believe https://wikistr.com/ favors linking to articles that were liked by the author of the current article or by yourself, or that are in the preferred wiki relays of the current article author or yours. But aside from that it doesn't do much currently.

Quick demo of Samiz + Citrine + Jumble working with 3 phones sharing notes via BLE:

There is not a single internet user who likes cookie banners. Many may not understand why exactly they're so widespread, but everyone definitely knows they are "mandatory" in some way, and everyone would be happier without them. Also all programmers, designers and product managers know they are awful. Yet these big corporate websites keep trying to blatantly lie to their visitors saying stuff like "we value your privacy" in the cookie banners, perhaps because for some weird reason they think that that will "soften" the negative impact of the banners. Why lie? Why not admit the thing is being forced upon them and just do the minimal they're required to? This is just one example case among many in which well-meaning people lie for completely unjustifiable reasons.

https://www.youtube.com/watch?v=l6RYw4Uo9yk

The full text of the following note compressed using https://bellard.org/ts_sms/: 膆䋢䲨䇜奕깇됬卨쁰擐變䱃걿葈堠鞼拍뚚狆乼䎾铖繍蘖匎䯁襇冂㱥拊귉둕錞撶㖭鱿㛭몠槮㭙誡꾊舝洼當艫蟼穅䛞詒靆㽆녻薽殪뱃븈嘷㦧裉涤谗獇䌀뢵镅镬錎岗꽱奌懡韡㓎网繅粄恶䟆夽봍甖㘠雬镢稺壧껬䐋善泙幪羶尽憑갫舀刺㮠焸貣錗㲑苳礣柡쀞龪갠䠜餳讬귋瀔묩摘解丞檯뺠㠛蚜叓欹䤹䦿茅붊契綾茎硾误荫簱蹗歌뷕鑵붶䣎볝맥臈柧広뎫뫺㞻駋蟔䔂墣褜罿䖆踮樕沆扮颡湞剟殕䓛徤땐侓뻗莵嵾㕰鬤惰囫䕳䃝뚖䨫稍䵸䀯䗀鵈湎묇疕愙示饻藣䐮釭节遵蘰恲㟪宇붵漆믰絢㒷彉冖墼겈璔蛇耴烡穢떋㖟毳릻꾎벺鄕遠秃㮐鱎䣹눮䪙怱㼃뤅瑛䝑薼兹气燇䀨䫘㞑畓䦇噖埯裡䖚䱵許諉窚谕蛥瓕厪떂瞓륹茮먡艚㵮齪妤蔿뺍醙睕䫪囤嬢姗钇鵌蓧궕簜諁苉䐴凙潅격㲘꼡哕鏚脶벇㜣幉蹱䖼둥褒㰟汍虗㪂蠵聊

Sorry, krautrock is too disturbing for me.

First of all this isn't backwards compatible (because indexes, relay message validation and other things have to be changed), so if you're going to break Nostr entirely then it's better to make a new protocol that also tries to address other suboptimal parts of Nostr, like is doing with Mosaic. But then at the same time you lose all the (small, but significant) network effect we have here, which to me isn't worth doing. Second, you create the need for these "disavowing" events to be reliably published (which cannot ever be guaranteed in Nostr) and they become the central part of Nostr, and you can't have that work reliably without a centralized sequencer (i.e. either a blockchain or a trusted operator), see for just a brief example of one of the many half-broken issues that can happen (I'm not sure this specifically applies to your idea, but I'm sure we can think of many variants). Now even if by miracle these disavowing events become reliably distributed then there is still the problem that now all clients and all relays have to store them and then check all incoming events that come with a locally valid attestation to see if their pubkey has been previously disavowed, forever. (I just came up with these issues now, later I can revise my opinion to either add more or retract these.) The other solution is to go the NIP-26 way and treat each key as independent, soft-linking them with attestations. That is more elegant in my opinion, but in practice it breaks too, because of issues like those described in this comment by : https://github.com/nostr-protocol/nips/issues/1810#issuecomment-2685163334 Maybe you'll want to see also although I don't remember what I wrote there.

I could definitely do that but I don't want people to think I care about email.

I get it, but any subkey proposal creates enormous burden on clients and relays and ensures nothing cool can ever be built again on Nostr. Also bunkers -- hosted frost multisig, self-hosted, running on your phone, running on trusted hosted hardware, running on a physical device in your home -- are the solution to not having to post your nsec everywhere.

I did try to livestream, it worked, I even watched my own livestream on https://zap.stream/. But it was a couple of days ago.

I think https://github.com/nostr-protocol/nips/blob/pf7z-nip41/41.md is still the best idea for saving identities from catastrophic key loss situations.

It's hard to believe it actually works, but it does.

A better URL to accompany my comment from 43 days ago: https://ngit.dev/grasp/