ImmortalDB Disable cookie store by default.

I'd suggest disabling the cookie storage option by default, making it opt-in.

amount of storage for cookies is more limited,
every cookie set is sent to the server on every request
- increases transmission overhead
- increases server-side time spent loading/parsing cookies

Oct 28 '18 21:10 tracker1

All sensible suggestions.

I tried to find a workaround for this particular aspect

every cookie set is sent to the server on every request

without success. When a cookie's path parameter is set to an esoteric path to obviate transmission to the server, like /c2eb2183ba25438d99e309dddcd8f3c6, that cookie also becomes unreadable on all other paths, too. In short, I couldn't figure out a way to both set, and read, a cookie and simulateously avoid transmission of that cookie.

Are you aware of any clever techniques that forfend transmission to the server?

Now, if you'll indulge my curiosity, what kind(s) of data do you wish to store in ImmortalDB? In turn, the kind of data stored connotes the storage requirements. E.g. bytes vs kilobytes vs megabytes, etc.

If the majority of ImmortalDB users want to store order of magnitude megabytes+ therein, it indeed makes sense to consider the removal of CookieStore from ImmortalDB's default data stores.

Dec 04 '18 18:12 gruns

My use case is to store base64 images locally. I never want to send that to the server. Another reason is for security. I want to build a local-only app. Nothing on the server.

The docs aren't clear on how I can instantiate a DB omitting cookies. I would expect something like this:

var db = new ImmortalDB({
  storage: ['IndexedDB', 'LocalStorage', 'SessionStorage']
});

I don't transpile my code. I want to use the .min.js file directly. Can I do something similar?

Jan 28 '19 20:01 martindrapeau

The docs aren't clear on how I can instantiate a DB omitting cookies.

I don't transpile my code. I want to use the .min.js file directly. Can I do something similar?

Absolutely. Here's how you can accomplish exactly that:

<html>
  <head>
    <script src="immortal-db.min.js"></script>
    <script>
      ;(async () => {
        const stores = [ImmortalDB.LocalStorageStore, ImmortalDB.IndexedDbStore]
        const db = ImmortalDB.ImmortalStorage(stores)

        await db.set('hi', 'lolsup')
      })()
    </script>
  </head>

  ...
</html>

Live example: https://codepen.io/anon/pen/LqZvgy?editors=1001#0.

Does that answer your question, @martindrapeau?

Jan 29 '19 01:01 gruns

I'd suggest disabling the cookie storage option by default, making it opt-in.

A fair compromise could be: by default, ImmortalDB's data stores don't include CookieStore; instead just IndexedDbStore, LocalStorageStore, and SessionStorageStore.

Then, a new, brother instance of ImmortalStorage -- what ImmortalDB is an instance of -- would be exposed globally that does include CookieStore. This instance could be called ImmortalCookieDB, or similar.

Users would then have a choice:

ImmortalDB: More storage, less redundancy, and free from the caveats of cookies (network transmission, max 4096 bytes per value, etc).
ImmortalCookieDB: Less storage, more redundancy, but subject to the caveats of cookies.

Users would, of course, remain free to instantiate new ImmortalStorage objects with whichever permutation of data stores they so desire, a la

import { ImmortalStorage, CookieStore, LocalStorageStore } from 'immortal-db'

const stores = [CookieStore, LocalStorageStore]
const db = ImmortalStorage(stores)

What do you guys think?

Jan 29 '19 01:01 gruns