Thanks for the kind words! We're collecting feedback over the next 1-2 weeks to prioritize the road map.
Is there anything that you would like to see?
A few things that are on our radar though:
- Support for more APIs out of the box. We've implemented a number of APIs that we've submitted for approval (including a bunch of google APIs). They should be added in the next few weeks.
- The ability to add your own API integrations via a simple form if we don't support them (both token based and OAuth APIs).
Long answer: As you may know, Samsung Health doesn't provide a public REST API. We are looking at different ways that we might be able to make that information available through the Google Fit API though (Samsung does allow their app to share data with Google Fit).
Everyone has trouble accepting criticism to some degree or another. I've found that with younger engineers this is some amount of imposter syndrome that can express itself in different ways. One way I've found to break through is to highlight all of the positive things I notice in a PR. Even if it's something that should be expected (eg. "Thanks for writing this test!") the positive re-enforcement helps with confidence and softens the blow when you do point out some areas for improvement.
Could you speak to security of information that I allow Slapdash to access? I'd be very interested in using this, but how do I know the sensitive information that I give you access to is secure?
No much magic here, we use pretty standard protocols and approaches for security.
The data stored is public-key-encrypted (buzzwords: ECIES, Secp256k1, AES256+CTR), and the decryption private keys (per app/user) are available only to the very last and isolated layers (e.g. in particular, right before the search snippet is sent to your browser, or right before the text is tokenized and converted into an inverted index which erases the information about the actual words location in the text). The engineers can’t see the users' data.
App access- and refresh tokens (which we obviously need to send API requests to the apps you connect) are stored the similar way. They’re only decrypted in a separate layer right before requests are sent to remote cloud apps' APIs.
We will publish a comprehensive overview of our approach to security, which I'll link to this thread for posterity. Frankly, we just ran out of time to publish this in time for the launch.
To compliment our architecture, I should mention we also also have strict company policy around general IT security and any type of customer data access. Security is an evergreen problem here.
We are definitely open to a self-hosted solution, but at the moment we have a small team, so we are trying to keep our engineering surface area manageable.
In the near future, we will be offering deployment to an isolated instance. It would be operated by us, but we would be able to provide infrastructure access.
A step after that would be to offer VPC deployment where the updates are applied by the customer and we wouldn't have access to the infrastructure.
I'm building a fitness tracker specifically for rock climbers using RFID in addition to the regular fitness tracker sensors (accelerometer, altimeter, etc). It started as a project to teach me lower level embedded programming (I do web dev for my day job). Since then it's expanded and we're actually testing it at a local rock climbing gym. If you're curious you can see a demo video here https://www.youtube.com/watch?v=6gnEAeMDKt8
I wish we could use NFC on an Apple watch. It would have saved a lot of trouble. Unfortunately the read range of NFC is too short to work on a climbing wall. The climbers wrist will sometimes be up 12+ inches away from the closest point on the wall. This was the challenge that I ran into with our first prototype.
As for moat, I think we have some patentable IP (another potential large cost to file for that patent) and because our model hinges on a relationship with the climbing gym, the big guys would have to establish a salesforce to sell into these gyms, which I think for the size of the market would not be worth it for them. If we can solidify a decent market share it would probably be more likely that they'd try to buy us out rather than fighting for those relationships, but I'm not certain about that.
You might want to consider alternate technological approaches. Have you considered using an IMU to deadreckon the route and detect rests and falls? I think this would be an perfect application. Then you wouldn’t need the rfid tape. You could also probably use an existing 3rd party hardware. I think developing the hardware and managing its production will kill you in the end. Plus, who wants yet another doodad to buy and wear.
Another possible method is to use computer vision and video to capture the climbers motion.
Is there anything that you would like to see?
A few things that are on our radar though:
- Support for more APIs out of the box. We've implemented a number of APIs that we've submitted for approval (including a bunch of google APIs). They should be added in the next few weeks.
- The ability to add your own API integrations via a simple form if we don't support them (both token based and OAuth APIs).