In the world of software, never give out dates (right Stan?
). I learned that lesson 30 years ago. Obviously though Thom, I took your comments very personal, so I sincerely apologize for my knee-jerk reaction. I am building things that have never been built before, so it's a bit tough to even hand out any timelines. I am well aware of what needs to be done, nobody has ever had to ask me for updates, and I do my best to detail our roadmap and progress right here on this lovely forum every week, so nothing more.
Apology accepted. I sincerely hope you realize I'm only trying to open discussion and understand where we are in this process. I am very glad to see the screenshots; you know what they say, a picture is worth a thousand words. They will help a lot for marketing.
Like I said tho, I'm not a marketer, let alone a professional one. My role at this point is simply to gather as much information as possible. Once enough info is known about how your "true and complete" stealth will work (at say a 1000 foot level) then some type of early marketing might be possible. You have provided the 100,000 foot view of how stealth will work, and the contrast of that view to the existing blinded transactions is quite dramatic.
Differences of perspective will always be present, so we all need to learn to work together without alienating one another. It serves none of us if we become divisive and locked into a "my way or the highway" mindset (not saying you're doing that ken).
Regarding the changes your making to the backend code. Those are what dictate whether a hardfork will be required, and IMO should be done very carefully. I agree with you ken, that the existing backend will require changes to implement a deep stealth that hides everything and also provides a backup mechanism for grandma's declining memory. If you can implement your true stealth without touching the existing blinded stealth code it will reduce the impact on testing and avoid issues with anyONE who might be using the old cli stealth code. I frankly don't see how you can avoid a hardfork to roll out your stealth, as it can't be accomplished in the UI / frontend codebase alone. How much of an impact your changes will have on existing operations is the key factor on how much testing will be required. You will also need to make changes (or at least additions) to the API so the UI can access the new stealth functionality.
Could the c-ipfs functionality for the backups be implemented in the frontend code only or will it require backend support as well? I ask b/c if the original wallet was completely stored in the browser I could imagine a direct interface between the UI code in the browser with IPFS, tho it would require porting the c-ipfs over to javascript.
As to when / if a spec will be required to facilitate a release that is up to the shareholders. None have been required in the past, so why should changes for stealth be any different? However, I tend to agree with xeroc's perspective that specs are very useful as a way to characterize functionality and as a tool to help insure test coverage is thorough. Writing a good spec is no guarantee of a successful product, and they do require time to do well.
IMO there are many aspects to the process of code development that could be improved greatly, both frontend AND backend. We will have to come to some type of consensus on what is and is not acceptable minimal standards for the future. I myself would like to see more specs, story boards and use cases as early in the development process as possible.
That is one thing the worker proposal system provides, a type of spec for work to be done. How loose or tight a proposal is and whether it meets minimal standards of acceptability are in the hands of the shareholders. I recall voicing my concerns about Bytemaster's stealth proposal not being adequate and turns out those concerns were valid. Since you have raised your own funds
@kenCode the shareholder approval process is moved from the start to the end of the engineering phase, actually all the way to the final deployment phase. I would hate to see all your hard work go to waste due to a failure to convince shareholders of the soundness and reliability of your changes.
Anyway, looking forward to a view out the window that becomes clearer as we descend from 100,000 feet down to the ground. I have complete confidence in your abilities
@kenCode to avoid the clouds and pilot this thing all the way down to the users on the ground.