Safe will be very fast because the blocks will all come from different vaults so the “server bandwidth” is enormous. Loading data from the disk cache is faster still. Are there plans to include local block cache functionality in the client libraries?
If the cache files and their addresses are encrypted by a key that is stored within the Safe account then it’s impossible to break the cache unless the account is broken first.
Looking beyond a simple LRU cache, this could be the first step towards a secure offline mode. I could instruct my browser to cache a movie file for a transcontinental flight, or my music player to cache a playlist, or maybe I want to have some other documents at hand at all times.
At that point, doesn’t it make more sense to just copy to your local drive?
Building an “offline mode” into the launcher seems like a lot more work than building an app that can ping files you want to look for changes and copy those to local drive.
Edit: I missed the “secure offline mode” part. While I still think an app with self encryption built in makes more sense, I do see where you’re going with this.
Yes, encryption is the important part about the offline mode. However, a full offline mode is different than a simple LRU cache, that would also be useful.
Would you really suggest all apps that want this functionality should roll their own encryption?
Absolutely not. I would suggest they pull from the safe libraries. Or possibly making making a “safe_offline_lib” with all the API calls from your app to do it.
The launcher is the pin that secures you and your data from the outside world while in the safe network. The simpler the code and less reading/writing to local fs that happens in there the better.
Simplicity is important, but so is performance. I add caching to scripts I write all the time. Does this sound complicated?
If an immutable block exists in the cache, load it from there and move it to the front of the list.
If the network is inaccessible, try the cache for mutable blocks as well.
If the block is not in the cache, load it and store it. If it was flagged to be pinned, mark it as such and (maybe) store which app requested it.
If we would go over the limit, throw away the oldest block that isn’t pinned for offline use first.
Maybe. This was my first idea too, before I saw not only caching but offline mode could be done very simply.
An app will need a GUI to pin or unpin documents from the cache but the core could handle the rest.
Core will need a keep_in_cache flag for download calls, and an additional call to remove the pin. If we store which app requested the blocks for offline use, all pins from a certain app can be removed, for example when the app is uninstalled.
I would think that this is a “client code” side implementation. There does not seem to be any need to modify the network core code in order to implement this.
Once SAFE is running then there will be custom clients written that provide extra functionality for the users. You do not need to run *official* client code. Just as long as it does whats needed then you can add all the extra features you want to the client code
Yes, client side. Hence the title of the thread. I thought requesting blocks from the network is a core functionality, but I’m not familiar with the structure of the libraries so maybe I used the word “core” wrong.