
Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues - kogir
https://www.realartists.com/blog/ship-20.html
======
rsanheim
This is a impressive amount of work to keep things fast and to avoid hammering
GitHub with redundant requests, which can get you rate limited[1] pretty
quickly.

Couple questions:

* I'm assuming you are using the actual end user's token for auth, so at least you have the 5000 requests per user per hour?

* It sounds like the Ship server has a lot of (potentially private) user data sitting around to keep things fast. What sort of security do you have in place to prevent data leaks or malicious access?

[1] - [https://developer.github.com/v3/#rate-
limiting](https://developer.github.com/v3/#rate-limiting)

~~~
kogir
> I'm assuming you are using the actual end user's token for auth

Yes. 5000 requests seems like a lot, though the GitHub API requires us to be
pretty chatty. To show reactions we have to request them for every issue and
comment individually, for example. Even doing it on demand (which we do) still
requires a lot of requests.

> What sort of security do you have in place to prevent data leaks or
> malicious access?

We take this really seriously, but it's hard to answer comprehensively in a
comment. Short story: Principle of least privilege, encryption where
appropriate, strong passwords and 2FA for everything, write-only logging,
super strict firewall rules, and parameterized queries.

I've been interested in security for quite a while and even briefly did
security consulting, so to the extent I'm able, I've been doing everything as
"correctly" as I know how from the beginning.

~~~
tptacek
For whatever this is worth to anyone: there are not a lot of people who run
bug tracking services that I would trust with my Github credentials, but Nick
is one of them.

------
dongslol
I'm impressed by the thought, care, and craftsmanship that went into this, and
all the more so because it's such a seemingly mundane tool. A better
bugtracker UX. What makes this a secretly interesting or important problem?

~~~
rtpg
Well, we have complex e-mail clients right?

Imagine if your e-mail client was like the Github issue tracker. This level of
pain is what a lot of larger projects go through. You have tags and basic
filtering, but the interface has a lot of friction for "power users" of
issues.

Think of those projects with 1000 open issues, and how you would want to deal
with this quickly. Easy access to certain filters, an interface with less
noise, etc.

------
marcosscriven
Serious q - how can I trust your 'Login with GitHub' screen? I'd rather be
redirected to my browser, so I can see I'm really logging into GitHub, where,
in fact, I normally am anyway. Then you can do the whole oauth thing without
me having to trust you don't take my password.

~~~
kogir
First, we're not stealing your password.

Each of us in the past have used multiple GitHub accounts to partition work
and personal life, or different consulting clients. I kept them in independent
Chrome profiles.

We originally had Ship launch the browser, but it was basically a crap-shoot.
I often had to paste the link into a different profile.

That said, you're right. We should allow the option to use the system browser.

From a strict security standpoint though, a malicious native app has remote
code execution on your box. It's game over. You're just one local privilege
escalation away from complete compromise. At some point you have to trust
reputation or never use any software. If this is a concern for you, native
apps aren't for you, and that's ok.

~~~
lentil
> From a strict security standpoint though, a malicious native app has remote
> code execution on your box. It's game over. You're just one local privilege
> escalation away from complete compromise. At some point you have to trust
> reputation or never use any software. If this is a concern for you, native
> apps aren't for you, and that's ok.

That's a bit disingenuous. The fact that privilege escalations exist doesn't
mean one has to trust all the software one uses completely and
unconditionally; it means there are risks that should be taken into account.

Given we're talking about the choice between an authentication method where
you can trivially capture someone's password, vs an authentication method
where you can't (and where you would need to successfully employ some sort of
exploit to do so), then the level of risk involved in each is quite different.

(Not only that, but I'd argue people will tend to trust software more when it
appears to be making best efforts with regards to security. Any obvious
security-related flaws will erode that trust rather quickly.)

(Edit: typos)

------
thedjinn
This app installed webhooks on all of my repos with no automated way to remove
them. Very annoying.

~~~
kogir
We fucked up here, and I apologize. Many thanks to robbiet480 for writing a
script to help clean it up.

We've just pushed new client and server versions to cleanup hooks when the
last admin user logs out.

New downloads will be the latest version, and current users can update now
using the Ship -> Check for Updates menu option. After that, you can logout
using Ship -> Account -> Logout. If you used the app earlier and want to be
sure all hooks are cleared out, you can log back in once more and then logout
again to trigger the removal.

There is also updated documentation here:
[https://www.realartists.com/docs/2.0/uninstall.html](https://www.realartists.com/docs/2.0/uninstall.html)

So about hooks - Hooks are added so that Ship is alerted when new repos are
created, issues/labels/milestones/comments are added/modified/deleted, issue
templates change, etc. The user experience without hooks is acceptable, but
not great. Presumably if you're using Ship, you want it to show the most up to
date information.

We disclose when you authorize Ship that you're granting repository and
organization webhook permissions. This appears to be insufficient notice.
We'll think about that next.

If anyone is still having trouble or needs personalized help, we're reachable
at support@realartists.com.

~~~
zyxzkz
So..., why did you have to install the webhooks in the first place?

~~~
pault
> Hooks are added so that Ship is alerted when new repos are created,
> issues/labels/milestones/comments are added/modified/deleted, issue
> templates change, etc.

------
kogir
Fred, James and I are in the thread and happy to answer any questions about
the product and how we built it. There's definitely more detail than made
sense to include in the blog post.

~~~
tobr
I'm fascinated by how it looks almost confusingly similar to Mail.app. Of
course a lot of apps use a three-pane layout, but most seem to deviate from
the standard UI one way or another. I don't mean not to criticise it - it
definitely makes it fit right in as a native Mac app, but it makes me
interested in your thinking behind it.

~~~
kogir
It's possible that Mail.app was a source of inspiration, and that we often
found ourselves asking, "Oh, that's like <feature> in email. How do other apps
do it?"

------
nicky0
I got as far as the screen where is asks for full read/write access to my
code, including all my private repos. I'm _fairly_ sure you won't mess
anything up or steal my secrets, but why does it need this?

~~~
kogir
Sadly, with the current GitHub OAuth flow that's the minimal permission needed
to access GitHub Issues.

See
[https://developer.github.com/v3/oauth/#scopes](https://developer.github.com/v3/oauth/#scopes)

------
pier25
Is there really a market for this?

9$ per month seems pretty steep when you consider that Github's web interface
is free and pretty awesome.

~~~
kogir
That's what we're hoping to find out. I think if you give it a try, you may
notice some ways the web interface is less awesome ;)

------
koolba
> Ship 2.0 is two parts, a hybrid Cocoa/ObjC/CoreData/JavaScript/React
> application that runs on your Mac, and a C#/MSSQL/Orleans server that runs
> in Azure. Oh, and a little bit of glue written in Python running on AWS
> lambda. Yes, it's truly an unholy alliance.

What compels someone to write a net new application (from scratch with no
legacy DB) that uses MSSQL?

In my book it's in front of only DB2 and Oracle on the " _Will not use unless
you 're already using it, migration is impossible, and you're going to have to
seriously pay me to deal with this_" list.

~~~
kogir
We can agree to disagree, but the tooling has definitely saved me enough time
to be worth it. That and realistically, no matter the DB chosen, you either
use DB specific features or leave performance (often substantial) on the
table.

~~~
koolba
> We can agree to disagree, but the tooling has definitely saved me enough
> time to be worth it.

What specifically are you referring to (regarding tooling)? Do you mean
running it on Azure as a managed service that auto scales, programming
tools/frameworks like LINQ, or client side GUI tools?

From an automation perspective not having a decent CLI for MSSQL to facilitate
scripting makes it a pain from day one.

~~~
kogir
SSMS is pretty great, especially for digging into query plans and deadlock
graphs. Same for SQL Server Profiler.

We use Database projects in Visual Studio, so all our schema, stored
procedures, and other scripts are in version control. We can compile them
(additional validation) into dacpac packages, and script updates and
deployment to local instances and Azure with sqlpackage and sqlcmd.

------
synthecypher
Nice I use Bee which supports GitHub and JIRA.

[http://www.neat.io/bee/index.html](http://www.neat.io/bee/index.html)

Unfortunately this application supports only GitHub issues.

------
mrmondo
Looks really lovely, would be great to see GitLab integration, I'm seeing a
lot of people move from Github Enterprise to GitLab CE/EE which (IMO) is a lot
better to work with.

------
eschaton
Note: Not actually native, it's apparently a weird hybrid JavaScript thing
rather than a Cocoa app. At least it's not just a wrapper around a WebView.

And if that weren't enough, it has some weird server component that's not
Github's own API server. That means I won't touch it, because who knows what
it's doing or sending…

~~~
kogir
I'd say it's as native as Mail.app, which also renders HTML content, and
relies on a remote server.

~~~
citruspi
> relies on a remote server.

That isn't really a fair comparison when eschaton says

> it has some weird server component that's not Github's own API server.

The remote servers that Mail.app communicates that are... the email providers.
As far as I'm aware, when I use Mail.app with Fastmail, Apple doesn't send all
my Fastmail email through their servers. Mail.app talks directly to Fastmail.

A mail client which works like Ship 2.0 would be Nylas[0][1].

For anyone who wants a bug tracker for GitHub Issues, JIIRA, or FogBugz which
communicates directly with their issue tracking server[2] someone mentioned
Bee[3] further down.

[0]:[https://nylas.com](https://nylas.com)
[1]:[https://nylas.com/cloud](https://nylas.com/cloud)
[2]:[http://www.neat.io/bee/security.html](http://www.neat.io/bee/security.html)
[3]:[http://www.neat.io/bee/index.html](http://www.neat.io/bee/index.html)

~~~
grinich
We actually released a version of Nylas Mail last week that communicated
directly with your email provider. (Plus it's free!) More details here:
[https://blog.nylas.com/nylas-mail-is-now-
free-8350d6a1044d](https://blog.nylas.com/nylas-mail-is-now-free-8350d6a1044d)

(I work at Nylas.)

------
QuentinM
If only this would support PRs / code review with revisions ... !

~~~
TheTon
We're working on something that I think is really good for PRs and code
review. It's part way done, and already I think it's a big improvement in
usability over the web based interface on github.com. But, in the interest of
shipping Ship, we had to cut it from this 2.0 release.

(btw, I'm James, I wrote the client side stuff in Ship)

------
bsimpson
I'd be a lot more curious about it if it handled Pull Requests. (Can't find
anything in the screenshots or docs to indicate that it does.) The biggest
pain point I've seen with GitHub's current UI is that it's hard to track PRs
as they evolve over time - old revisions and comments are often hidden away,
with no way to indicate what's been resolved and what hasn't.

Though to be honest, I'd be skeptical even if it supported that. I imagine
finding enough open source people who will pay $9 a month for a wrapper around
a free tool is a challenging business model, and I'd hate to become reliant on
it only to find it's been sunsetted due to the cost model.

Best of luck to the team! I don't mean to be pessimistic, just aware of the
realities of the developer tools market.

~~~
kogir
> I imagine finding enough open source people who will pay $9

Actually, we intend for Ship to always be free for (truly) open source. Public
repos will always work, even after the trial expires.

------
Simorgh
no one else seemed to point this out, but your name is really clever :-).
'Real Artists' for the company name and the product 'Ship', as in 'Real
Artists Ship', makes me think back to not too long ago when Mr Jobs was still
...

------
hobarrera
Hint: Jira support might sell fast too (if you're looking for a second
platform to support). All the people I've know who had to use it hated it
(myself included), _especially_ the UI.

~~~
softawre
Hm. I love Jira. I am the admin of my projects though, and get to actively
work to make things simple for my team.

------
begriffs
I use Github email notifications to keep on top of issues. GH lets you use
different email addresses for each organization you belong to, and then you
can use an email filter rule to separate issue traffic from the rest of your
inbox. Admittedly far less powerful than this desktop app, but also simple,
free, and native (via my native mail app). It handles a lot of my needs.

------
dbg31415
Given all the 3rd-party integrations available to the web interface (ZenHub,
Harvest, to... Grammarly even), what's the point of having a native MacOS-only
interface? It seems limiting / backwards to have native applications when
there's already a universal web interface.

Are there features that the web interface doesn't have?

~~~
kogir
Right now we have some search and charting features that GitHub's web
interface doesn't. We also hope to do a much better job with PRs (diff view
especially).

The big win for us right now (and hopefully other teams) is the ability to
view issues from multiple repositories all together. So if you have an
organization wide "1.0" milestone, you can actually view all the issues in
that milestone from all repos at once. You can also use custom queries to
group things however you like across all your repos.

------
nohant
Hopefully not too late, I'm wondering why do you use AWS lambda for?

~~~
kogir
To be honest, we wanted to play with it, and it was really easy to prototype
the OAuth code (and keep our OAuth client secret out of the client) before we
had the server deployed.

Now, since it works great, there's been no need to replace it.

------
TAForObvReasons
How does it compare to the official Github app:
[https://desktop.github.com/](https://desktop.github.com/)

~~~
kogir
It allows full interaction with GitHub Issues. The official application (I
believe) only supports limited interaction with PRs.

------
mcescalante
For a new user, they may have no idea that this is a 30 day trial until they
download and run the app, and I don't think that there is pricing information
on the website anywhere. Not necessary to have any of this, just some feedback
:)

~~~
fpotter
Yep - it's a 30 day free trial. After that it's $9/month. Like GitHub, we're
also offering a plan for organizations that want to provide Ship to their
whole team.

Our pricing page goes into more detail --
[https://www.realartists.com/pricing.html](https://www.realartists.com/pricing.html)

You're right, though - we should mention the free trial part on the front
page. Thanks for the feedback and for trying it out!

~~~
csomar
How do you charge a subscription for a downloadable, native app? Does the app
stop working if I stop payments?

~~~
fpotter
If you cancel or your trial expires, Ship keeps working but it only works with
your public repos. The intention is that Ship is always free for open source.

------
old-gregg
Fantastic work! Thank you for sharing. Do you guys see pressure from
commercial users to offer one-time payment instead of subscriptions?

~~~
fpotter
Thanks! We think the subscription model is the best fit for our product. While
Ship is a native Mac app, it also relies on a backend service so we have
ongoing costs to cover there.

Also, with subscriptions we don't have to play the upgrade game with our
customers. We can release features as they're ready instead of holding them
all back so we can justify a $50 upgrade for version 3.0.

That said, we would certainly accomodate companies that find it easier to pay
annually. And, if we end up doing an enterprise, on-premise version, that may
have a different pricing structure.

------
zacmps
Why did you develop just for OSX and would you consider supporting other
platforms (Linux!) in future?

~~~
kogir
Well, we had to start somewhere, and macOS is what our team knows best. If
there's enough interest, we'd love to support other platforms (including
Linux).

~~~
mixedCase
If you have decoupled your application logic from the UI, you might wanna look
into Qt/QML. Opens up support for a lot of platforms, and you can have a
native-looking GUI for both Windows and Linux using the exact same codebase
without "ifdeffing".

~~~
davidcollantes
Just curious, could you link an application using Qt/QML with a native-looking
Windows GUI?

~~~
LeoNatan25
Native-"looking" = Looks and feels like nothing native. Always use the best UI
for each platform, which is the native UI stack.

~~~
mixedCase
Qt maps its widgets to native ones. As long as you pay the same attention to
detail as required when you're accessing the Win32 API directly, you're going
to be able to get the same results.

And as I mentioned in the other comment, QML makes it fairly easy to make
UWP/Metro-style apps.

~~~
davidcollantes
Again, do you have a link to one of those applications? Every time I have come
across one, they look decently on Linux, but far from it under macOS, for
example.

Like previous post @LeoNatan25 wrote, they looked and feel nothing like
native.

~~~
mixedCase
As I mentioned in the other comment, most people simply don't care about
making it native outside of their own platform, but Qt won't get in your way
if that's what you want; you have access to the native widgets, it is up to
you to make it look the part.

------
davidcollantes
Very nice, but $9/month to use?

~~~
kogir
If we're not yet there, the goal is to get to the point Ship is worth at least
$9/mo. Are there any features you'd like to see?

------
Redoubts
So does this mean Ship isn't a stand alone tracker any more?

~~~
kogir
Ship 1.0 will continue to work for the foreseeable future, but you're correct:
Ship 2.0 depends on GitHub.

------
niemyjski
Brew support?

~~~
kogir
That's actually a great idea. Do they have a notability requirement?

------
mosselman
I just tried the app and I think the typography of the issue list makes it
hard to look at for me. Also, I doubt that the app is useful to me. What kinds
of teams is it aimed at?

~~~
nkoren
Without intending any snark, here's a guide to getting upvoted rather than
downvoted for a comment like this:

"I think the typography of the issue list makes it hard to look at for me,
_because_ ________(insert constructive criticism here)________"

"I doubt that the app is useful to me, _because_ ________(insert thoughtful
feedback here)________"

I'm sure both the authors of the app and the HN readership at large would be
more receptive to such a post.

~~~
dang
Wow, that's really good. Thank you!

