Thank you for your answer Kathy.
I look forward with great interest to MyCroft breaking the leash to third parties and the WAN. I hope it happens soon.
Some observations / ideas for MyCroft:
anonymise STT requests - we are currently using a cloud STT provider while we work with Mozilla to try and bring DeepSpeech STT to the local device
In this regard, I’d much prefer to type my requests in at a local console (presumably a computer on the LAN) than be required to access a remote STT capability. Just as a suggestion, MyCroft might want to consider a module that 100% stands in for the STT at the keyboard. This would provide a wedge where any LAN-based skill can run without having to go out on the WAN with all its downsides. Perhaps there already is such a thing? If not, surely it would be a minimal project to undertake.
Skills that require WAN access (beyond the STT layer) could (should!) be flagged as such in the marketplace, and MyCroft would then be able to triage such skills based on a user preference for local operations. MyCroft devices should be able to completely disallow access to the WAN as a straightforward matter of user security.
Additionally, small systems that do general STT with low resources have existed for some years now; for instance, my handheld Garmin GPS, purchased around 2012, understands me reasonably well and pulls that off with nothing but a battery which lasts all day while also running the GPS receiver and display. No doubt these solutions are carefully guarded secrets by companies such as Garmin, however, the fact remains that it proves that it does not require a lot of computing power to do reasonable STT. Getting from here to there… that, of course, is the trick. Solutions that require lots of horsepower and a GPU are, to put it gently, suboptimal. Hopefully this will come about sooner rather than later.
provide account information - such as name, location etc.
Clearly, if the system is being run locally, there is no need for “an account” anywhere but at home. So this is a non-issue, other than providing for secure local storage of such information.
reach third party API services - several Skills leverage third party API services
If the WAN is not available, WAN APIs are not available either. There are two reasons the WAN would be unavailable: first, it may be down. Second, it may be disallowed. For instance, I have no interest whatsoever in WAN-based capabilities / requirements. What I am interested in is building open source skills that leverage 100% LAN-resident capabilities. Skills such as controlling local devices, reading local sensors, keeping local databases of shopping, to-do and other lists; that sort of thing.
Those of us who are knowledgable are well aware that data transiting the WAN cannot be guaranteed to be secure; third parties are absolutely unpredictable as to being trustworthy, as any organization may already have, or eventually incorporate, black hats operating sub-rosa or even right out in the open as is already the case at Google and Amazon; and the WAN itself is unreliable - it may simply not be available when the digital assistant is needed. Breaking the dependence on these factors is my #1 priority when it comes to digital assistants.
our intent with the personal server is to scale this down to be fit for scale for personal use.
I hope this project sees the light of day very soon. As I mentioned above, an easy start could be made entirely without STT; it seems there’s very little remaining to do beyond that. I hope MyCroft will seriously consider this.
That’s all for now. Thanks again for the quick response. Good luck with MyCroft!
I did not volunteer. It’s not my project. Yet. But I would be happy to put my shoulder to the wheel here as soon as the project doesn’t require the LAN it runs within to be hooked to the WAN in any way.