4 ms·

Maybe it is a poor example, but I don't understand how IndexedDB and WebCrypto have anything to do with a distributed chat system like Slack. For a system wher

Maybe it is a poor example, but I don't understand how IndexedDB and WebCrypto have anything to do with a distributed chat system like Slack. For a system where I can join a channel at any time and see what's been said in the past, the information has to live on their servers and be readable. Even more so if you want to be able to search for something someone said across your entire Slack account. You aren't going to have all of that data local to your machine and browser.

javajosh 10y ago
* I don't understand how IndexedDB and WebCrypto have anything to do with a distributed chat system like Slack* Uh, what? The OP didn't mention Slack at all. I mean, you could make this kind of...comment on anything: "What does X have to do with Y?" (In this case, X=(WebCrypto & IndexedDB) and Y=(Slack)). But it's not very useful.
- jameskilton 10y ago
  Check out the screenshot in the article of the conversation with @SlackHQ.
- eridius 10y ago
  The article had a very prominent image of a tweet from @SlackHQ about the lack of encryption at rest - https://cdn-images-1.medium.com/max/1400/1*OBXEceCpTP4jUeTZuRrC_A.png https://cdn-images-1.medium.com/max/1400/1*OBXEceCpTP4jUeTZu...
  - javajosh 10y ago
    Yes, you're right. I missed it. I guess he's making a point about wanting his own chat history searchable on his client, and yet opaque to the server-side Slack operators. I agree it's not a great application, though.
phpnode 10y ago
They don't want to send down the entire message history every time you switch to a particular conversation window, they want to be able to store as much of that locally as is possible/sensible so that the user doesn't have to wait for a network round trip and it still mostly works offline. They would like to store these messages in IndexedDB but they would like to encrypt them first.
- paulddraper 10y ago
  Browsers have had HTTP caches for decades. But yeah, IndexedDB is nice too.
  - Klathmon 10y ago
    HTTP caches are great for their intended use case, but when used like this they have a lot of limitations. You can't rely on them existing, having space, or keeping your data for any real amount of time. You can't process the data before it hits the cache, you can't clear them easily, and they are iffy at best when offline.
    - paulddraper 10y ago
      > You can't rely on them existing, having space, or keeping your data for any real amount of time In other words, a cache.
      - Klathmon 10y ago
        Yes, but a cache with zero reliability isn't very useful. If I do an expensive operation, then need to use its result later, I can't rely on the HTTP cache as the browser may never have cached it in the first place, or may have evicted it by the time I go to use it. So using that unreliable cache can actually make things worse in the sense of more data usage, more power usage, more battery usage, and more memory usage. For a real world example, say I wanted to pre-fetch a bunch of data on page-load, then in a later page I want to use the cache to be able to quickly get that information and use it without any latency. If I had some control over the HTTP cache, I could do this. But as it stands right now, I can try to make a GET request on the page load, but when the user clicks the button to see the result on a later page, it's a crapshoot on whether or not the HTTP cache will still have it, leading to the user having to wait sometimes, and not other times, duplicated requests, and a lot more data usage. With localstorage, IndexedDB, WebSQL, etc... I have that control. I can know that the information is going to stay there until I need it so I don't need to worry about my caching making things worse.

javajosh 10y ago

* I don't understand how IndexedDB and WebCrypto have anything to do with a distributed chat system like Slack* Uh, what? The OP didn't mention Slack at all. I mean, you could make this kind of...comment on anything: "What does X have to do with Y?" (In this case, X=(WebCrypto & IndexedDB) and Y=(Slack)). But it's not very useful.

jameskilton 10y ago
Check out the screenshot in the article of the conversation with @SlackHQ.
eridius 10y ago
The article had a very prominent image of a tweet from @SlackHQ about the lack of encryption at rest - https://cdn-images-1.medium.com/max/1400/1*OBXEceCpTP4jUeTZuRrC_A.png https://cdn-images-1.medium.com/max/1400/1*OBXEceCpTP4jUeTZu...
- javajosh 10y ago
  Yes, you're right. I missed it. I guess he's making a point about wanting his own chat history searchable on his client, and yet opaque to the server-side Slack operators. I agree it's not a great application, though.

phpnode 10y ago

They don't want to send down the entire message history every time you switch to a particular conversation window, they want to be able to store as much of that locally as is possible/sensible so that the user doesn't have to wait for a network round trip and it still mostly works offline. They would like to store these messages in IndexedDB but they would like to encrypt them first.

paulddraper 10y ago
Browsers have had HTTP caches for decades. But yeah, IndexedDB is nice too.
- Klathmon 10y ago
  HTTP caches are great for their intended use case, but when used like this they have a lot of limitations. You can't rely on them existing, having space, or keeping your data for any real amount of time. You can't process the data before it hits the cache, you can't clear them easily, and they are iffy at best when offline.
  - paulddraper 10y ago
    > You can't rely on them existing, having space, or keeping your data for any real amount of time In other words, a cache.
    - Klathmon 10y ago
      Yes, but a cache with zero reliability isn't very useful. If I do an expensive operation, then need to use its result later, I can't rely on the HTTP cache as the browser may never have cached it in the first place, or may have evicted it by the time I go to use it. So using that unreliable cache can actually make things worse in the sense of more data usage, more power usage, more battery usage, and more memory usage. For a real world example, say I wanted to pre-fetch a bunch of data on page-load, then in a later page I want to use the cache to be able to quickly get that information and use it without any latency. If I had some control over the HTTP cache, I could do this. But as it stands right now, I can try to make a GET request on the page load, but when the user clicks the button to see the result on a later page, it's a crapshoot on whether or not the HTTP cache will still have it, leading to the user having to wait sometimes, and not other times, duplicated requests, and a lot more data usage. With localstorage, IndexedDB, WebSQL, etc... I have that control. I can know that the information is going to stay there until I need it so I don't need to worry about my caching making things worse.