Feature Request for offline decoding options

[ModerateIdeas]

Great project, love functionality! After working through some use cases I have some ideas, if we are thinking about long term storage and recovery:

1. Include manual instructions to recover secret if unable to access Banana Split (Some combination of scrypt and ssss-combine maybe)

2. Include the decode page as QR codes that can be scanned in at recovery time if the project page is not available?

[kirushik]

@ModerateIdeas maybe you can elaborate what do you mean by "unable to access Banana Split" and how would a person get access to scrypt and ssss-combine in this situation?
I mean, BananaSplit is basically a standalone html file which can be run from your own computer, uploaded to IPFS, sent to a friend over email, copied to a USB stick etc.
The source code is publicly available and can be forked/cloned/republished as well.
What scenario do you have in mind in which the user would get access to other tools but not to the BananaSplit specifically? How would a user get access to our instructions in this case?

[ModerateIdeas]

Suppose that you store some long term valuable information with Banana_split that gets stored for a years, or decades. At some point you need to recover, or your heir's will need to recover. They might not have access to Banana_split, github may have had a major crash/gone out of business, archive.org may not have indexed it, bitrot and availability of online tools is a real long term problem at decade scale.

I do appreciate this is unlikely given IPFS, backups, and the like.

[kirushik]

Well, my mental model for BananaSplit is for it to be the opposite of the "online service" — I'm pretty aware of those things' long-term unreliability.

That's exactly the reason why 1) we've picked HTML+JS as a platform to develop on (your browser typically can render the pages from 1998 without major issues, but have you tried running an app from 1998 without an emulator on up-to-date hardware/OS?)
And that's also why BananaSplit explicitly refuses to work when hosted on the web, requiring you to download it and reopen a local file.

I totally understand the desire to have a documented cryptoscheme (and maybe some compatible re-iplementations? We're working on embedding one into Parity Signer via https://github.com/paritytech/banana-recovery-rust right now, for example).
But this is more of a "compatibility and turning BananaSplit into a protocol" thing, less of "ensuring that the project survives the nuclear war" — after all, how are you going to read that document in case of such event? How are you going to access ssss or other tools, which are not even built with the same "should work in 20 years" goal in mind as the regular BS self-contained html file?

In addition to that, as a part of #32 we are likely to have another version bump in the cryptoscheme we're using — and it's probably would be even less compatible with ssss than the current one.
Of course BananaSplit will retain backwards compatibility (you being able to decode any past formats with the most up-to-date BananaSplit version is an important guarantee we aim to provide), but such third-party recepies will definitely suffer.

All in all, I suggest you making a backup of the version of BS you've used to split your secret without any delays, and picking any future-proof mediums of your choice to store that — my suggestion would be archive-grade CD-R disk, but it's pretty risk-model-dependent.