[HN Gopher] Launch HN: Slapdash (YC W19) - A uniform, low-latenc...
___________________________________________________________________
Launch HN: Slapdash (YC W19) - A uniform, low-latency interface for
cloud apps
Hello HN, 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, doing a quick spreadsheet
calculation and even routine things like opening an existing
document are measurably faster. [3] For teams and companies,
Slapdash provides a unified interface to a team's collective
knowledge. This has traditionally been reserved for top technology
companies, but we are bringing these advantages to everybody else.
And for the individual, we are making the use of disparate cloud
apps feel closer to the classic experience of a desktop computer OS
- fast, integrated and more productive. We are still figuring out
what apps to support, what commands we should build and how we can
open up the platform for others to build on as well. We would love
to hear from you on any of those counts and any feedback you might
have! [0] Facebook has something called "intern" and Stripe has an
internal product called "Stripe Home". [1] Content is stored using
ECIES (with Secp256k1 curve and AES256 cipher in CTR mode), public-
key-encrypted with individual per-user, per-app key pairs. [2]
It's actually not zero latency, of course, but by preloading most
things on the hover state we can cut ~50ms of perceived latency (as
long as the server response time is under that, which we try to do,
it feels instant). [3] We use the keystroke-level GOMS model to
evaluate interface speed, but the speed difference here is large
enough that it can be intuited. Example of filing a task on
GitHub: Time controlling computer: open browser, command + L (
focus location bar), type partial URL of repo until it auto-
completes, wait for page to load, click on Issues, wait for page to
load, click on "New Issue". Expressing actual intent: typing title
of task. Filing a task with Slapdash: Time controlling computer:
Type Command + J, type "Cre gi" to fuzzy match "Create New GitHub
Issue" command, hit enter. Expressing actual intent: typing title
of task.
Author : kanevski
Score : 152 points
Date : 2020-09-03 15:13 UTC (7 hours ago)
| shay_ker wrote:
| This sounds interesting at a high-level, and the octopus is cool,
| though I'm having trouble understanding how it'd impact my day-
| to-day. There's a gif on the homepage on how to... add to a
| "space"? I'm not totally sure what value this would bring to me.
|
| Do 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?
| orliesaurus wrote:
| Also came here to ask to see more examples of day to day
| usecases!
| kanevski wrote:
| Here is a sampling of ways I use Slapdash daily.
|
| * 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...
| kanevski wrote:
| For folks that use are comfortable with using the keyboard, we
| recommend installing our desktop application. The desktop
| application adds a global shortcut (Cmd + J) by default, which
| you can use to pull up Slapdash.
|
| 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.
| [deleted]
| gk1 wrote:
| This looks amazing. Coincidentally, I was just looking at the
| Slapdash page in Zoom's app marketplace.
|
| 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.
| kanevski wrote:
| Thanks for the feedback.
|
| 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.
| ablekh wrote:
| Congratulations on your launch and best wishes! Interesting
| stuff. Having said that, I think that I have seen another startup
| offering something along the same lines. I don't remember the
| name, but should I recall or find it in the ocean of my
| bookmarks, I will return here and add a comment.
| karakanb wrote:
| Congrats on the launch, this looks really cool and I'll give it a
| try.
|
| 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.
| Gipetto wrote:
| So, does this mean that users hand over permissions to a 3rd
| party to index internal company systems? So you could read a
| Confluence instance, or some other kind of wiki, and be a vector
| for data/security leaks?
|
| Seems like there should be a "talk to your security team"
| disclaimer... people get fired for granting access like that.
| kanevski wrote:
| 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.
| iudqnolq wrote:
| Any plans on a linux client?
| kanevski wrote:
| Yes, it's almost ready.
|
| 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.
| e12e wrote:
| > 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).
|
| 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...
| dbla wrote:
| 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?
| rokobobo wrote:
| I think this is relevant. It's cool that you've mentioned a
| couple of "competitors" -- which are internal to large tech
| companies.
|
| Would you guys be open to providing a self-hosted solution for
| large clients?
| kanevski wrote:
| 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.
| dimitriko wrote:
| 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.
| kanevski wrote:
| 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.
| rimjongun wrote:
| One idea would be removing apps from the "Connect Apps" list
| after I've connected them. Also app requests: - Digital Ocean -
| Wordpress - Ghost - Basecamp(?) - Signal(?)
|
| Exciting stuff, web interfaces can suck.
| kanevski wrote:
| 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.
| marvinblum wrote:
| This looks like the command menu we designed for Emvi [1]. I like
| seeing this taken to the desktop. It feels really good just to
| type in a command and get where ever you're trying to get faster
| than by clicking. This is what I like about Linux too.
|
| [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
| canterburry wrote:
| I was once being recruited to join a company with pretty much an
| identical product/business model. Back then things were much more
| file share/desktop based but pretty much the same value prop.
| Give away your passwords to all sorts of locations and we search
| it all, index and let you find things easily.
|
| I declined once I noticed that most other people at the company
| came from an NSA/FBI background.
| 2StepsOutOfLine wrote:
| Why did having co-workers with an NSA/FBI background dissuade
| you from working there?
| canterburry wrote:
| Because the whole thing was clearly an NSA corp with the main
| objective to funnel data to gov agencies disguised as a very
| helpful app.
| rimjongun wrote:
| What do you mean "very clearly?"
|
| 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 :)
| canterburry wrote:
| https://www.crunchbase.com/organization/farallon-research
| jesalg wrote:
| This is very cool. I just installed it.
|
| I was curious, can you speak to how this differentiates from
| https://getcommande.com/?
| kanevski wrote:
| 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)
| zestyping wrote:
| Thanks, this is helpful! Can you do a similar pros/cons
| comparison with Akiflow?
| jesalg wrote:
| Awesome. Thanks for breaking it down.
| hv42 wrote:
| That's really cool!
|
| 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.
| WesleyJohnson wrote:
| This looks awesome. I recently upgraded from Spotlight to Alfred
| and the productivity went way up. Slapdash seems like it would do
| that, again, 10 fold.
|
| Do you support local installations of the listed products,
| specifically Gitlab and Jira? If not, any plans to work that out?
| kanevski wrote:
| What do you mean by local installation?
|
| 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.
| yarone wrote:
| Great job with the description above; sounds incredible.
| Installing and playing with this now. Nice work, congrats.
| Cilvic wrote:
| Awesome, I'm longing for something like this for a while.
| Especially for many cloud systems like salesforce etc. Reminds me
| of Bloomberg terminal.
|
| I tried signing up, but receive no confirmation email to jmechtel
| posteo.de
| kanevski wrote:
| I just checked and it looks like the confirmation email was
| blocked.
|
| 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.
| technics256 wrote:
| Are you using sendgrid? They've been having a lot of issues
| with spammers recently so it could be affecting your delivery
| rates.
| kanevski wrote:
| Yeah, it's SendGrid. Good to know.
| rimjongun wrote:
| Mailgun has been good to me after switching from
| sendgrid. Even though I like sendgrids interface better.
| Cilvic wrote:
| Thanks for unblocking.
|
| 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
| kanevski wrote:
| 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.
___________________________________________________________________
(page generated 2020-09-03 23:00 UTC)