We have built a low-latency file system for your cloud application as well as the fastest interface in the world - the Command Bar - to interact with it. It's a new type of type of tool that makes modern computer work less tedious and more fun.
We are hiring for three engineering roles:
* Infrastructure Engineer - build infra that turns cloud apps into a low-latency database
* Product Engineer - build brand new ways for people to get things done with a focus on speed
* Partner Engineer - build integrations and custom commands to make our partners successful
We have an incredible development stack, all in Typescript, that lets us move incredibly fast. A small, but incredible team of very talented engineers. And, the product we're building is also something we all love and use.
We have a great technology stack with an emphasis on speed and dev experience (heavy on Typescript).
We are currently in need of a lead product designer as well as a product-focused engineer. If you're curious to bend the physics of what's possible with cloud applications and want to be at the vanguard of HCI, please reach out!
You are right - the “control-your-computer” functionality is currently a subset of Alfred, but we are working on bridging that gap.
Most people use Alfred in limited ways, and we tried to cover those hot paths. However, we are still working on covering the long tail of that feature set.
That's a really neat idea to be able to search logs quickly.
We definitely support building custom commands, but they are super limited today. We have to build the sophisticated commands ourselves. However, we will be opening up our toolkit, so if you have ideas on dev ex of building a command or how you would want to rig them up, feel free to reach out.
Feel free to shoot me an email (ivan@) if you want to brainstorm some commands and how they can work.
Quest looks cool. I just downloaded and started playing with it - well done.
Today, we write the integrations ourselves.
We will eventually open up our APIs so people can build their own integrations to extend Slapdash. If you have ideas or thoughts on what would be a good dev experience, feel free to reach out.
We don't take security lightly, but we don't do a good job articulating how we safeguard things in the product. We'll fix this - thanks for pushing on it.
There are details throughout this post, but I will summarize our high-level approach.
* When we request permissions, we request a minimal set. For example, you can connect Drive with just meta-data access and our access will be scoped accordingly.
* Everything is encrypted. Importantly, it's also encrypted in the data store itself. If our DB was compromised, the entries would not be readable (ECIES, Secp256k1, AES256+CTR). Only exception is the reverse index.
* The operations that involve encryption / decryption of encrypted content live in an isolated layer.
* Token storage follows similar methodology
* We get a pentest and security reviews quarterly
* We also have strict company policies around IT and infrastructure access
That said, we aren't ever at a terminal point in our security story.
Our experience has been that security conscious companies simply turn off ability to connect third party applications.
The reason some apps are not removed after you connect them is that you can connect more than one account. For example, you can connect multiple G-Drive accounts.
That said, it's definitely confusing in its current form, so thanks for highlighting it.
The apps you suggested are definitely within reach (except for maybe Signal). We don't integrate any CMS's yet, but I think it would be quite helpful, especially for folks who tend to interface with them a lot.
Our onboarding is quite under solved, thanks for putting up with it.
If you think of Slapdash as sort of an OS, today Spaces are kind of like folders. You can build them manually, or with rules (a saved query). It's a means of organization -- which is complimentary to the problem of information retrieval. It also lets you add arbitrary things to the Slapdash graph (any URL) - which helps with making Slapdash more comprehensive outside of the apps we have coverage for.
You will certainly be able to extend existent commands. We are in the process of exposing our command-building primitives so custom commands can be as sophisticated as the ones we write.
We will improve coverage with the MSFT stack, and the use-cases you mention (launch a zoom call with a person, schedule a meeting with a person) are actually right around the corner.
The one thing we have left is fixing auth. We auth in the browser and then open the desktop app to pass the auth tokens to the desktop client. However, this hand off is more difficult to achieve with Linux (can't just open slapdash:// URLs as easily as you can on OS X and windows).
There is a work around hack, where if you can get the auth token from the browser and manually add it to Slapdash.
The steps are: Open Chrome Dev Tool Console right inside the desktop app (F12 or Shift+Ctrl+I) and run something like:
location.hash = "#/lt?token=..."
We will of course build a more person-friendly UX before we make the linux client more widely available.
Both Slapdash and Command E can search apps, but Slapdash can do other things too:
* You can also write to applications, it's not just read-only (create docs, file issues, close tasks, upload files, etc.)
* You can browse the structure of applications in Slapdash (not just search them).
* You can build sophisticated queries (show all tasks open tasks, that mention this customer, render it as a list)
* We are client-agnostic. While we love our desktop client, you can also use Slapdash just in a browser window, or as a Chrome extension (and soon mobile).
* You can control your desktop computer too (launch apps, search local files, etc.)
* You can build your own custom commands and share them with others (this turns out to be quite fun)
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.
At the moment, the easiest way to unlock functionality is to connect an app. We will be building a lot of the interesting commands to start, so there should be no work required and should help the "blank canvas" problem.
However, custom commands are quite powerful, but we don't do a good job showcasing what they can do and how you can create them. Our team, for example, has a set of shared commands which streamlines a lot of our day-to-day work, but it's unclear to other what might be good commands to create.
Improving the command building experience and complimenting it with templates is definitely at the top of our list of things to improve.
We have built a low-latency file system for your cloud application as well as the fastest interface in the world - the Command Bar - to interact with it. It's a new type of type of tool that makes modern computer work less tedious and more fun.
We are hiring for three engineering roles:
We have an incredible development stack, all in Typescript, that lets us move incredibly fast. A small, but incredible team of very talented engineers. And, the product we're building is also something we all love and use.