Live data from Hacker News

Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

realartists.com

91–100 of 106 posts

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#91

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.

OP, I agree with this. As I mentioned in an earlier comment, I was put on edge using that login screen. There's absolutely no way to know if it's real. I ended up creating a fake GitHub account to test the app because it made me uncomfortable.

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#92

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.

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

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#93

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.

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.

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#94
post #93

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.

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 bro…

As a counter point, I have never used multiple GitHub accounts and it's unclear why I would. The separation is provided by contributing to different orgs.

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#95
post #93

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.

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 bro…

> 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)

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#96
post #73

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…

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

> 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 [1]:https://nylas.com/cloud [2]:http://www.neat.io/bee/security.html [3]:http://www.neat.io/bee/index.html

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#97
post #73

Earlier quoted context omitted.

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

> 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 l…

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

(I work at Nylas.)

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#98

Earlier quoted context omitted.

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.

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.

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.

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#99
post #85

Earlier quoted context omitted.

The one real downside here is that you're tying your users to Windows. If you had a more "pluggable" db layer, they could use the platform of their choice. That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.

You mean back-end developers right? Because users are not tied to Windows, as they do not need to install the server side of the app...

Yes, I meant the backend. Apparently I misread the part where this is a SaaS product, I thought you could host the backend.

Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

#100
post #86

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

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.

Post reply on HN