anemitz

Yup. We built a bunch of billing/invoicing mechanics on top of Stripe.

Anthony here. Happy to answer any questions about how the calling integration works.

How soon after signup do you call? 5% is definitely on the lower end of what I would expect if you're generally calling within an hour of signup. You can really blow someone's mind by calling them within a few minutes of signup. You're not looking to get them on the phone for more than a couple minutes -- just a quick, "hey how's it going..anything I can quickly help with...ok, great...if you have any questions go here or contact us like this..."

EDIT: signups outside of normal business hours are harder to call so it's OK to try and fit those in as best you can -- your success there will also depend on the signup's timezone.

Not sure why there's such backlash against the idea of calling customers. You signed up for a service. If you're at all serious, there's a good chance getting a call right away will either 1) help overcome some stumbling blocks with activation or, 2) leave you with a feeling of personal connection. Both are good things in my book.

But yes, of course, no one wants to get a used car salesman calling them and stuffing a sale down their throat. That's not what this post is advocating. But in case you're worried (or not serious about using the service) there's an easy way to avoid getting a call: don't enter a phone number (or at least a real one).

StartSSL is also not a widely accepted CA which means Apple Mail (and others) will likely complain the certificate is not issued by a trusted party. It's an easy fix, but one that shouldn't have to be done.

@rdl who is your go-to CA?

If Google decides to change how they save drafts you're compromised. They also have complete control of the page so any key press or mouse movement you do they can catch.

Yeah, was thinking the same. At the end of the day any type of client-side javascript encryption is insecure since you'd need to prove the browser + runtime + js + algo are all kosher.

It's also sort of ironic that this extension is trying to protect your privacy against the same company making both the browser and the email service:)

What's the suggested method to securely exchange the key?

It feels a bit like this is a step backwards in many ways. Being a non-webmail user, how can I benefit from this? If this were an implementation of SMIME/GPG it would be more widely adoptable since anyone with a compatible GMail plugin, desktop, or mobile client could use this.

Edit: Good read about JS encryption and its downsides: http://www.matasano.com/articles/javascript-cryptography/

Out of curiosity, what was the reason for not picking a more traditional Dovecot + Postfix setup?

Steve Jobs famously re-leased his SLK every 6 months and never put plates on it -- seems like a great way to avoid this type of tracking if you're in the financial position to do so.

The internet is fun, so I'll bite.

> scummy and uninteresting business model

We make a sales communicate platform that integrates CRM + calling + email. <sarcasm> You're right, it is a pretty uninteresting business model in that we don't use some new-fangled financial instruments to cook our books -- it's just boring ole' monthly recurring revenue at a SaaS company. </sarcasm>

Scummy? Don't even know where to begin on that one -- but if you're in the Bay Area ping me. I'd be happy to sit down and entertain any ideas you may have that we run a scummy outfit. Seriously. I really would like to understand the context behind that statement. It's not something I take lightly as a founder.

> None of my email clients, on OS X, Windows, or Linux, will show that pixel unless I press a button or take some action.

Yes and no. You can set most clients to load images by default -- I haven't tested the default settings on all clients so I can't speak about what percentage that accounts for. I'd assume someone like Mailchimp/Marketo/Pardot/etc. may have published some interesting findings about this.

You're entirely right, however -- we can't do anything if a client blocks images. And that's OK. Tracking is a feature our customers love being able to utilize when they can, but they also understand that it's not entirely accurate.

Incorrect terminology should now be fixed. Thanks for calling that out.

Note that Google's SMTP servers do store the messages in your sent mail folder. I don't claim to know exactly how they do this (IMAP, direct access to filesystems, whatever), but the messages are stored -- and yes, obviously the SMTP protocol doesn't facilitate this but their SMTP servers perform this action.

I hate social sharing buttons and ad networks just as much as the next guy, so I completely understand where you're coming from with this comment. However, you have the option to completely opt-out of any kind of email tracking by always reading only the text portion of emails sent to you.

Asking whether this is morally/ethically OK is probably not the right question. As we've seen with any technology, if something is possible to track/store/analyze it will be. If tracking email opens (or any data on the internet) is not something we want to accept as a society we need to find ways to ensure tracking those actions under any circumstances is impossible -- not just leave it up to chance.

Author here.

You're entirely correct that this part of the SMTP spec does potentially allow for dubious behavior -- and that's one of the reasons I wanted to publish this article. I have a feeling this is one of the little-known secrets of email sending which we should all be aware of.

EDIT: Also, I'd like to point one that the real textual content of a message can't differ when sending through Close.io so the scenario you explained above isn't possible within our app.

This is a comment.

Any company blog is boiled down to an advertisement at some level. If your interested in learning about how we technically do a lot of these things scroll to the bottom of the article and checkout the technical companion post. This post is merely gives context of what/why. http://hack.close.io/posts/building_better_email_integration... gives you the how.

EDIT: I don't know where I got my internet license. Wrong link now fixed.

I've also been considering the possibilities of an OSS security focused business. Random thoughts:

* Build infrastructure necessary for other developers to build provably secure products on, license this.

* Free consumer versions, paid/managed versions for corporations and governments.

* Things like secure telephony have business models built in where you could charge per minute (or message) (and probably still be less than incumbent carrier minutes).

There's no expectation of privacy at the service provider level in this case. If Verizon, or any service provider, has access to the unencrypted data or the decryption mechanism, the system is insecure.

However, cryptography does help you as an individual user of a service. There's no reason we can't build systems which are provably secure and retain strict end-user data privacy.

This is precisely the type of attitude we should all have as hackers.

It's easy to sit back and say "oh government this or corporation that sucks", we need to step up our game as builders of the software sitting on millions of devices.

This is a privacy arms race -- and right now we're losing.

The chart of mass shooting casualties leads me to believe this study has underlying bias already.

1) The use of bullets seems like something a media outlet would do to invoke irrational emotional response. I'd hope that if this is a serious scientific study you wouldn't have to resort to such antics.

2) The only chart on this page centers on mass shootings which account for less than 1% of all gun violence. I'd much rather see a comprehensive breakdown of gun violence by incident type (gang, mass, accidental, etc.) and also by weapon (semi-auto handgun, revolver, shotgun, semi-auto rifle, etc.).

EDIT: It would also be nice to see a citation for the underlying chart data.

One of the largest benefits for us was the ability to rent numbers through the API. Since developer accounts can't rent real numbers will you be renting out some sort of internal numbers? Not allowing any numbers to be rented seems like an oversight since I'd imagine a lot of apps use (and want to test) this type of functionality.

A link to "Plivo Blog" should probably go to blog.plivo.com. If it were a link to "Plivo" it would make sense, but how do I now browse your other blog posts?

Repost of http://news.ycombinator.com/item?id=5334554

It's worthwhile to point out many people don't attend SXSW sessions but instead go to Austin during a combination of either Interactive or Music and just bum around the city, meet new people, and hack on their own projects. IMHO, the value of SXSW is not the conference sessions, but the change of environment.

If you're resourceful, you can do Austin during SXSW on a very tight budget (< $500 including airfare) and get a lot of value out of it by not being sucked into the conference mentality. My recommendation is to hack during the day while sessions are going on and go out and have fun at night.

If you're careful with your time and energy, traveling to Austin during SXSW can be a big productivity and morale boost.

We aren't happy with the available web calling options, yet. The more traditional route, Flash, has obvious disadvantages. More recently, WebRTC has been used for calling, but it's still too immature for serious applications. Long term WebRTC is the technology we'll choose for web-enabled calling, but it needs wider adoption among browsers and proven rock-solid reliability and quality for us to trust our sales team (and yours) with it.

Absolutely. We can also setup your account with an international number (most countries available) so that you can sell in the region best suited for your business.

Good eye. We also realized this at one point. The Elastic logo in its current form was done Jan. 25 2012.

Awesome, hope you like it:)

And you're right, we use native SIP -- that's the main reason we have native applications. Behind the scenes we use the PJSIP library.

There may or may not be several people wearing capes at our office on any given day:)

We can do a historical import. Shoot us an email at support@close.io and let us know from what date you'd like us to start importing from.

We evaluated Twilio, but decided against it due to lower call quality. Their gateways are virtualized in the cloud and this can lead to timing issues or hollow/tinny sounding audio. Twilio also lacked their SIP endpoint (not sure if this is still in beta) at the time we started building Close.io, which would have allowed us to do native calling. We ended up working with Plivo (another YC company) and have been happy with our choice.