After building a paginated list of items using Dexie’s liveQuery feature, I’ve now refactored the project to use static queries instead.
The live updates aren’t worth the hassle and inconsistencies you have to deal with when using liveQueries—although I’d love for a future version of Dexie to make this easier (which it seems there are plans for in v5 
).
Un exemple d'utilisation des services workers et d'IndexedDB (la base de données incluse dans les navigateurs) pour créer un système qui permet d'uploader une image même sans réseau et de faire l'upload réel lorsque le réseau est à nouveau disponible.
https://www.smashingmagazine.com/2025/04/building-offline-friendly-image-upload-system/
Ok. Just culled ~20,000 of 25,000 #tumblr posts accumulated via #RSS over a month. I've gotta get to work on my own project applying basic statistics to this stuff. Think "reverse chronological + $all_your_own_filtering_and_sorting_and_bucketing". Not sure if I should do that within the confines of a #thunderbird add-on, or try some other approach. I really, really want to be able to use #sql for this stuff. It's a natural fit. But #sqlite seems to be a no-go for #WebExtensions. There is only #IndexedDB, which, in my limited experience with it, is absolute garbage to work with.
Kahuna, the IndexedDB-Manager Webextension
With the changes brought by Svelte 5, I found myself wanting to take advantage of performance improvements and harness the power of runes. But converting my stores to something 'rune-based' proved more challenging than I had hoped since so much of my codebase relied on stores.
Migrating Svelte Stores to Runes
https://www.closingtags.com/svelte-stores-to-runes
My esteemed followers, you have posted a total of 375,809 statuses to the #fediverse. 22% of you have posted in the last 24h. You are a chatty bunch! ;-)
Check out my new #sideproject: *fedi-followers*. A privacy-friendly fediverse #followers explorer as #localonly #staticwebapp, decentrally hosted on the #ipfs. See who's actually following (and unfollowing) you over time and much more.
I've built a thing.
Sometimes my follower count seemingly fluctuates at random. To understand why, I dug into the #MastodonAPI and created "fedi-followers":
A privacy-friendly #fediverse #followers explorer as local-only static web app, decentrally hosted on the #ipfs. See who's actually following (and unfollowing) you over time and much more.
Использование браузерного хранилища для управления состоянием приложения
Современные web-фреймворки для реализации управления состоянием используют библиотеки, такие, например, как Redux для React или Pinia для Vue. У традиционной реализации управления состоянием есть недостатки. Store в таком варианте является частью скрипта страницы, и его данные при её перезагрузке теряются. Кроме того, если нам в приложении нужно организовать управление отображением контента в нескольких окнах браузера, оказывается, что традиционный Store не может этого обеспечить.
localForage — Что делать если localStorage уже не хватает?
localStorage и sessionStorage сильно ограничены в размере - всего 5 МБ, а использование IndexedDB для обхода этого ограничения не всегда является удобным из-за сложного API. localForage решает сразу обе проблемы!
"Encryption at Rest" for JavaScript Projects
Following a previous post (https://infosec.exchange/@xoron/113446067764347249), which can be summarized as: I'm tackling state management with an extra twist: integrating encryption at rest!
I created some updates to the WIP pull-request. The behavior is as follows.
- The user is prompted for a password if one isn't provided programmatically.
- This will allow for developers to create a custom password prompts in their application. The default fallback is to use a JavaScript prompt().
- It also seems possible to enable something like "fingerprint/face encryption" for some devices using the webauthn api. (This works, but the functionality is a bit flaky and needs to be fixed before rolling out.)
- Using AES-GCM with 1000000 iterations of PBKDF2 to derive the key from the password.
- The iterations can be increased in exchange for slower performance. It isn't currently configurable, but it might be in the future.
- The salt and AAD need to be deterministic and so to simplify user input, the salt as AAD are derived as the sha256 hash of the password. (Is this a good idea?)
The latest version of the code can be seen in the PR: https://github.com/positive-intentions/dim/pull/9
I'm keen to get feedback on the approach and the implementation before i merge it into the main branch.
Does anyone have a good example of using #Leptos with #IndexedDB ? Something that shows best practices for managing the IdbDatabase and IdbOpenDbRequest values and making them available to any component (assuming I'll need to use a context or store)
"Encryption at Rest" for JavaScript Projects
I'm developing a JavaScript UI framework for personal projects, and I'm tackling state management with an extra twist: integrating encryption at rest!
Inspired by this React Hook: Async State Management (https://positive-intentions.com/blog/async-state-management), I’m extending it to support encrypted persistent data. Here's how:
The Approach:
Using IndexedDB for storage.
Data is encrypted before saving and decrypted when loading using the Browser Cryptography API.
Event listeners will also be encrypted/decrypted to avoid issues like browser extensions snooping on events.
The password (should never be stored) is entered by the user at runtime to decrypt the data. (Currently hardcoded for now!)
The salt will be stored unencrypted in IndexedDB to generate the key.
Proof of Concept:
You can try it out here: GitHub PR (https://github.com/positive-intentions/dim/pull/8). Clone or run it in Codespaces and let me know what you think!
Looking for Feedback:
Have I missed anything? Are there better ways to make this storage secure?
Let's make secure web UIs a reality together! 
#Database․build: Browser-based #PostgreSQL Development Environment
Runs completely in-browser using #WASM technology powered by #PGlite, with data persistence via #IndexedDB
Features #AI assistance for database operations, including smart CSV imports and automated report generation
Built-in tools for creating charts and database diagrams with drag-and-drop functionality
Developed using #Nextjs framework with #S3 deployment capabilities in development
#Opensource project (Apache 2.0) by the #Supabase community
Learn more: https://github.com/supabase-community/postgres-new
#Development #Pitfalls
Don’t use localStorage for sensitive data · Alternatives for tokens, secrets, and private info https://ilo.im/160lq1
_____
#LocalStorage #SessionStorage #IndexedDB #JavaScript #Security #Vulnerability #XSS #Browser #WebDev #Frontend
If I'm going to store #JavaScript objects in #IndexedDB, is there any significant size or performance difference between storing them as Objects (letting IndexedDB serialize them), strings (post-JSON.stringify), ArrayBuffers (post-TextEncoder.encode), or Blobs (wrapping the ArrayBuffer)?
My assumption is the space difference is minimal or none, and that there may be some performance gain for not doing the JSON -> UTF8 -> bytearray conversion in discrete steps in Javascript.
Here's a trivia question: when using IndexedDB, can a transaction with a single put() operation fail even if the put operation itself succeeded?
I suspect the answer is "yes", but it'd be interesting to know for sure one way or the other.
If it's "no", it simplifies code a bit in that one doesn't need to stash the autogenerated key (if using that option) between the put's "onsuccess" and the transactions "oncomplete."
#Development #Techniques
Storage for the web · Which browser storage is best for your needs? https://ilo.im/1607lb
_____
#Storage #CacheStorageAPI #OriginPrivateFileSystem #IndexedDB #WebApp #PWA #Browser #WebDev #Frontend
#indexedDB is really a cool API, but how have they not yet implemented encryption at rest as a standard feature? Or did I miss the release notes somewhere?
Feels unnecessary on a private device, until you realize that it's local to the device's storage, which may or may not be encrypted, and is definitely not encrypted when the browser is open.
Am I being paranoid? I don't want unencrypted data just sitting there in the dev tools for anyone to read.
Updated! Store your lists of numbers in Indexed DB as UInt8Arrays!
(Previously I recommended base64 strings, but UInt8Arrays are much better.)
Thanks to @richvdh for having the idea and doing the work.
