Rather than persisting user sessions (e.g., UI state) using a traditional method such as cookies, with SAFE all non-volatile data generated by or for a user should be owned by the user and usable in a predictable manner.
For a Rust/wasm web app in the SAFE Browser environment, what workflow and API should be used to persist/restore a user’s session file? The session file would be created by the web app, on behalf of and in response to a request by a user, for the purpose of automatically restoring the user’s web app session state after reopening the web app.
In addition to the write/read primitives, what API should be used for SAFE Browser to prompt the user to allow the session file to be written/updated?
2 Likes
Right now we’ve only got the APIs for pseudo filesystem in place in the exposed APIs (more appropriate data structs are coming, though).
You could use the files container APIs to make a folder in a deterministic location (or via nrs), and store JSON for now: sn_nodejs/native/src/lib.rs at master · maidsafe/sn_nodejs · GitHub
Right now, when you prompt for authorised app creation, the user will be prompted to provide permissions for read/write.
@Shane has previously created Phantom, which is open source and may be worth having a look at in terms of safe connectivity and data persistence as things stand.
1 Like
@joshuef
With the work on Safe over the past year, what’s the current state of this? I’m ready to test Safe Browser app read/write user data as soon as the new testnet is live.
1 Like
Hey @anon78698497, good to hear you’re ready and waiting!
A basic browser udpate should not be a massive undertaking. safe node will need udpated with new apis. But that mostly just updating args. And with in browser it should hopefully work without too much fuss (famous last words).
That said, we’ve not started there and aare still stabilising things. But I do not foresee a working basic browser taking much longer once we have things stabilised for the testnet.
4 Likes