The first version will use small batch production techniques like 3D printing and small volume PCB manufacturing. On the photos, we thought it to be more appropriate to show a sketch vs a pretty AI generated photo that is true to anything yet but presents well.
Well. Color me convinced a bit. I took a little time to compare where your at now to where Ring began with Doorbot. It’s not improbable that this can take off.
I’m not a product guy. Or a tech guy for that matter. Do you have any preparations in mind for Apple’s progress with AI (viz. their partnership with Google)? I don’t even know if the actual implementation would satisfy your vision with regard to everything staying local though.
Starting with an iPad for prototyping made me wonder why this didn’t begin as just an app. Or why not just ship the speaker + the app as a product.
You don’t have sketches? Like ballpoint pen on dot grid paper? This is me trying to nudge you away from the impression I get that the website is largely AI-scented.
After making my initial remarks (a purposely absurd one that I was actually surprised got upvoted at all), I checked your resume and felt a disconnect between your qualifications and the legitimate doubt I described in my comment.
To be honest my impression was mostly led by the contents of the website itself, speculation about the quality/reliability of the actual product followed.
I don’t want to criticize you and your decisions in that direction but if this ambition is legitimate it deserves better presentation.
Do you have any human beings involved in communicating your vision?
Some of the more magical moments we’ve had with Juno is automatic shopping list creation saying “oh no we are out of milk and eggs” out loud without having to remember to tell Siri becomes a shopping list and event tracking around kids “Don’t forget next Thursday is early pickup”. A nice freebie is moving the wake word to the end. “What’s weather Juno today?” becomes much more natural than a prefixed wake word.
Agreed, while we've tried to think through this and build in protections we can't pretend that there is a magical perfect solution. We do have strong conviction that doing this inside the walls of your home is much safer than doing it within any companies datacenter (I accept that some just don't want this to exist period and we won't be able to appease them).
Some of our decisions in this direction:
- Minimize how long we have "raw data" in memory
- Tune the memory extraction to be very discriminating and err on the side of forgetting (https://juno-labs.com/blogs/building-memory-for-an-always-on-ai-that-listens-to-your-kitchen)
- Encrypt storage with hardware protected keys (we're building on top of the Nvidia Jetson SOM)
We're always open to criticism on how to improve our implementation around this.
Device should have been accompanied with a lot of examples so people are really aware how stored data could be misused. Alexa or any other similar device - their users are technically illiterate. Do you remember leaks of movie stars’ iPhone images? Multiply it by thousands… Court order, burglars, hackers - all bad actors imaginable…
For you, as producer, those situations can be a nightmare if not well described in operating conditions. And devices should not be pre-setup (don’t be “Google-evil”, as they track everything if you don’t set it up different; and it is always hidden deep in the third level menu under 2-steps verification)
> Are you okay with private and intimate conversations and moments (including of underage family members) being saved for replaying later?
One of our core architecture decisions was to use a streaming speech-to-text model. At any given time about 80ms of actual audio is in memory and about 5 minutes of transcribed audio (text) is in memory (this is help the STT model know the context of the audio for higher transcription accuracy).
Of these 5 minute transcripts, those that don't become memories are forgotten. So only selected extracted memories are durably stored. Currently we store the transcript with the memory (this was a request from our prototype users to help them build confidence in the transcription accuracy) but we'll continue to iterate based on feedback if this is the correct decision.
This is something we call out under the "What we got wrong" section. We're currently collecting an audio dataset that should help create a speech-to-text (STT) model that incorporates speaker identification and that tag will be weaved into the core of the memory architecture.
> The shared household memory pool creates privacy situations we’re still working through. The current design has everyone in the family shares the same memory corpus. Should a child be able to see a memory their parents created? Our current answer is to deliberately tune the memory extraction to be household-wide with no per-person scoping because a kitchen device hears everyone equally. But “deliberately chose” doesn’t mean “solved.” We’re hoping our in-house STT will allow us to do per-person memory tagging and then we can experiment with scoping memories to certain people or groups of people in the household.
Yes! We see a lot of the same things that really should have been solved by the first wave of assistants. Your _Around The House_ reads similar to a lot of our goals though we would love the system to be much more pro-active than current assistants.
Feel free to reach out. Would love to swap notes and send you a prototype.
> I hope the memory crisis isn't hurting you too badly.
Oh man, we've had to really track our bill of materials (BOM) and average selling price (ASP) estimates to make sure everything stays feasible. Thankfully these models quantize well and the size-to-intelligence frontier is moving out all the time.
With cloud based inference we agree, this being just one more benefit of doing everything with "edge" inference (on device inside the home) as we do with Juno.
Pretty sure a) it's not a matter of whether you agree and b) GDPR still considers always-on listening to be something the affected user has to actively consent to. Since someone in a household may not realize that another person's device is "always on" and may even lack the ability to consent - such as a child - you are probably going to find that it is patently illegal according to both the letter and the spirit of the law.
Is your argument that these affected parties are not users and that the GDPR does not require their consent?
Don't take this as hostility. I am 100% for local inference. But that is the way I understand the law, and I do think it benefits us to hold companies to a high standard. Because even such a device could theoretically be used against a person, or could have other unintended consequences.
True, we focused on hardware embodied AI assistants (smart speakers, smart glasses, etc) as those are the ones we believe will soon start leaving wake words behind and moving towards an always-on interaction design. The privacy implications of an always-listening smart speaker are magnitudes higher than OpenClaw that you intentionally interact with.
Both are pandoras box. Open Claw has access to your credit cards, social media accounts, etc by default (i.e. if you have them saved in your browser on the account that Open Claw runs on, which most people do.)
This. Kids already have tons of those gadgets on. Previously, I only really had to worry about a cell phone so even if someone was visiting, it was a simple case of plop all electronics here, but now with glasses I am not even sure how to reasonably approach this short of not allowing it period. Eh, brave new world.
They sure do and it's pretty amazing. One iteration of a vision system I worked on got frames from a camera over a Mellanox NIC that supports RDMA (Rivermax), preprocessed the images using CUDA, did inference on them with TensorRT, and the first time a single byte of the inference pipeline hit the CPU itself was when we were consuming the output.
We're a Wealth Management platform and advisory firm (RIA) that helps high-net-worth individuals and families achieve their financial goals. We're looking for a Senior Typescript Fullstack Engineer (over-weighted towards the backend) to join our Client and Advisor Product team. We just raised our Series C and you'll be joining a team of 5 other CAP engineers. We focus on lean teams that lean on functional programming to move fast and still act like a Series A company.
You'll be working on a full-typescript codebase and be responsible for designing features from a blank sheet, coming up with normalized relational tables, and writing functional (imagine TS code that looks like Haskell) backend and frontend code. Some more details: https://fartherfinance.notion.site/Senior-Typescript-Full-st...
Experience in finance/fintech is a must. If your experience is in the wealth management space or trading that is a huge plus. As this is in the senior range we're looking for 7+ years of experience or some kick-ass equivalent.
Please contact adam+nov-hn@farther.com with a copy of your resume and a brief introduction. As we're a detail oriented team please include a sentence or two on your favorite functional programming idiom, yes this is my brown M&M test.
I think it's fair to call it e-paper since it's reflective. It's not e_ink_ of course, and I believe in a previous thread they mentioned it's not bistable (needs power to maintain the image).
We have some details here on how we’re doing the prototyping with some photos of the current prototype: https://juno-labs.com/blogs/how-we-validate-our-custom-ai-ha...
reply