mutex / mutex is on Nostr

"2a849a75fff09b61b28f667ee3d407378a3b96f5c48d481f779aab6812a60deb50a0edc9d19342df6a99b1c0ae03e112422597daf81283e644ffd1aa50a33666"

Last Notes

2026-02-03 01:51:01 UTC

- reply

well you can say that to him, if AI confirmed his point of view i wouldn't have bothered to reply

2026-02-03 01:46:51 UTC

- reply

why not? i gave him the answer he is looking for. after reading and removed useless points 4 and 6.
you see he was wrong about the dystopia thing here, it is a good thing for privacy

2026-02-03 00:59:43 UTC

- reply

:
This person has identified a real and rather unsettling quirk of how modern browsers handle embedded content, but the interpretation needs some clarification. Here’s a breakdown of what’s likely happening:
1. What’s likely being observed
The 42 MB is probably the storage allocation for the YouTube iframe’s browser cache, service workers, IndexedDB, or other persistent storage that YouTube sets up when it loads in an iframe.
YouTube (like many large web apps) uses client-side storage for performance, offline functionality, tracking, etc.
In modern browsers, storage is partitioned by origin + top-level site (a policy called “Storage Partitioning” or “Network State Partitioning”).
This means if you embed youtube.com on example1.com and example2.com, each gets its own separate storage bucket for YouTube, even though the YouTube origin is the same.
2. Why 42 MB specifically?
That number isn’t random; it’s likely the initial or default storage allocation YouTube requests via the Storage API or IndexedDB.
Browsers may pre-allocate space up to a quota, and 42 MB could be YouTube’s chosen baseline for caching video segments, player assets, etc.
The exact number might be consistent because it’s part of YouTube’s embedded player initialization.
3. Why does each site get its own copy?
This is due to privacy-focused changes in browsers (especially Safari, Firefox, and Chrome) to prevent cross-site tracking via shared storage.
Previously, if you visited Site A and Site B, both with YouTube embeds, the embed could share storage and use it to identify you across sites.
Now, with storage partitioning, the YouTube iframe storage is segregated per top-level site. So yes — you end up with duplicated storage for each site where YouTube is embedded.
5. Is this dystopian?
From a user storage perspective, it feels wasteful — dozens of sites × 42 MB adds up.
But from a privacy perspective, it’s meant to protect you. The alternative (shared storage across sites) would allow YouTube to track your browsing across all sites that embed its videos.
The real criticism could be:
Why does YouTube need so much storage for a simple embed?
Could the embed use a lighter, storage-free version if it’s just a video player?
Conclusion:
The observation is essentially correct — each site with a YouTube embed gets its own partitioned storage chunk (~42 MB) from YouTube. It’s a side effect of privacy protections + aggressive caching by large platforms. The trade-off is privacy vs. storage bloat.

2026-02-01 05:51:06 UTC

- reply

Thanks!
it depends on which browser you're using, Keychat is more restrictive for the added nostr and privacy features, I'm still not able to detect why it won't refresh and couldn't debug my client on their desktop version. couldn't play with screen off too. will try to make it work better on Keychat but it may be a trade-off for their added features so it may never work.
but if you can test on other browsers it should work fine with screen off or even in background while using another app, I'm assuming you mean android.

2026-01-30 04:27:02 UTC

- reply

github is just a host for your source code, you build on your device then push to github. there is github pages that can host your static website if that is what you mean, i am hosting my app on that. but github is just a host you are not creating anything in it.
any AI can help you with detailed step by step answers for the thing you are trying to achieve.

2026-01-30 03:49:21 UTC

- reply

not sure what you mean, question too broad

2026-01-30 03:38:49 UTC

- reply

it prevents refreshes

2026-01-30 03:17:22 UTC

- reply

lightning addresses and zaps, just like other nostr clients

2026-01-30 03:05:52 UTC

- reply

removed the auto detection for extension and it seems to be working fine now. seems Keychat needs some time to inject the browser extension or something.
there is another problem just with Keychat when the app updates it freezes

2026-01-30 02:00:55 UTC

- reply

yes, it currently should auto detect a browser extension and show like that
https://image.nostr.build/d5ab0408e6a2faf79efe63c13fb49de5a89deaf2836bdab98ea11de6987ff156.png

2026-01-30 01:42:13 UTC

- reply

actually found keychat already installed on my android from earlier, what's different in keychat than a browser with signer extension because it seems not detecting it on keychat

2026-01-30 00:32:33 UTC

- reply

it works on keychat

2026-01-30 00:22:59 UTC

- reply

what is keychat?