Launch HN: Slapdash (YC W19) – A uniform, low-latency interface for cloud apps
I'm Ivan, one of the founders of Slapdash (https://slapdash.com/). Slapdash lets you work across all of your cloud apps at desktop speed, sort of like an OS for cloud apps.
We have built a uniform, low-latency data browser (kind of like Finder) as well as a unified command line-like interface (kind of like Spotlight) for the applications you use at work.
When we left our big company jobs, one of the difficult things to part with was the tooling. Companies like Facebook and Stripe build a class of tools internally that unifies all the employees and any collaboration apps, so you can find anyone or anything the company knows. Everything is just a quick search away [0]. It’s quite a useful way to work. Common questions in day-to-day work are easy to answer. What’s the history of this code abstraction? What are my colleagues working on? What’s the story with this customer?
Building such a system today means connecting people's cloud apps, because that's where most of the work is happening today. Even for a small team like us, our work spans Drive, Dropbox, Figma, GitHub, Asana, Notion, Docusign, Slack, Quip, etc.
The first thing we built was a low-latency file system for cloud apps. You connect an application like Drive, or GitHub to Slapdash and we give you a way to search and browse the data in a uniform interface (kind of like Finder). It turns your working world into a database you can easily query.
We modeled our file system as a graph and we built our architecture to match, with a focus on performance. We built an import system, which effectively solves a graph replication problem (translating the structure of the app data to the Slapdash graph and keeping it in sync). We then built a graph database on top of Postgres, added a data access layer with graph semantics, with GraphQL API delivering the data to the client.
Of course, the data we store is encrypted on disk, in-transit and in the data store. Slapdash employees can't see the contents of what we index since everything except the reverse index is encrypted. It’s not zero-access yet, but we’re building in that direction [1].
What we discovered is that by applying optimizations to how we store (sharding & colocation) and retrieve data (batching & coalescing) we could achieve an almost zero-latency [2] experience when browsing application data. As a result, it's much faster to browse Google Drive in Slapdash than in the Drive interface itself.
While the low-latency file system is interesting, we learned that being able to search and navigate is not enough utility for a single individual. People don’t search as much as they think they do, and most have their unique information foraging habits that work well-enough.
However, we wanted Slapdash to be useful for anyone, not just an employee at a big company, so we turned our attention to building a new experience on top of the file system. Our goal was to take a leap in speed with which people can control their computers. We thought this was possible because the difference in UX between desktop and cloud app environments was so acute: the desktop OS is principled, integrated and fast, while cloud apps are latency-laden and confined to crowded browser tabs.
To that end, we built the Command Bar (Command Line + Search Bar). The Command Bar is best experienced as a desktop app, where it’s invoked with a global shortcut. You can quickly search your apps, file tasks, peek at your calendar, create zoom meetings, etc: all with a couple of keystrokes. Of course, you can also write your own commands too.
In practice, it meaningfully cuts down the time you spend controlling the computer. For example, filing a task on GitHub might take 10 seconds of just navigating to the right screen, while you can start writing the task title within 2 seconds by invoking the "Create New GitHub Issue" command with the Command Bar. Things like searching for a customer record,...
70 comments
[ 4.4 ms ] story [ 125 ms ] threadDo you have a gif or video showing someone already set up with everything, and then show them solving a few problems? And maybe even a side-by-side with someone trying to do the same thing, without Slapdash?
* Open files I know exist without touching the browser[0]
* Create new issues without touching the browser
* See what my colleagues are working on[1]
* Launch Mac Apps
* Use custom commands to speed up debugging. We have commands like "Find Customer"
* Use commands to launch recurring Zoom rooms
* Open my VSCode to a specific directory to start coding
* Use spaces to organize work I'm currently working on researching
In practice, everyone uses the computer differently, so when we get people set up on Slapdash, we do something called an "ergonomic fitting". We learn how use the computer and then we match you up with the features that you would benefit from most.
[0] https://twitter.com/iKanevski/status/1261410583951204352
[1] https://headwayapp.co/slapdash-changelog/visual-search-filte...
[0] https://code.visualstudio.com/docs/editor/command-line#_open...
I have my command set up to open this URL:
vscode://file/<ABSOLUTE_PATH_TO_YOUR_DIR>
The "file" above is important, first time I set it up I missed it and it didn't work correctly.
If you use launchers like Alfred or Spotlight, you can think of it as a drop-in replacement for those tools. The difference is that Slapdash can capture not just your desktop environment, but your cloud apps (and browser) too. The benefit is similar here too, it's a faster way to use your computer.
Side-by-side is a good idea, we really should make some videos like that.
Unless I misunderstood the app while playing around with it and reading every word on your product page, it is not a _ drop-in replacement_ for those tools. Albeit, I didn't try creating my own url/launchers but if anything its functionalities seem like a subset of Alfred's abilities as opposed to a replacement.
..which was one of my primary hesitations considering this tool for adoption while playing with it. I already have Alfred, this doesn't replace Alfred, and I don't want yet another launcher to keep in mind. I could just sync all apps locally (Dropbox/Google Drive) and get the majority of the value proposition of Slapdash with Alfred.
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.
Comments on the marketing front:
Awesome tagline ("Work across..."). Much better than what's on the homepage now, about operating system for work. Monday.com is pushing the "WorkOS" thing[1] and it doesn't convey much. If it catches on and people start saying "We need a work OS!", then by all means jump on the bandwagon and catch that sweet, sweet organic search traffic. Until then it's meaningless.
Business users don't seem to like searching. It requires them to think, and to know what they don't know. I've seen this play out at many companies: Marketing creates a bunch of sales enablement content and organizes it in a central place like Drive, but the sales team just uses the same 1–3 pieces of content (or nothing at all). That's why there are a bunch of "sales enablement platforms"[2] that provide not just search but context-aware recommendations.
Every search product has this issue, which is why they all inevitably introduce suggested searches to aid with discovery, or even recommended content/actions to skip the search altogether.
The command line seems super interesting. I suggest having loads of templates for people, otherwise the blank canvas requires people to think too much and to know what's possible (you see the pattern here). Flexible and powerful products like Retool, Asana, Airtable, and Netlify Functions have paradoxically low activation and feature-usage rates unless they supply users with templates[3] or at least ideas on what's possible.
[1] https://monday.com/enterprise/
[2] https://www.g2.com/categories/sales-enablement
[3] Airtable goes a step further and lets users share their apps or discover other people's apps: https://airtable.com/universe. I imagine a bunch of your users would want the same (or similar) custom commands, so a showcase might be helpful.
PS - In the time I spent writing this, two people already commented that they need to see more use cases to understand the value, thus validating my point above about not making people think.
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.
Would you guys be open to providing a self-hosted solution for large clients?
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.
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.
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.
I tried signing up, but receive no confirmation email to jmechtel posteo.de
One way to unblock is to sign up with a Google account (which won't require the email verification).
Otherwise, feel free to email me (ivan@slapdash.com) and I can help confirm your account.
The onboarding is a bit weird as i don't really know what i want to use this for, i guess creating github issues, but then i got distracted between installing the desktop app and trying to read the "get started".
Also i still don't really understand what "spaces" are supposed to be?
When creating github issues the first thing i wanted to do is create a command, that would include which repo i want the issue to be for.
But looks like I can't extend the existing commands, that would be cool.
Let's see how this work day to day, we are a microsoft shop. Some of the use cases I'm looking for:
- open meeting scheduler with these people - launch a zoom call to that guy (if he is available) - create sharing links for the currently opened document
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.
I was curious, can you speak to how this differentiates from https://getcommande.com/?
* 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)
What's the process around adding new apps? Would one be able to integrate easily?
I built Quest https://github.com/hverlin/Quest during the lockdown to search content across several apps (Gmail, Jira, Confluence...) as I could not find one that would allow me to do this.
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.
You can actually download a linux build from: https://download.slapdash.com/
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.
Isn't this exactly what xdg-open does?
https://wiki.archlinux.org/index.php/Xdg-utils
https://askubuntu.com/questions/527166/how-to-set-subl-proto...
I suppose if you want to support text mode (ie use from mutt without running a gui) - you'd have to use mailcap - but that assumes the login flow works in a text mode browser like w3m...
I am no expert, but as far as my experience goes, an app registers a URI scheme with the system, and then it is as easy as 'xdg-open scheme://stuff's life e12e said.
We still have some fit & finish things to improve upon, but it should be quite functional.
We are new to this, so don't hesitate to reach out with suggestions, we're still learning.
I declined once I noticed that most other people at the company came from an NSA/FBI background.
People with an intel background doesn't make it an NSA op. The NSA grabs top talent all the time, and companies grab them when they leave.
Im curious how you spotted the spooks :)
Exciting stuff, web interfaces can suck.
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.
Do you support local installations of the listed products, specifically Gitlab and Jira? If not, any plans to work that out?
Certain products have a desktop app counterpart. For example, Notion, Trello, Figma, etc.
Slapdash is aware of those applications and when possible will opt to open things inside the desktop app vs a browser tab.
Seems like there should be a "talk to your security team" disclaimer... people get fired for granting access like that.
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.
A pen test costs half the monthly salary of an engineer, so it’s an easy investment to rationalize on a quarterly basis.
[1] https://emvi.com/blog/a-new-experimental-user-interface-QMZg... - it looks different than in the article, as it has changed quite a bit in the past few months
Just a quick note: the GitHub connect page asks whether it should index the private repos or not, but when I try to connect my account even after I disable it the oAuth page says that you'll be able to read and write to the private repositories, which seems to contradict with what I assumed I'd achieve by turning that flag off.
But this particular GitHub case seems to be different. So it's fixed.
Couple of very minor FYI's i've noticed on the macOS app:
- on logout the ui redirected to a text 'error' screen (no ui / obvious blip) .. had to quit. The webui worked as expected redirecting to the homepage. I'd initially signed in to the wrong email account.
- When 'app visibility' is set to 'Just in menu', cmd+j-ing into the command bar causes the app to reappear in the dock and needs to be (x)'d again.
I'm ready to pay.
By the way, you can override the shortcut in Preferences (see "Global Command Bar Shortcut"). For instance, I changed my shortcut to CMD+SPACE (I already had a muscle memory for this shortcut since before I used Spotlight on Mac OS).
In my earlier job we had several repos and being new to the job, I had to search often to understand how a particular logic is handled. sometimes the search will lead to a doc or internal wiki.
I had tried getFYI but I am much faster at typing than browsing.
Also the command line looks useful too. Do you allow custom tasks? Like I do SSH often on the servers to check logs. I would love to do all of it in one go:) You could do something similar to visual studio build config.
Good luck.
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.