FFmpeg's future and resigning as leader - <AUTHOR> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489.html <comment><USER2> I don't know the extent of the drama, but I have used FFMpeg a decent amount and it's been a lifesaver. I know that OSS leaders are extremely under appreciated, and I'd like to thank Michael for all of his efforts doing so.

<comment><USER3> > I don't know the extent of the drama

As a heavy user of FFmpeg/libav, for VLC (I'm the VideoLAN president), the drama has been huge, and more aggressive than most forks we've seen in the open source community.

Most of the information you find online is biased, wrong or down-right lying, including the usual blogposts that are quoted from one side or the other one. (like the pkh.me pasted or the Debian wiki one)

Whose fault is it? Well, it's a bit complex to answer, and there has been very dick moves from both sides. Especially since the beginning of the story started in private and was not reported publicly.

Who is doing more work between the forks? That's also very hard to answer, because most of the libavcodec and libavformat work has been done in libav, but most of the libavfilter, ffmpeg and tools work has been done in FFmpeg.

What you should know is that the current codebase of FFmpeg is messier compared to libav, but has quite a few more features, notably filters and more formats supported.

Choosing one or the other gives you different set of features, but mostly different set of bugs and level of support of codecs. It's a big mess...

<comment><USER4> " FFmpeg is a huge mess compared to libav"

I assume this is an unbiased opinion as much as it can be but could you elaborate on what about FFmpeg is a "mess."

I've used both these libraries in building MythTV from strictly a user perspective. Both code bases are open source. I'm wondering if there is so much turmoil here, why doesn't someone (like VLC) take the best features from both projects and create their own library?

I never understood the OSS communities. It just seems simple to me. If you don't like it, fork it and do your own.

<shrug>

<comment><USER3> > I assume this is an unbiased opinion as much as it can be but could you > elaborate on what about FFmpeg is a "mess."

Examples: 2 prores decoders, 2 prores encoders (or 3), 2 different resampling libraries, libstagefright integration that does not work, more global context structures compared to libav, etc... They also refused to remove some very outdated (non-working) code like xvmc.

> why doesn't someone (like VLC) take the best features from both projects and > create their own library?

Because it's a lot of work. An enormous work.

<comment><USER5> For what it's worth, a lot of production code looks this way. It's not right, it really should be nice and neat and so on. However, I don't see it as a grave sin against the project. Messy code can diverge where needed more easily.

Three different copies of the same code? Yeah, ok. That's ok. One day, when you can, merge them together. You can't merge them together? It's ok. Maybe they shouldn't be merged together.

Is it a barrier to entry for new developers? I feel that any developer who has worked on messy legacy code won't bat an eye. This sounds more like a problem experienced by a young coder fresh out of university.

You definitely can write clean code. Cleanliness can be a priority. There are some surprisingly clean and well-written large codebases out there. However, a lot of people just don't care. They are very smart, capable people who just bang out code that works and don't care to integrate in the proper clean way with the old code.

If you want clean code, an old, large, working C/C++ codebase is not what you want. We often can't spend time cleaning up old code, since there's always more features to implement, bugs to fix, etc. Learn to deal pragmatically with code like that. It's not like that out of malice, or some misguided attempt at writing the largest IOCCC winner. You can work with it. It's just a bit trickier.

<comment><USER6> I've worked on some of those "old, large, working C/C++ codebases" and the ones that are not clean are the ones where you are terrified of making a small change to fix a bug, especially close to release, because you have absolutely no idea what might break. Two copies of the same code? Great, which one do I fix? Both? How do I test that it worked, I can't even figure out where #2 is activated in the UI?! Is there something a little different about them that I need to watch out for? And test cases for said codebase? Hahahahaha!

</comment></comment></comment></comment></comment></comment><comment><USER7> Interestingly, a recent LWM article on ffmpeg coming back to Debian touched on the possible implications of Michael stopping work on the project: [https://lwn.net/Articles/650816/](https://lwn.net/Articles/650816/)

"Reinhard asked whether FFmpeg is a one-developer project that would find itself in trouble should Michael stop working on it. "To me, this constitutes a serious bus-factor: Without Michael, (probably) nobody is able to replace him." He went on to suggest, though, that Michael's departure could do a lot to bring an end to the fork."

</comment><comment><USER8> Before Yahoo! went public David Filo contacted Larry Wall and gave him the option to buy a good portion of pre-IPO stock at a low price.

The reason? Yahoo! could not have existed without Perl.

FFmpeg has been used in so many profitable ventures (hint[1] hint[2] Netflix). I sincerely hope there is a business leader with the same level of consciousness and grace that will do the same for Michael. He's one of the heroes of the past decade. Internet video streaming would certainly not exist as soon as it did without him.

[1] [https://twitter.com/nicolasweil/status/466248052454727680](https://twitter.com/nicolasweil/status/466248052454727680)

[2] [http://www.streamingmedia.com/Articles/Editorial/Featured- Ar...](http://www.streamingmedia.com/Articles/Editorial/Featured- Articles/Streaming-Media-East-Netflix-Making-the-Move-to-HEVC-but-Efficiency- Gains-Lag-96981.aspx)

<comment><USER9> Kudos to Yahoo! What a different time, thankful tech companies. But this is no more, only after public shaming did the Googles/Facebooks chip in money for OpenSSL and GnuPG when those projects almost collapsed. And they gave rounding-error level of their multibillion cash piles.

This is why the community is broken and sadly some of us feel cornered to do Affero or just not open source. I used to be hardcore BSD, but times changed and had to adapt.

These the majority of the community is selfish, doesn't contribute back, doesn't even give credit to most of the tools behind their UIs. See:

[http://zedshaw.com/archive/why-i-algpl/](http://zedshaw.com/archive/why-i- algpl/)

<comment><USER10> Being LGPLv2 was enough to get FFmpeg some income streams, because almost any shareware video converter you could find shipped it without credit or source distribution, and the SFLC would go after them for copyright violation.

Not sure if there was much contribution or acknowledgement for the longest time from any company (Google, FB, Vimeo, Netflix, Zencoder, etc) using it, and I remember the best they'd do for bug reports was say "yeah it crashes sometimes" and refuse to send sample files.

Eventually Google did have some people contributing full-time, of course. They paid me 1x GSoC (one week's engineer salary) for more than a year of work once. Um, it seemed like a good idea at the time.

</comment></comment></comment><comment><USER11> Wow, that's a pretty classy move. Now lets how this will help heal the wounds with the libav community and they will in fact move to the other side.

I think he should have left out the bit about 'will I ever return', that might actually cause libav contributors to hold off from making the switch.

Still, it's great to see the recognition that in the end this is all about the product and its users.

<comment><USER12> I disagree. FFmpeg is/was heavily dependent on Michael for active development and bug fixes. In the last few years, more than half of the commits are from him. Without his contribution to development, nor a clear leader and succession plan, FFmpeg may stagnate again.

I don't blame Michael for any of this situation, but this is not a win for the community, product, or users. Development is going to slow way down, bugs are going to go unfixed, and the overall quality will decline in the short to medium term. It is unfortunate that vitriol over the fork led to this situation, where neither libav nor FFmpeg win, and everyone loses.

<comment><USER11> What else should/could he have done that would be better?

<comment><USER13> he could have stepped back much earlier

<comment><USER14> or someone else could have stepped up much earlier?

<comment><USER15> Well people actually have tried that 4 years ago: [http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/123868](http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/123868)

and somehow leadership was still a thing for Michael at that time, which really contradicts with something he says now.

<comment><USER14> That looks very much like a hostile takeover, it's unsurprising that it failed.

<comment><USER16> It was very much a hostile takeover. If I remember correctly, the people who controlled the infrastructure like the website and mailing list booted out not only Michael but also a bunch of the existing maintainers of ffmpeg code and it got really ugly.

<comment><USER17> You might check your facts before spouting this kind of sentences.

Sadly the people on the Libav side never spoke up and nobody really checked or asked since they are "EVIL".

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> Sigh. This is one of those situations where the world has received so much benefit and they didn't realize it until that person finally got fed up. FFmpeg is sort of an ongoing disaster, but it reflects the nature of media on the web, and it works. I'd love to say that my hunch is things will get better but I don't think that will be the case short or long term.

libsndfile -- another key component everyone takes for granted -- is in a similar position. Full of known problems, super-smart but slightly neurotic leader, and GPL issues that people are pretending not to notice in hopes he finally does a release after 5 years.

I've done major community work and man, is it ever exhausting. It's a shame we haven't found a way to get people the assistance they need. Some of which is psychological.

<comment><USER19> The approach I'm trying to take with the community I'm involved in is to keep the effort required spread out -- so for instance I manage mainline releases but somebody else deals with stable branches and point releases, and a third person does the "pick up otherwise orphaned patches from the mailing list and get them applied" work. If I was trying to do all those jobs at once I'd never find time to do any of the things I actually find interesting!

<comment><USER20> This is probably one of the issues with being a the aforementioned super-smart / super-productive leader: they _can_ take all of that load if needed.

Should they? God no. No one can run that workload as a volunteer for a decade+.

But I can see how the default reality probably bends towards "Well, someone left and we need this job filled" -> "I'll just temporarily add that job to my workload" -> "It'd be more effort to move that job's responsibility to someone else, so I'll just keep doing it."

</comment></comment></comment><comment><USER21> Thanks Michael for all the awesome work. Sad you are leaving for these reasons, hopefully in the futur, libav contributors will come back to FFmpeg and be less agressive with the leadership, but it might not happen.

</comment><comment><USER22> A huge thank you to Michael. It's easy to forget how difficult playback was just 5-10 years ago. FFmpeg has been invaluable.

</comment><comment><USER23> > Especially as somehow "leader" is being interpreted by everyone as "the guy > who does all work noone else does, and takes all responsibility noone else > wants to take"

Hmm.

<comment><USER24> > Especially as somehow "leader" is being interpreted by everyone as "the guy > who does all work noone else does, and takes all responsibility noone else > wants to take"

That's what leadership is.

<comment><USER25> There's likely otherwise stuff to it, e.g. Does all the boring housekeeping commits, patches security vulnerabilities etc, leaving others to work on the 'sexy' stuff like new features.

</comment></comment></comment><comment><USER26> As a VLC user, I'm sorry to hear things in the FFmpeg community got so bad. However, I thank all involved (including VideoLAN) for the work they did to make something that plays about anything on the major systems. Good news is, since it's open-source & mature, it has a chance of rebounding back into good shape either in current or new hands.

</comment><comment><USER27> Just to add context: this is a post from a person involved in the project since 2004. It is a bit bitter but I found it interesting to read ("What happened to FFmpeg" by Kostya)

[http://codecs.multimedia.cx/?p=339](http://codecs.multimedia.cx/?p=339)

</comment><comment><USER28> Can someone give us a backgrounder on what the split in the ffmpeg community is about?

<comment><USER29> [http://blog.pkh.me/p/13-the-ffmpeg-libav- situation.html](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html)

There's probably some great popcorn in mailing lists.

Edit: libav have a big "personal conflict resolution" section here which is another hint:

[http://libav.org/about/](http://libav.org/about/)

</comment></comment><comment><USER30> The message on the FFmpeg site [http://ffmpeg.org/index.html#message](http://ffmpeg.org/index.html#message) sounds hopeful for a reconciliation of the forks.

</comment><comment><USER31> This is all news to me but the FFMpeg / libav split and apparent attempted coup d'etat of FFMPEG the other year all looks very sad. This reminds me of the XFree86 / x.org splits, the EGCS/GCC splits etc.

All very sad but makes for interesting OSS history! I find FFMpeg very useful, but then again I find VLC and libav useful. In fact, it is all useful. I hope it all works out.

<comment><USER32> Why sad? XFree86 and GCC had HORRIBLE code, first thing done in forks was to delete 70% of code.

<comment><USER33> As a Gentoo user we're gonna have terrible dependency problems for the next few years. Specifically VLC and Qt.

Somebody at Redmond is laughing at the OSS community for failing to provide functionality that comes out of the box on the latest Windows systems.

<comment><USER34> Nothing that Microsoft has comes close to the functionality of ffmpeg. Apple, either, for that matter. Last time I checked neither OS even supported reading Matroska containers natively, and containers are pretty simple compared to codecs.

        $ ffmpeg -codecs 2> /dev/null | wc -l
             396

ffmpeg and libav are simply the most comprehensive collections of video codec software in existence.

<comment><USER35> That doesn't make either one good.

<comment><USER10> I can promise nearly every implementation in ffmpeg is better than the competitors. No commercial product has the motivation to keep making improvements to their code that already works "well enough", and they don't have as good a set of working optimizations to apply to new codecs.

They can get new features out the door, though. One reason for the original fork in ffmpeg was that the very strict code review culture made it difficult to get anything in that was experimental or depended on personal taste.

<comment><USER35> There is a lot of very useful functionality in ffmpeg/libav. That doesn't make using it pleasurable.

<comment><USER10> Were you trying to use it from the API or the command line?

Either way, yes. Elenril and others were doing good work cleaning up the API when I last paid attention years ago, but there's a lot of surprise technical issues esp. in libavformat that it has to cover up. (Like, PTS/DTS in avi. Like operations that are instant in some file types might be real-time minutes in others.)

As for the command line, major customers tended to not ever give feedback on it, and it was maintained by Michael who tended to use the same code-review standards on the UI code as on the inside of a video encoder. This made it quite difficult to ever get anywhere. That's one of the reasons there was a fork back then.

Of course, there's deep technical problems there too - you can tell it to do all kinds of things that are actually really hard, and it will kind of half- heartedly do them then fail. Try converting a Matroska file to MP4 without re- encoding it; you'll get a weird error. That one weird error would take more than a year of developer time to fix.

<comment><USER35> Yeah, both. In fairness, the last time I tried using the API was before the libav split, and I have no doubt that the situation has improved; the command line, while almost ludicrously powerful, retains a lot of terrible habits -- silent defaults, mutually contradictory options, &c.

I have somewhere a much more prescriptive python library that sits on top of the command line API, but I think it'd be really great if there were a "strict" mode for the CLI -- no more implicits, no more silent rejiggering of options. If you don't totally account for your input and output, it's an error. Then, there could be a much more forgiving and intelligent front end to the front end that allowed for things like "-i foo.avi ./foo.mp4", making best guesses at each stage of the pipeline.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> So who is likely to take the reins on the FFmpeg end?

</comment><comment><USER37> For those who were around for it, I'd be interested in a comparison with the ffmpeg/libav issue and the GNU Emacs/XEmacs times.

</comment><comment><USER38> I didn't follow the background of that fork. Will ffmpeg and libav be able to merge now? Was it a leader conflict or something else?

</comment><comment><USER39> To whoever contributed to it: the swscale library (colorspace conversions) was really helpful during my PhD work.

</comment><comment><USER40> Sad to see the hostile fork "win".

I know if I were ever in the position to contribute to general OSS video, libavcodec would be on the list of projects i would never be willing to support.

Hopefully these projects can reconcile and libavcodec and its shamed name can be put down and development can continue under the projects true name to honour its true roots.

<comment><USER41> > Sad to see the hostile fork "win".

I wouldn't put it that way, considering that the last distros still shipping libav are abandoning it in favor of ffmpeg.

</comment></comment><comment><USER42> Thank you for all the work that you have done so far Michael Niedermayer

</comment><comment><USER43> Every project needs a strong leader. I seems that projects seem to fall apart when decision making become driven purely by consensus. If Linus was not a strong leader in giving Linux definitive direction, this same thing may have happened for Linux by now.

</comment><comment><USER13> not that he was likely to go without making a ton of derogatory remarks about the livav split.

and if he never liked the leadership role as he claims, he was given ample opportunities to get rid of it.

<comment><USER44> He states:

"I had hoped for a long time that the fork situation would resolve and both sides somehow merging back into one team. All the Libav developers joining FFmpeg again. But even now as the last distributions are preparing to remove Libav, still theres no hint of that happening. Maybe even the opposite."

and

"Do friendly merges, and if you like do hostile merges. Its all up to you now!"

That isn't "a ton of derogatory remarks".

libav is working to the same goal as ffmpeg. The split is due to idealism and politics, not due to the goal of the project. I'm not going to pick a side in this, as interpersonal relationships are impossible to accurately gauge from an external viewpoint.

I'm not sure if you have a personal stake in this argument, and I apologize, and sympathize if you do.

Best of luck in the future Mr Niedermayer. Thanks for all the work over the years.

<comment><USER13> "...and its very difficult to be the leader when one is on one side of this split and the other tries everything to push me out..."

that the gist of it, it's always the _other_ side wanting him harm. he never ever acknowleged any wrongdoing on his side.

<comment><USER16> The libav side have consistently refused to merge code from the ffmpeg side of the split, including security fixes, have written their own incompatible versions of any APIs the ffmpeg developers come up with, and been generally hostile, and he's the one that's had to deal with the mess for the past several years.

<comment><USER17> "Refused" ? In Libav any patch has to go through review, anything that had been put in review had been managed as any other patches by any other sources.

Libav is about rules and not leaders.

<comment><USER45> After seeing a few of the comments from libav developers here and on IRC, you can see the bitterness is still alive. :-(

<comment><USER13> if everything that somebody from the libav side says here is automatically labelled bitterness and downvoted, maybe you can understand why some are indeed bitter.

<comment><USER46> I've never heard of this split up until today, why are you still salty? You won, you can take over the world now.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER47> Not going to comment on his skills to lead such a community, which more than obviously are very very good, but for a project manager of 14 years he really writes like a newcomer.

<comment><USER48> I was thinking the same thing. Looks like the writing of someone posting to a drug forum blacked out on benzodiazepines.

<comment><USER49> That's oddly specific.

<comment><USER42> maybe speaking from personal experience...</comment></comment></comment></comment>


Russians penetrated US voter systems - <AUTHOR> https://www.cnbc.com/2018/02/07/russians-penetrated-us-voter-systems-nbc-citing-top-us-official.html <comment><USER2> Must have been through the hanging chad exploit.

<comment><USER2> Ha, I figured out how to downvote an article I don't like.</comment></comment>


GoDaddy is a scam - <AUTHOR> https://www.reddit.com/r/web_design/comments/a562gv/godaddy_is_a_scam/ <comment><USER2> I have no proof of anything GoDaddy specifically does.

A while back I came across some of my archives that mentioned a BBS name that was popular in the past. Thinking it would be neat to own the domain name of the company that went out of business, I went to GoDaddy and checked. It was available awesome. Got distracted, came back an hour later and it was no longer available, but was at auction.

My first suspicion is nothing nefarious happened. I could have misread available vs auction, but I don't think so. I might have mistyped the domain name, but I don't think so. Something didn't feel right.

A few days later I checked another domain using whois through icaan. No resolution. Available. Pop over to GoDaddy and do the same thing ... check name is available. As a test, I wait an hour and come back to the name at auction.

I cannot explain what happened it except maybe GoDaddy's name check leaks or someone had the exact same name ideas when I had them. Again, this was years ago and am unsure if it still occurs.

<comment><USER3> I can. I used to work at GoDaddy and they have an "Executive Domain Team" that is basically just a fancy word for a group of people that assist domain kiters. If you search for a domain on GoDaddy's whois, they put a hold on it and publish the list to potential domain "investors" (read: kiters) who then have the option of purchasing it out from under you. These are people that literally invest thousands of dollars to buy up domains on the off chance that they can resell them at a profit. Anytime there's a sunrise period on a new domain TLD, these guys go in and buy all the popular and common names wholesale and they have a dedicated person that works at GoDaddy to help them do this.

Anytime you have a question about whether something is a scam or not, just ask yourself where the money is. In this case, it's in GoDaddy making money off of any time a domain name is sold, re-sold, auctioned, or if it changes hands. It's where the majority of their money made comes from, outside of services where people just don't know that better alternatives exist.

<comment><USER4> This sounds exactly like what happened to me. I had a few .london domains in one of the early stages of the TLD launch. Sat there for about 60 days, and then all of a sudden - gone.

GD support were useless and I lost out on a few quality domain names. Never used them again since. In fact, I don't even think I got my money back!

</comment></comment></comment><comment><USER5> For what is worth I've been using Namecheap.com for domain registration, for several years and have been satisfied. Never had any problems.

Cloudflare is also entering this business and looks promising.

<comment><USER6> I was happy with Namecheap until they redesigned their website and included a tonne of JS which slowed everything down. Doing something as simple as changing an A record became unbearably sluggish, and I tend to think I have a fairly high tolerance for that kind of thing.

I gave them a few months to see if it was teething problems with the new design but it persisted. Eventually I moved everything to gandi, which has been better in every way as far as I can tell - cheaper (for me), better website, better features out of the box.

<comment><USER7> Their online chat support is extremely helpful in my experience

</comment></comment></comment><comment><USER8> Nothing new. I used to buy and sell (mostly buy) lots of domains and wrote a review of several registrars in 2014 placing Godaddy at the very last place recommending users to stay away. Here below is what I wrote then:

"Godaddy has improved slightly on their interface since last years review. However they still have large menus that are complicated to navigate through and seem to be using the same bait and switch methods as before. After finally finding a domain that you like you will receive several offers for email, hosting, etc before you can even get to the cart. All prices seem to have an asterisk or two telling you that their super low price is only valid if you pay for 2 years or more. Going from previous experience I feel as if Godaddy wants to lock me in to use their services for as long as possible or to simply get as much money out of me before I leave. Looking around for what Godaddy charges for renewals I found several red flags where users are getting charged "market prices" for their renewals. You can see a forum thread regarding how Godaddy charges way too much for renewals here ([http://www.webhostingtalk.com/showthread.php?t=1365680](http://www.webhostingtalk.com/showthread.php?t=1365680)). This post here ([https://www.authormedia.com/6-reasons-authors-should- avoid-g...](https://www.authormedia.com/6-reasons-authors-should-avoid- godaddy/)) even gives an additional 6 reasons why you should stay away from Godaddy."

[https://archives.tenghamn.com/best/domain/registrar/2014/10/...](https://archives.tenghamn.com/best/domain/registrar/2014/10/27/best- and-worst-domain-registrars-my-review-2014.html)

<comment><USER9> I think I saw your post long time ago and switched from GoDaddy to Namecheap because of it. Now I'm using Google Domain. Thank you for your contribution!

<comment><USER8> Glad to hear it!

</comment></comment></comment><comment><USER10> Moving away from GoDaddy was one of the most rewarding "online service" switches I've made. I used to cringe visiting GoDaddy when renewing domain names where I've had to carefully navigate my way through their Dark UX patterns which feels like I've ventured into the "Dark side of the Web" where you can't trust what you read and everything is designed to upsell scams out of you.

I've moved everything to Google Domains, at $12 /y for .com domains it's only a little more expensive than GoDaddy (with Coupons) but it has a straight- forward simple and minimalist UI where I can get everything I need to get done (e.g. dns config/renewing) quickly and easily.

It's an example of a UX-focused UI built for you by contrast I view GoDaddy's user-hostile UX was designed against your best interests.

<comment><USER11> I totally agree. I always dreaded the time when I had to renew my SSL cert with GoDaddy. Then, each year, while navigating on their website, I always ended up asking myself if they hired a group of psychos to design their UI.

After a couple of years I finally found Namecheap and never looked back.

</comment></comment><comment><USER12> FWIW, GoDaddy isn't the only site I've seen do this. I had the same issue a couple years ago when I tried to use Google Domains to find a domain for my website. At the time I was trying a few and found, to my delight, that nothingofvalue.com was available.

I started the process of purchasing it and then got scared when it came time to list my personal address for ownership. I stopped for about an hour to call my father to see if he would mind if I used his PO Box as the address. When I went back to redo/complete the registration, I was told the domain had been purchased by someone else.

For the next year or two, I checked it periodically, just to see if anyone had actually built a page of it. Nope. Just squatting.

I purchased nothingofvalue.org instead and have had it ever since. I also transferred the domain to Namecheap.

</comment><comment><USER13> I remember I once searched for a domain name on Godaddy, and found that it was available. I waited a couple days before I decided on buying it, but next time I checked it was registered by Godaddy. If you wen to the address, you were directed to a website stating the domain has been "parked for your convenience", and you could buy it from them for now twice as much. I remember feeling so completely cheated I never did business with them again, and certainly never searched for available domains with them.

</comment><comment><USER14> I've experienced sketchy practices from several domain brokers and hosting services. GoDaddy is just the most widely used amongst my friends and clients --making them a necessary evil in my life--luckily not at my expense.

</comment><comment><USER15> Godaddy is for sure a scam.

They once charged me, if memory serves, $75 to resolve a complaint about one of my domains. They wouldn't tell me what the complaint was, who brought it, or how it was resolved. They just charged my card on file $75 for the "service".

I transferred my domains out and never looked back.

</comment><comment><USER16> Going to get a little off-topic here, feel free to downvote if you feel it's out of place.

Many HN users presumably saw the public launch of sr.ht a few weeks ago. I've been thinking about directions that it could be expanded in the future, and the use-cases which fit best are both (1) things I need to do to maintain sr.ht anyway, and could make into a service available to users; (2) things which are annoying to do elsewhere. To this end I'm thinking about offering domain registration. Since users pay a monthly/yearly subscription fee for sr.ht, I can just sell domains at wholesale prices and take no margin. Then you get to use the nice UI and API and so on sr.ht offers for doing DNS and domain registration (DNS probably through just pushing zone files to a git repo).

Thoughts?

<comment><USER17> While I have no doubt that you of all people could do DNS right, it seems a bit like scope creep IMO. I'm very excited about sr.ht, but also worried that it might be too much to execute all at once.

That being said, DNS records in Git sounds kinda neat. You avoid all the special authentication nonsense of "DynamicDNS" or proprietary APIs by using SSH keys, and you have versioning for rolling back configurations. Also you don't need a special UI that essentially builds zone files as you'd just have your users make their own. You might need some validation of the files before you actually put them into BIND though.

<comment><USER16> Well, in terms of scope, this falls under

>things I need to do to maintain sr.ht anyway

I already run my own authoritative nameservers and if I automated the maintenance and deployment of that, it'd only be an afternoon of hacking to make available to the public, and a weekend of hacking to add domain registration to it. I don't just work on sr.ht, too, so having a streamlined and integrated domain registration and DNS service would be great for my other projects.

<comment><USER18> Your scope, yeah, but I think the previous poster was talking about product scope.

Though I do think it could be a good idea.

</comment></comment></comment></comment><comment><USER19> I spent two hours one time transferring all my domains (~10) to Google Domains. What a relief to be done with that company. There is not one honest step in the GoDaddy flow, you really have to keep your hand on your wallet.

Disclaimer: I work for Google, no interaction with the domains team though.

<comment><USER20> How is Google's support for domains ? I am very hesitant to buy anything from Google that may require support, as an Android developer I've heard too many horror stories to trust Google in this area (basically, there is no way to even talk to a human being, you can send an email and get a canned response from a bot. You're better off talking to a brick wall).

<comment><USER21> It's exactly what you can imagine. I'd instead recommend gandi.net. It's a few bucks more but they take their motto to heart.

<comment><USER22> I posted this on the reddit too:

I tried to buy a domain with gandi. I left it in my cart for a day and then the price went up $20 dollars. I loaded up the Tor Browser, searched the same domain name and it was back at the normal price. It would stay that way even when i looked up new .scot domains. Proof: [https://i.imgur.com/7kMutbB.png](https://i.imgur.com/7kMutbB.png) . The "no bullshit" moto just sounds like Googles "don't be evil" moto, bullshit designed to fool geeks into thinking they're honest people. Does there even exist a site to buy domains that doesn't do this bullshit?

<comment><USER21> The current price on .scot domains is $49. Perhaps you're seeing a difference due to exchange rate? This is the first and only report I've ever heard of Gandi even remotely doing something like this. Unlike Google, Gandi actually does live up to its motto. And like Google, if they ever fail I'm ready to jump ship.

On what date was this picture taken?

[Edit] I just checked the exchange rate on google and 49usd is 67aud. Looks like it was just an exchange rate mixup on your part.

<comment><USER22> I think you are right, which makes me feel quite stupid. I think what tricked me is that I must have logged in to gandi at some point and then come back to look at my cart I'd made while logged off and it switched to AUD, which also uses $, so I thought it had changed without me doing anything.

</comment></comment></comment></comment></comment></comment><comment><USER23> Their domain privacy service just blackholes any emails sent to it instead of forwarding them on.

Almost cost me a domain due to their scammy set-up - since the domain was listed as "Domains By Proxy" or something similar, GoDaddy argued that it wasn't actually mine (despite selling it to me, and selling the privacy service to me) and the request to transfer couldn't go ahead.

Thankfully Nominet were incredibly helpful (and seemingly well aware of GoDaddy's M.O.) and they managed to sort it for me.

Sadly, I've just checked their site and they list GoDaddy as a registrar to use them looking for a domain, which is a shame.

</comment><comment><USER24> Couldn't we reverse this on them? For example, get a list of available domains and reverse-scrape from various users to trick the algorithm into thinking the domains were valuable?

</comment><comment><USER25> A few years ago, I typed in a domain I wanted and was surprised to see a link to Godaddy Auctions saying I could have it "Buy It Now"-style for $80. I've had miserable experiences with Godaddy so I really didn't want to do it, but I wanted the domain and figured they'd jack it up to $5,000 if I hit refresh. A few days went by with no registration details, and all I could find in my account was the receipt. I called them up and was told that somebody else already owns the domain, but, if they don't re-register it when it expires, and they don't re-register it during the 30 day grace period, then I'd have the pleasure of being able to own it. When I told the person that I could have just waited and registered it on my own without spending $80, she said that since it's a 5-letter domain, Godaddy would have put it on the market as a premium domain. Apparently, I got a bargain.

I transferred it out of Godaddy as quick as I could, and one of the first things I did at my current job was convince my boss to start transferring his 400+ domains out of Godaddy. He had no idea that the "premium domains" that they charge him $100/yr to "premium renew" aren't actually anything special, and other registrars don't do that.

</comment><comment><USER26> Link to hacker news from... 7 years ago

[https://news.ycombinator.com/item?id=2326790](https://news.ycombinator.com/item?id=2326790)

<comment><USER27> 404 ?

<comment><USER26> Nopie

</comment></comment></comment><comment><USER28> My understanding of GoDaddy over the last couple of decades is that they weren't always a bad player in the space. They are, supposedly still, the largest registrar. I don't see a future where that can ever stay true, however. I used to use them, but my final straw was their backing of SOPA in an incredibly heated time for Internet legislation which has reverberated into present day.

A lot of their market presence in the past had to do with their marketing, such as the Super Bowl commercials they ran, GoDaddy partner Danica Patrick, and some local philanthropy in Arizona, where their headquarters is.

Eventually, people found better deals with Gandi, Namecheap, and others, and their industry force evolved into one with far less impact.

Now the industry is evolving into one with no overhead with Cloudflare providing domains at-cost as companies provide value-added services which subsidize operating costs for providing domains to customers. This will ultimately put companies we've known in the past to be giants, and to this day are still publicly traded, in dire straits as they find new ways to stay relevant.

GoDaddy provides no high-value value-added services in comparison to other market leaders. So, for most who have moved on, there's no reason to go back. They are a now a middleman for no one other than small agencies or individual customers at best, who arguably do not provide any value for them either.

We'll see what happens to GoDaddys, Namecheaps, and Network Solutions when you can't charge people for domains anymore. What happened to TLS certificates will almost certainly happen to domains, too, albeit with ICANN fees remaining as the last overhead.

<comment><USER29> >GoDaddy provides no high-value value-added services in comparison to other market leaders

I don't think there's all that much serious competition for auctions.godaddy.com

</comment></comment><comment><USER30> GoDaddy made me angry earlier this summer when it broke domain forwarding when they added shortlinks. All my URLs instantly broke. Customer support said it was by design.

To fix it, we made NavHere ([https://navhere.com/](https://navhere.com/)) to be a simple domain forwarding service. Just a few weeks ago, GoDaddy announced they are going to fix their domain forwarding...

<comment><USER31> That said, domain forwarding is still broken on GoDaddy for people who wish to forward domain-a.com/* to domain-b.com/base-path/* and preserve the path.

</comment></comment><comment><USER32> This was always accepted as a reality within the affiliate marketing communities, we knew never to use godaddy services to search for an available domain unless you purchased it immediately.

I heard many anecdotal stories as consequently I owned the #1 us organic position for "available domain" and primarily referred people to godaddy and namecheap.

 _edit_ I see a godaddy insider confirmed the practice

</comment><comment><USER33> I have known a few people who think they are going to make millions selling domains. They had hundreds of domains, with auto renew. Set it and forget it. That has to got to be 50% of goDaddy revenue.

I moved over to Amazon Route 53. It's not terribly user friendly, but at least it's not GoDaddy.

<comment><USER34> I wasn't a big fan of Amazon's domain name prices, but Route 53 is by far the best DNS I've ever used in my life.

</comment></comment><comment><USER35> Godaddy got a domain I searched and did not buy, and generally the user experience is like doing business with a scammer and penny pincher. On the other hand, they found a buyer for one of my domains for $5000. Kinda of a wash.

</comment><comment><USER36> Probably off-topic, but I've always wondered how malware authors register domains that are generated by Domain Generation Algorithms, without it being trackable back to them.

</comment><comment><USER37> I just sold a domain on GoDaddy two weeks ago. Should I be afraid, that I won't get my money? I thought there was nothing to worry about, since it's such a big company....

</comment><comment><USER38> Are there any landmines to step on when transferring a domain? Seems like you pay a transfer cost but they extend you by 1 year. Easy as that? I'm ok with a bit of downtime.

<comment><USER39> You shoudn't have any downtime. Copy your current DNS records for your transferring domain(s) and input them at the destination Registrar, then initiate the transfer, and done. It is surprisingly easy.

The only edge case to check is if you are using non-standard or less common DNS record types (ALIAS, CAA) then first confirm with the destination Registrar that they support the record types you need.

Or if you want to keep things really simple, switch to a third-party DNS host before transferring and use the same name-server settings.

And yes, paying the target Registrar should extend your registration time. For example, say you bought a domain last year and paid to register it for five years (so four years remain). Now you transfer it to Gandi.net and pay their transfer fee. You used up one year originally, transferred, and it's yours for five years again. Your unused years at the outgoing Registrar 'roll over' to the new one.

<comment><USER38> Thank you.

</comment></comment></comment><comment><USER40> Totally off topic but I must. Because of the the painful UI to the horrible marketing to the elephant killing paid for by the founder, I celebrate everything anti-Godaddy.

</comment><comment><USER41> Relevant: [https://news.ycombinator.com/item?id=18632988](https://news.ycombinator.com/item?id=18632988)

</comment><comment><USER42> Couldn't this be considered "front running"?

<comment><USER29> How do you go from this post to "front running"? The guy is talking about a domain auction lasting more than 90 days.

<comment><USER42> I could be mistaken by the main point was that they are searching for a domain on Godaddy and finds it was purchased and subsequently put up for auctions moments after the search.

<comment><USER29> I doubt that's the main point. There's simply nothing in the original post that suggests this.

The guy later commented that GoDaddy had registered the domain the same day he searched it, but judging by his original comment it doesn't seem that he ever saw it available.

>Okay, so I searched for one domain name on godaddy. It was available but it was on 'auction' being sold for more than $10k.

After reading OPs post over and over again, it seems pretty clear that the guy is upset about the auction lasting more than the 90 days that was originally promised.

>The auction was supposed to last 90days. After these 90 days there were 4 views in total (all by me) and it got renewed for another 90 days and it keeps saying that the auction has started the day I searched for the domain for the first time.

>If someone is able to justify this as not a scam, please post your opinion

I think it's very weird that all the commenters seem to be assuming that there's frontrunning happening here.

I guess it's just easy to hate on GoDaddy while totally ignoring the facts.

It's _far more likely_ that this guy resolved the domain to check if it exists and got fucked by passivedns instead of GoDaddy.

</comment></comment></comment></comment><comment><USER43> Can anyone be surprised at how worried I was when I learned that webfaction were being bought by GoDaddy?

</comment><comment><USER44> I'm glad Godaddy is getting shamed. I hope they lose a ton of business over this.

</comment><comment><USER27> I had a very similar experience back in 2007. Searched for the domain, was available (and super unique). Next day ready to buy and it was up for auction.

Nowadays I would only use Google. They have a reputation to worry about if they try and pull over these tactics, unlike Godaddy and similar shady companies.

<comment><USER45> I had my suspicions about searching for domains on godaddy. Do a search for a domain, come back in a few days and it was purchased by someone else.

</comment></comment><comment><USER46> It's not surprising a company founded by an elephant murderer turned out to be a scam.

[https://gawker.com/5787676/meet-godaddys-ridiculous- elephant...](https://gawker.com/5787676/meet-godaddys-ridiculous-elephant- killing-ceo)

</comment><comment><USER47> I'm just an user, I'm not in the business of buying/selling domains.

Besides their shitty website, I never had a problem with GoDaddy.

I've been a customer of theirs for about 15 years.

Just sharing my experience.

<comment><USER48> I moved over a decade ago purely because of their shitty website. It just made me angry, wading through what could be a satire of all the annoying, shady and deceptive sales tactics that I don't think existed anywhere else at the time. I started paying more elsewhere to avoid the stress, and expected them to die off in the race to the bottom. But there they still are, and they aren't the cheapest and aren't offering anything unique. They are one of the reasons I'm so intolerant of advertising in general, because what I see is marketing driving people to give money to an abusive company, when just about every alternative is a better option. It just seems wrong.

</comment></comment><comment><USER49> Godaddy is a scam and a massive domain squatter.

</comment><comment><USER50> I use domainr.com for this very reason.

</comment><comment><USER29> What is godaddy supposed to have done wrong here? OP strangely enough doesn't seem to make any specific claims of wrongdoing.

<comment><USER51> They registered a domain soon as OP searched for it and jacked up the price, basically.

<comment><USER29> That's not what the OP says though. The OP says the domain was registered the same day he searched it on GoDaddy, he never specifies when this happened.

If you read the guys comments, it almost feels like he's going out of his way to avoid specifying this really important detail. [https://www.reddit.com/user/joevenet/comments/](https://www.reddit.com/user/joevenet/comments/)

And if this thread is supposed to be about godaddy squatting, why the story about the 90 day auction expiry? To me this definitely reads like a complaint about Godaddy auction processes and not about squatting.

</comment></comment></comment><comment><USER52> I used godaddy in 2010-2011 for domains. no problem with them. ymmv

<comment><USER52> how do I delete this. I'm sorry for sharing my experience with godaddy. I was just talking about domain registration. I am suspicious of domain name auctions. There is no way to delete comment.s I would have deleted it as soon as it went to zero but could not.

<comment><USER53> If that was your experience, then don't delete the comment. Doing so promotes echo chambers. If you are concerned about Karma, simply submit some articles to balance it out.</comment></comment></comment>


My Internship Experience With MakeGamesWithUs as a 13-year-old - <AUTHOR> http://gthinkin.wordpress.com/2013/10/18/my-internship-experience-with-makegameswithus/

<comment><USER2> Always glad to see people doing stuff at a young age. Keep learning and keep up the good work!

<comment><AUTHOR> Thanks! It was an awesome experience.

</comment></comment><comment><USER3> Presentations from entrepreneurs, a showcase with VCs and the public, and most importantly, getting a product out there on the market? Sounds like one hell of an opportunity. I wish I'd had that when I was his age.

<comment><AUTHOR> Hi Kronopath, the app isn't on the App Store just yet. It was sent for review, meaning it could take another week or so before I actually know whether it will be approved for sale or not.

</comment></comment><comment><USER4> Wish I was as lucky as you when I was your age. These kind of things just weren't available then. Keep at the good work!

<comment><AUTHOR> Thanks!

</comment></comment><comment><USER5> HI GOAT</comment>


MIT And Dropbox Alums Launch Inbox, a Next-Generation Email Platform - <AUTHOR> http://techcrunch.com/2014/07/07/mit-and-dropbox-alums-launch-inbox-a-next-generation-email-platform/?utm_campaign=fb&ncid=fb <comment><USER2> _"Inbox is an email company. Google is an advertising company. This product is our focus, and will not be 'discontinued' unexpectedly." Burn!_

Very amusing. But for all we know they will be acqui-hired, maybe even by Google, and then shifted to a different project.

<comment><USER3> I said this in the other thread and I know it sounds cliché, but we're not planning to "go away" or get acquired or something. We've always positioned this company as a long-term play, and made that very clear when hiring, raising money, etc. It's just not possible to go after something big if you plan to "flip" the company quickly.

<comment><USER4> > but we're not planning to "go away" or get acquired or something

If you've taken VC money, haven't you already gave up that choice? Despite pretenses, the VCs are going to want: a) IPO or b) acquisition.

Since you assert b) is not your plan, do you really think you can become a $100m/year company (IPO) by charging for something that Google/MS/everyone else provides for free?

Perhaps I am too pessimistic (or realistic?) about VC goals/control.

<comment><USER5> who cares what they want? If they put in the money as a minority shareholder, their options are to follow the CEO or try to change his/her mind.

Note: they're very good at the latter.

<comment><USER6> Or exercise their Board powers and fire the CEO when push comes to shove.

Nobody spends millions of dollars on something to make themselves powerless in it.

<comment><USER7> That's what the parent poster is getting at. In SV, most founding teams retain control after a seed financing, and many continue to retain control after a Series A.

</comment></comment></comment></comment></comment></comment><comment><USER8> I guess I'm a little confused here. As far as I can tell this isn't an email platform; it's a service that wraps IMAP and POP and exposes RESTful services.

The grand claims in the text makes me think they're going to provide something that replaces email addresses and provides a better protocol than IMAP but that's not what's going on as far as I can tell.

Am I missing anything? I'm not trying to be an ass and IMAP and POP suck to deal with but there are hundreds of libraries that do it with very little work required. IMAP should certainly be replaced with something better but I don't see a proposal for such a thing.

<comment><USER9> It's the platform upon which a better email can be built. The IMAP/POP wrappers provide backwards compatibility, so that you don't have to stop using the old email system while the new email is built around it. At some point, theoretically, IMAP/POP can be transparently replaced with better delivery protocols.

<comment><USER8> I disagree and agree.

You're right in that better protocols can be swapped out in this design pattern and that's fine; most decent external service consuming code does this so it makes sense in that regard.

But where I'm not convinced is in the API itself along with the location in which we are abstracting IMAP and POP at. The abstraction you could recreate most of what this service does with a language library so I don't really get why making it a service is even needed in the first place especially with so many worried about storing their data elsewhere. The API has limited ability to do push (webhooks are only good for web applications not thick or mobile applications) and I didn't really see how they're handling the dual authentication required.

But as I said I didn't want to just poopoo the idea; I'm curious as to where it goes but with version 1 I don't see what usefulness it gives me as a developer.

</comment></comment></comment><comment><USER10> You ever see those commercial restaurant spaces which seem like a good spot on paper, but every restaurant that goes into it seems to fail?

Thats kind of how I feel about all the "We fixed email" startups. A real pain point but one I'd never want to tackle since there doesn't seem to be one "I've fixed it" solution.

<comment><USER11> Hi there, Christine from Inbox here.

That's why we're tackling the problem from a platform level, not building one specific product---it's obvious to us that the ways folks are using email these days are so varied that no one thing solves them all.

A better toolset allows many different solutions.

<comment><USER12> What do you mean, "platform"? Where's the RFC?

<comment><USER13> That's unfair -- not all platforms have IETF specs (iOS, Android, AWS, etc). You might _prefer_ platforms that have proper specifications, but the presence of one is not implicit in the term.

<comment><USER12> Walled gardens. That doesn't bode well.

Still, I understand the nitpick, it's just that there isn't a word to describe them. Open Standards?

</comment></comment></comment></comment></comment><comment><USER14> > But the larger goal with Inbox is not just to offer a suite of developer > tools, but to create a new email standard. That means, Grinich says, the > company has to provide the fundamental infrastructure as an open source > package.

I really am at a loss to think of something that email _as a standard_ (and SMTP as a protocol) is lacking that requires a replacement.

There are a lot of things that I would like from an email client, but almost all of that can be done over IMAP using an MUA, and that would allow interoperability with literally every other email server out there, no matter how old the software is.

Replacing e-mail (and/or SMTP) as we know it would be a change on the order of magnitude of IPv4 → IPv6, in terms of how disruptive it would be to daily operations and how much extra work it would require just to handle the changeover seamlessly.

Unfortunately they don't go into too much detail with what they hope to do[0], so I'm left with no understanding of what they want to do that's so advanced that it requires a new standard altogether.

[0] At first glance, everything they talk about can be done using IMAP and makes more sense to implement client-side than server-side/embedded into the protocol.

<comment><USER15>
        At first glance, everything they talk about can be done
        using IMAP and makes more sense to implement
        client-side than server-side/embedded into the protocol

Take a stab at building an unicode-enabled email client that works using 90% of available client features across any one major email provider and any one imap OSS server. After a few months when the flow of edge-case bugs slows to a medium roar, take a stab at allowing customers to connect to a different OSS imap server. Then try adding support for exchange's imap.

The standards exist, but they are open to a lot of interpretation in key areas. As a result, there are a lot of interpretations. It's a painful thing.

<comment><USER3> This is exactly why we built the Inbox API.

<comment><USER16> So we can have yet another standard with weird quirks and edge cases, but also that's proprietary and promises to change in breaking ways to existing email?

The world in which Inbox succeeds at anything is just a world where we have some more webmail competitors and that's about it.

</comment></comment></comment></comment><comment><USER17> This is great. We've used ContextIO in the past (they've been great) so good to see more ways to access user email data.

Any comparisons vs. contextIO? Do you index all the data yourselves, or proxy requests to the actual mail provider?

<comment><USER11> Hi there, Christine from Inbox here.

Inbox is pretty much a superset of ContextIO. (You can also use it to send mails, and "entire mail clients" is a supported use case.)

Unlike ContextIO, we don't proxy requests directly to the backend mail store ---we run a mail sync engine and query that instead. Lots faster and gives us a lot more room to make future improvements. Data just has to make it into the datastore in the right format and then it's accessible to query via the API. :)

</comment></comment><comment><USER18> ITT: People no longer dazzled by innovative startups that promise to not go away any time soon, and that promise to change very old tech.

We're all being pessimists today and for a good reason. In the past several months alone, we've been hit by plenty of companies that trumpeted, "We're not here to get bought out!" and get bought out, and that say, "Now that we're bought out, nothing will change!" and everything changes.

Same goes with companies that try to fix age-old broken models, "We saw how fucked up [insert 20+ year old tech] was, so we fixed it!" but have either slow adoption rates, or hit brick walls when trying to solve the problems that age-old tech solved in a very messy way, or they hit the problem of not satisfying the "core necessary features" that seem to vary from individual to individual.

So, as far as this email platform goes I say, "Good luck!" and I hope it goes well but I won't be surprised if in five months I'll see a post-mortem of the company, or a "bought out" sign on their home page.

<comment><USER19> MIT in the title made me expect something free of VC strings. Picture me disappointed. Outcomes tend to match intentions. Money will lead us nowhere near the network we'd dreamt about. I'm tired of all those wannabe billionaires.

</comment></comment><comment><USER20> The problem they are trying to solve is wicked. The problem with IMAP is not that it's awfully complicated - that would be easier to fix with a cleaner and simpler library/SDK. The problem with IMAP is that every service provider fucks up in implementing it in new and surprising ways.

It's very hard to write a program to work with Gmail, Yahoo and Outlook properly without implementing their edge cases. Let alone many thousands of other providers, and many millions of privately hosted servers.

IMAP should be fixed or replaced with something that the implementor cannot screw easily. But that will likely never happen so I'm going to use this.

<comment><USER19> What would prevent us from building an IMAP successor ? Genuine curiosity.

<comment><USER21> There's an RFC for that...

[http://tools.ietf.org/html/rfc2223](http://tools.ietf.org/html/rfc2223)

There's really nothing at all stopping intelligent people getting together and "fixing" IMAP, rather than building a compatibility bridge between siloed data gatherer A and reticent data hoarder B.

I personally have zero problems with IMAP4. I run my own server. You could too... In fact if you and 10 friends want to each pay $2.00/month, you could rent and share a 48GB Linode - setup your own IMAP server with CalDav and whatever else. All secured with ssh public key only access and a free SSL cert from startssl. So you only get 4GB of storage space each... I wouldn't see that as much of show stopper for me or most people I know.

</comment></comment></comment><comment><USER22> Right, so now _all_ of my email can go through some third party's systems. That's exactly what we need in a post-Snowden world.

<comment><USER23> It's on GitHub, you can self-host it if you wanted to. It's not a service _yet_.

<comment><USER24> Self-hosting your e-mail is really not much better, from a security point of view, than letting gmail have your e-mail. Google has some of the best security people in the _world_ , if your mail is safe anywhere, it's safe with Google. The problem, of course, is that Google is definitely going to try to read your mail, use and retain your private data indefinitely.

The problem is that if you host your own e-mail server, you dramatically increase the chances of some unpatched flaw or tiny messed up configuration file causing the Russian mafia to get access to everything on your e-mail server. You probably don't even particularly decrease the risk of the NSA getting your e-mails.

This is a problem that could be fixed by new models for e-mail that utilize encryption so that you inherently don't need to trust third parties in order to make use of their services. Avoiding third parties entirely is very likely impractical and unwise.

<comment><USER25> Depends on the threat. If you host your own email, there is a whole class of legal intrusion (persuasive cops, warrants, national security letters) that you get to hear about if they want your archives or stuff that's encrypted on the wire. The same applies to corrupting employees; I'm going to know if somebody bribes my sysadmin for access, because that's me.

There's also some benefit in avoiding being part of a monoculture. Big mail providers are an enormously interesting target for both spies and criminals. Breaking into random quirky personal servers, though, has a very different cost/benefit ratio.

<comment><USER24> I heartily agree about avoiding being part of a monoculture, there are definite tradeoffs. The weirder your setup, the less likely you are to be swept up in anything bulk, but the more vulnerable you are to anything targeted. Unfortunately, it's pretty common for some quirky little open-source project to start out relying on obscurity, then become widely adopted, putting you in the absolute worst case scenario, since suddenly you're running high profile software that's never been "battle tested".

</comment></comment></comment></comment></comment><comment><USER15>
        Grinich also points out that developers can build using
        the Inbox APIs for free, without sending email data to
        a third-party.

Cool!

        In the future, however, the company will release a
        hosted version of Inbox that will allow developers to
        create applications without needing to also scale their
        own infrastructure.

Oh...

<comment><USER3> You can totally still run it yourself. But we figure most developers won't want to run lots and lots of servers to sync+store terabytes of mail data. (see Heroku, AWS, etc.)

... but you can if you want. And if that sounds interesting, maybe you should work with us? :) email@example.com

<comment><USER26> Besides syncing to a device, inboxapp stores a copy of a person's mail data on the server side?

<comment><USER3> Yes, for caching+performance reasons.

<comment><USER27> Do you encrypt anything in that case? Or do things in such a way that no rogue employee of Inbox would be able to read someone's email?

I work with email currently, and one of the core mantras we have is that nobody should be able to read the email of someone who uses our service. It's such a personal thing with so much private information, that even the possibility of someone being able to do that (especially when there are more than a handful of us) is unpalatable to everyone here, to the point that we can't do common password recovery in order to keep that information private from us. I certainly hope you are/will take that into consideration as you build this.

<comment><USER28> > I work with email currently, and one of the core mantras we have is that > nobody should be able to read the email of someone who uses our service.

Sounds wonderful. Where do you work?

</comment></comment></comment></comment></comment></comment><comment><USER29> I hope that there will be some standardisation in these efforts. First there was Fastmail's JMAP, then Google's announcement of extending GMail's APIs and now this.

IMAP has a lot of shortcomings, but at least it is a standard.

That said, Inbox' approach seems nice in that it wraps a new API around 'legacy' protocols as well.

<comment><USER3> Michael from Inbox here.

I actually looked pretty closely at JMAP when it was announce. It's really just a JavaScript wrapper around IMAP conventions. Plus, there's no way to actually use it-- it's just a document spec.

The thing people don't realize about IMAP being a "standard" is that there are tons of extensions, weird bugs, provider-specific edge-cases, no comprehensive tests, no reference implementation, etc. If you mean it has an RFC, then yes it's a standard. But actually working with it is still hellish.

We're trying to fix email from a pragmatic, developer-focused point of view. We just want to build new apps and services without the struggle of old protocols or dealing with character encodings. The philosophical argument can come later when the dust settles.

<comment><USER30> This I strongly agree with: what we want now is a RESTful JSON API for email retrieval and querying. IMAP was hairy 20 years ago and is stuck with its design choices forever.

But I can't see such a thing taking off unless it's Free.

<comment><USER31> But _why_? Email does not seem RESTful to me. Not the slighest.

Read an email and then flag it as unread? Save and delete instead of move? Batch operations that are not atomic? What happens when the connection breaks then?

Synchronous command requests, really? IMAP solved that 20 years ago. Do we really want a glorified POP to replace it?

What is the purpose?

<comment><USER30> What do you mean by "does not seem RESTful"? It's a set of data. Writing a webmail app should be more like any other CRUD app. I don't see why that damages atomicity. Nor do I see why synchronous command requests are a problem, this works fine for AJAX. Especially if you can issue more than one at once. Store the mail in MongoDB or similar (possibly detatching the bodies of large mail for storage convenience). Stop using rfc822 as the wire format.

"Move" is greatly simplified if "location" is a tag field like gmail rather than anything to do with filesystem storage.

The purpose would be building web apps that manipulate email.

<comment><USER31> The question is why you think a RESTful data model fits the problem. It is a model that fits when resources are published globally, when the CRUD methods are enough, whose purpose is to enable global caching and make hyperlinks possible.

Pretty much none of this is true for email. You don't even want global caching here. You want responsivity, and a rich and extensible data model.

How would you move an email? How would you control whitelisting? Spam scoring? Folder ACLs? How would you sleep until a mailbox changes? Even if you _could_ represent these things as resources, it's going to be much more hairy than IMAP with the performance of POP.

The evolution of email has been completely opposite of dumbing it down. Users expect calendaring and global contact lists, and here you have the impedance mismatch _again_. Look at the mess that is CalDAV, and that's DAV which is much richer then REST.

Regarding asynchronous commands, I don't know what you think it has to do with AJAX. It is the Javascript that is asynchronous in AJAX, not the HTTP requests. Web browsers typically implement it using multiple connections. This is a problem. Do you really want connection pooling (so a server can serve _fewer_ clients)? No, you want an evented protocol. Such as IMAP.

And again, you probably could do it given enough work and come close to the performance of IMAP for most end users, but why would you? It doesn't really map to the REST architecture.

It you would rewrite your comment but s/REST/RPC/ I would not object to it. I would just think you were from the past :).

<comment><USER30> Are you arguing that the correct way to do webmail is to have an IMAP client in Javascript running in the browser? I think we're talking at cross-purposes here. Suppose I am writing a webmail client. Suppose I am doing this in the usual modern way of writing web applications, which is to retrieve data in JSON or XML and render it client side. I wish to retrieve some data items called "email headers" and "email bodies". I want the backend to look as much like a database as possible, relational or non-relational. I want the backend to explode mime/multipart, canonicalise things as UTF-8, fix quoted- unprintable etc. That's the application I'm aiming at. Furthermore, I'd like to standardise the transport layer enough that people can write interchangeable web frontends.

As far as I know IMAP itself doesn't have any features for whitelisting and spam scoring? Nor calendaring nor global contact lists?

"Move" email specifically would be implemented as updating the "location" table. An email would be allowed to be in multiple locations (qv gmail labels).

<comment><USER31> Am I that unclear? No, I'm not arguing that the correct way to do webmail is to implement IMAP in Javascript. (How would that even work?)

I'm arguing that a RESTful implementation of the same functionality IMAP offers would -- by necessity -- have problems with responsivity and/or concurrency. Webmail clients should be a case in point here.

Do note that when Google implemented the GMail app for Android, they created a protocol that looks a lot like RPC and is nowhere near REST. These people are not stupid and if the REST architecture made sense for mail clients you would see it reflected there.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> To me a next-gen e-mail platform is one that has _end to end encryption_ enabled by default, like say what Dark Mail is trying to achieve. Seeing how Dropbox has never once considered to add E2E encryption for its storage service, and how they're hired the anti-champion of privacy, Condoleezza Rice, I'm not expecting that to happen here - ever.

<comment><USER33> The moment they announced Condoleezza Rice I closed my Dropbox account and moved to SpiderOak (playing with OwnCloud now).

Not having full e2e encryption is an absolute deal-breaker for me. The service looks nice and I like that I can play with the code, but without encryption ( _especially_ when Inbox App offers hosted email), there's nothing to write home about, _for me_ (and I'm sure IA solves issues other people have that I do not).

</comment></comment><comment><USER34> In my opinion, the reason no one add "features" to an email client because it is just as fine as is. Please tell me one thing that a user (power or just every day user) really needs that is not supported by a reasonably recent email client? And no, every few people use emails as a todo list.

<comment> grey-area _Please tell me one thing that a user (power or just every day user) really needs that is not supported by a reasonably recent email client?_

Sure, here are some ideas I'd like to see:

\- Effortless encryption

\- Verified identity

\- Pull model rather than push model (like twitter, requires verified identity, would eliminate spam and work for many email addresses which you don't want to be public)

\- Attachments which are uploaded once, not duplicated and sent over the network

\- Better filtering (this one isn't bad currently, but can always be improved)

\- Integration with other forms of messaging

\- Better support for public messages like mailing lists or mass mailings, e.g. URIs for messages or parts thereof (attachments etc).

\- Single signon (get rid of passwords on websites by producing an email replacement so awesome people use it as a central identity)

...etc. There are plenty of possibilities, and the ones at the top of this list I think would benefit a lot of people and make things like spam a lot harder.

I'm not sure this particular service is going to succeed (it reminds me of app.net in that it targets developers, which is probably a bad idea for mass- market tech), but there are _plenty_ of things we could improve about email and email clients.

<comment><USER35> A lot of these are protocol changes, not necessarily client changes... And I don't see many protocol changes coming for email...

<comment><USER36> Yep, totally, email is probably as good as it will ever get. Pack up the bus guys, let's go home.

</comment></comment></comment></comment><comment><USER37> Im a bit amazing that the name "Inbox" was available for a product involving email.

<comment><USER38> Names are always available when you have some money to invest in buying rights and domains.

<comment><USER39> The name is Inbox App, not Inbox. Nothing special there.

I'm willing to bet that they'll have significant problems with the name if they try to call it just "Inbox". First, they didn't even get the inbox.com domain, theirs is inboxapp.com. Second, they don't seem to have a trademark on the product name as "Inbox" and I doubt that they'd get one. Third, their company name is Inbox App, Inc., so it doesn't seem like they did anything special in terms of buying rights or domains.

<comment><USER38> You are probably right about the company name, but inboxapp.com is still a pretty good domain name. Looking at the whois record for the domain[1] shows that it was registered in 2008. Moreover, archive.org[2] tells us that it was parked at GoDaddy for some time, before they purchased it in 2013. So, they probably invested a bit of money in a good domain name, yes.

[1]: [http://whois.domaintools.com/inboxapp.com](http://whois.domaintools.com/inboxapp.com)

[2]: [https://web.archive.org/web/20110201102718/http://inboxapp.c...](https://web.archive.org/web/20110201102718/http://inboxapp.com/)

<comment><USER39> Nice job on the research. You're right that they may have actually paid a premium for the domain. Though, I dislike domains with words like "app" in them as they tend to pigeonhole the product.

</comment></comment></comment></comment></comment><comment><USER40> it's great to see friendlier APIs for working with email! is Inbox intended more for building email clients, compared to something like Switchboard ([http://switchboard.spatch.co/](http://switchboard.spatch.co/)) which is more for processing inbound email?

any plans for a WebSocket API? seems like it would be easier to receive pushed emails on an existing socket, than registering a webhook and then sending a push notification out-of-band to the client to fetch new emails.

<comment><USER41> Your comparison between Switchboard and Inbox is solid. Switchboard is being used for tasks like sending "new email" push notifications to mobile clients, or uploading attachments to dropbox. I haven't used Inbox yet, but I'm excited to try it out.

It's great that Inbox is also built on top of IMAP. The new Gmail API is great, but an application which takes advantage of it is locked into using only Gmail. By building from the standard, Switchboard and Inbox are cross- provider.

</comment></comment><comment><USER42> Github repo: [https://github.com/inboxapp/inbox](https://github.com/inboxapp/inbox)

</comment><comment><USER43> The FAQ page for Inbox states "You can use Inbox to replace _nearly all_ the functionality of IMAP and SMTP."

Implying that there is some functionality of IMAP and SMTP that Inbox doesn't handle. Thats OK. In many cases people are willing to lose some functionality to gain other more valuable functionality.

However, nowhere on the website can I find a description of what IMAP and SMTP functionality Inbox doesn't handle.

If I'm going to invest my time in trying out the product, it would be great to know upfront what features it currently doesn't support.

I think the Inbox team would be better served by just being honest and saying "Hey with Inbox you get all these awesome features, in exchange for losing this one feature..."

</comment><comment><USER44> If this can result in more hosted email offerings, it's excellent. I'm pretty positive a simple API + a complete documentation + OSS reference implementations, as they exist can help achieve that.

</comment><comment><USER45> Inbox seems like a potentially confusing name for an email-based product.

</comment><comment><USER46> So, I really don't understand what Inbox is. From what I'm reading, it looks like an API to access email messages: perform queries, modify them, etc. Does that sound right?

If it is, then what are the "email applications" that require this API? To me, the problems with email are its plain-text nature, spam and managing the vast quantity of mail we get. Does Inbox help here?

</comment><comment><USER47> Has someone tried it already? Any first impressions?

</comment><comment><USER48> In plain english can one explain whats broken with iMap/current email and how Inbox fixes it ? I m missing something sure here

<comment><USER49> I wouldn't say "broken", but more "stuck in its ways" since it's a huge standard, used by everyone, and as a result, network effects (literally everyone online uses email) keep it from being improved in any way.

It's also hairy, slow, and a bit buggy.

Some concrete issues: [https://gist.github.com/mscdex/5329227](https://gist.github.com/mscdex/5329227)

Since everyone's using this standard, the only way forward is to either jettison the whole lot and start fresh (network effect means this will never happen), or to wrap it, maintain compatibility, and slowly get your wrapper accepted (which is at least possible in this universe).

</comment></comment><comment><USER50> Not a single mention of encryption, security, PGP or GPG. In my book, that makes it a non-starter as a new email platform in 2014.

</comment><comment><USER51> If you're using the USS Enterprise as one of your key visuals, you're probably taking yourself too seriously.

<comment><USER3> To boldly go where no APIs have gone before... ;)

More seriously, we're super focused on MS Exchange support for enterprises. Ping me if you'd like preview access to this: email@example.com

</comment></comment><comment><USER52> Unless it's dramatically more secure than current email platforms, it's not the "next generation" of email.

Anything hosted in big shared data centres in the USA cannot be more secure. That's last year's thinking, not "next generation".

</comment><comment><USER53> Perhaps I missed it, but what's the business model? Is it the (forthcoming) SaaS version?

<comment><USER3> Yes.

</comment></comment><comment> old-gregg Very neat, congrats on the launch! Quick Q: are there any reference/demo clients out there that use this sync engine?

Even though I'm probably not you target audience, but I'd love to replace Outlook web client (and Gmail too) with something else.

<comment><USER3> Yeah definitely!

iOS: [https://github.com/inboxapp/inbox- ios](https://github.com/inboxapp/inbox-ios)

JS/Angular: [https://github.com/inboxapp/inbox.js](https://github.com/inboxapp/inbox.js)

Full API docs: [https://www.inboxapp.com/docs](https://www.inboxapp.com/docs)

</comment></comment><comment><USER54> I can image how to use inbox by Google Gmail API. It's a good news for developers. They don't need to build a email server to receive email message or add a SMTP part, and only use one way to transmission application's data.

</comment><comment><USER55> Hey guys, for those who want to try the Inbox API (and don't want to install Vbox like me), I just have installed and configured a inbox instance into a terminal.com container! Feel free to test it and let me know what do you think.

</comment><comment><USER56> What's worst here is not that by using this I would be giving up all my emails to them, but the fact that if I created an app using their SDK all my users would unknowingly be giving up their emails to this company.

</comment><comment><USER57> So it's an e-mail client as an platform/SDK? That's kind of neat.

<comment><USER3> Thanks! :D

</comment></comment><comment><USER58> I've heard "the future of email" before: [http://techcrunch.com/2012/05/31/first-impressions-on- fluent...](http://techcrunch.com/2012/05/31/first-impressions-on-fluent-the- startup-promising-the-future-of-email/) This seems very similar to fluent.io - an email startup by Dhanji Prasanna. [http://rethrick.com/#rip- fluent](http://rethrick.com/#rip-fluent) [http://www.businessinsider.com.au/australian-ex-googlers- ema...](http://www.businessinsider.com.au/australian-ex-googlers-email- fluent-2012-2)

</comment><comment><USER59> What I would really love for someone to fix is how _slow_ email is. Why is it so much slower to send an email than an SMS or FB message with the same contents?

<comment><USER60> There's no free lunch. FB (Or rather, Apple and Google's Push Notification Server they depend on) and SMS are centralized messaging systems and that's why they can be fast, whereas email is decentralized and designed to be "good enough", which makes it slow but as a result has other benefits that centralized messaging systems can't have

<comment><USER59> I would personally much rather PAY for a centralized system that works better than "good enough".

<comment><USER61> Until the centralized system fails. Email is resilient and will still be working post-apocalypse, where as, FB will probably not.

</comment></comment></comment></comment><comment><USER62> Interesting choice for logo design. It's as if someone took the Dropbox logo and shifted the camera up to an overhead shot.

</comment><comment><USER63> I wish this app had more support for PGP

</comment><comment><USER64> So, does it work with IMAP & POP?

<comment><USER3> Michael from Inbox here.

IMAP, yes. Gmail and Yahoo! Mail now, expanding to others ASAP. (We depend on the `CONDSTORE` extensions right now for performance, which isn't always supported.)

POP, no. My time machine didn't go back that far. ;)

But you can help add it? github.com/inboxapp/inbox

<comment><USER65> > POP, no. My time machine didn't go back that far. ;)

Imho this remark comes across as quite unprofessional. Ignoring the fact that POP and IMAP weren't born that far apart in time (wikipedia says 84 and 86 respectively), POP is one of the two standard email client retrieval protocols. Most mail clients support it for good reason.

Its no problem that inbox.io doesn't support POP3, its a feature you may or may not have it.

What bugs me, as someone who likes to implement ancient protocols and backward scompatible clients (because its the right thing to do), is your stupid remark about it. Nobody cares that you think POP3 is old fashioned and that you were too smug about it to implement it. Furthermore POP3 and IMAP are like completely different protocols for completely different use cases. I don't fucking use IMAP because its fucking centralized model doesn't make any fucking sense in my decentralized world. POP3, even being two long years older, works just fine. So don't be a dick and just say you didnt't implement it. There may be reasons, but you didn't mention one. You just bashed a perfectly fine protocol for no reason and pissed me off.

</comment></comment></comment><comment><USER66> Your claim that your product will not be discontinued is worthless.

If you're so sure of that, put your money where your mouth is, and offer an SLA with a contractual minimum duration you promise to keep the service up, and significant monetary penalties if you fail to meet it.

Doesn't sound like a good idea? Then shut up.

<comment><USER3> (Michael from Inbox here.)

Ouch. We're just a few hackers trying to fix broken developer tools.

Any claim is just a claim, for sure. We know that it's a long road to earn trust of other developers. One of the (many) reasons we made the sync engine open source was so that developers could run it on their own metal without trusting us. Transparency is really important to us.

This is just the beta announcement of our API. I'd love to hear any comments you have on what guaranteed level of support+performance you would need for a hosted product. We're working on a hosted version now (so you don't _have_ to run it yourself), and developer happiness is the #1 priority.

<comment><USER67> But if you believe in the claim, why not sign a contract that brings some validity to the claim?

<comment><USER9> Agreed. Those kind of binding agreements are the only way you can guarantee that something won't change immediately upon acquisition, and an interested party may still buy your company if you have such agreements. They may just have to wait a while to shut you down if that is indeed their plan. However, I don't really know if that's a better alternative than just shutting down upon acquisition, lest a false sense of security be provided to the users.

</comment></comment></comment></comment><comment><USER68> Sure the folks at inbox.com will be amused by their choice of product name.

</comment><comment><USER69> How is this different from Context.io?

</comment><comment><USER70> Ha ha! I clicked on this article's HN comments thinking "Wow, this sounds a company ready for their Incredible Journey to begin." (c.f. [http://ourincrediblejourney.tumblr.com](http://ourincrediblejourney.tumblr.com)) And lo, the most upvoted comments here are all expressing the same sentiment.

I do not recall before today just looking at a new company's elevator pitch and muttering "Best wishes with the acquihire, y'all". Something subtle's shifted in the way we perceive startups, lately...

But the above is just my observations at my own behavior. I do wish the best for this company!

<comment><USER71> The fact that the pitch includes a swipe at Google shutting down services kind of invites the "yeah but are y'all a future acquihire?" counter-skepticism. I think they could probably just have left that whole subject out of the pitch; it's an approach to competing with Gmail via "negative advertising" that I think has relatively little upside and opens up a can of worms. (On the other hand, it's an obvious enough counter-swipe that I'm not sure it's helpful for the entire HN discussion to be about it.)

<comment><USER72> Indeed. They've inadvertently refocused attention from an otherwise interesting discussion about problems and innovation in Email into one about acquihires and company lifetimes. There's a PR lesson in here folks.

</comment></comment></comment><comment><USER73> Can someone please educate me as to what the differentiation is between past email protocols, messaging protocols, and these types of APIs? I'm starting to get this sense that we are just moving towards a singular communications protocol and the name, e.g., email or chat, is simply a matter of UI design and layout and maybe even unnecessary simulation of behaviors and actions.

</comment><comment><USER74> Sorry, but I don't see how yet another attempt at an abstraction layer on top of the existing protocol is even remotely interesting.

It's time to move on from email as it exists in its current form, and towards a new fundamentally secure persistent messaging model(whatever that ends up being).</comment>


Machine Learning for Hackers - <AUTHOR> http://shop.oreilly.com/product/0636920018483.do

<comment><USER2> I hate to be high brow here, but I'm just waiting for O'Reilly to release Brain Surgery for Hackers. Some things are just better learned the hard way, sitting down and getting a more thorough introduction.

<comment><USER3> I think these books are not really meant to be a PhD education but more of a tutorial introduction to the field. What O'Reilly is doing right now is really important. As Steve Yegge said, they are "trying to provoke a culture change."

Would-be brogrammers will find these books, read them, and graduate from cat- picture projects into more sophisticated applications that can solve real computer science problems. It matters less whether the readers of these books actually get a comprehensive understanding of the theoretical knowledge behind them, then it does that they enrich readers and spread the desire to learn and attain true understanding of the field.

Steve Yegge reference: <http://www.youtube.com/watch?v=vKmQW_Nkfk8>

<comment><USER4> You underestimate the value of ML for monetizing cat pictures.

</comment></comment></comment><comment><USER5> This Machine Learning in Action from Manning uses python instead of R: <http://www.manning.com/pharrington/>

PS. Attended Machine Learning class in hacker dojo with the author, he's a bright guy. Hopefully the book will be as good.

</comment><comment><USER6> I would love to know more about this book but it seems to not be released yet and there are no reviews. Not sure what the point of posting it is or why it is up voted. More details would be great.

</comment><comment><USER7> Have interacted with both authors, however briefly. These are both smart guys operating outside of the typical CS fields who have figured out how to apply cutting edge computational techniques to their specialties and deliver meaningful insight. Really looking forward to reading the book.

</comment><comment><USER8> In corollary to this post, does anyone know what's up with the Stanford Machine Learning course? Haven't heard anything since the delay

<comment><USER9> It should be going live soon. I got an email about the Model Thinking class which launched a preview at <http://www.coursera.org/modelthinking/lecture/preview>

Hopefully that means they're getting ready for the other classes to go live as well.

</comment></comment><comment><USER10> Promising title, doesnt appear to have a table of contents currently.

<comment><USER11> From Safari:

    		Preface
    		Machine Learning for Hackers: Email
    		How This Book is Organized
    		Conventions Used in This Book
    		Using Code Examples
    		How to Contact Us
    		Using R
    		R for Machine Learning
    		Further Reading on R
    		Data Exploration
    		Exploration vs. Confirmation
    		What is Data?
    		Inferring the Types of Columns in Your Data
    		Inferring Meaning
    		Numeric Summaries
    		Means, Medians, and Modes
    		Quantiles
    		Standard Deviations and Variances
    		Exploratory Data Visualization
    		Visualizing the Relationships between Columns
    		Classification: Spam Filtering
    		This or That: Binary Classification
    		Moving Gently into Conditional Probability
    		Writing Our First Bayesian Spam Classifier
    		Ranking: Priority Inbox
    		How Do You Sort Something When You Don't Know the Order?
    		Ordering Email Messages by Priority
    		Writing a Priority Inbox
    		Works Cited
    		Books
    		Articles
    		About the Authors

<comment><USER12> using R seems a bit strange to me -- i have nothing against R (use it regularly), but not exactly a "hacker" language. this seems like an ideal book for python, but R?

<comment><USER13> I had the same feeling when I saw this. R is a great tool for statistics, very useful when you need to do in-depth statistical analysis (analysis of variance, etc.). It doesn't strike me as a good choice for a hacker's book - which makes me think about their reasons to use this word, hacker. Maybe they are just trying to benefit from the buzz that it generates these days?

<comment><USER12> indeed, this was my first reaction as well...seems like a bit of marketing gimmick to toss the word "hacker" into the title.

</comment></comment></comment></comment></comment><comment><USER14> Just a quick note if you're interested, this book is similar and is an absolutely fantastic 'applied beginner' ML book "Programming Collective Intelligence"

[http://www.amazon.com/Programming-Collective-Intelligence- Bu...](http://www.amazon.com/Programming-Collective-Intelligence-Building- Applications/dp/0596529325/ref=sr_1_1?ie=UTF8&qid=1328721596&sr=8-1)

</comment><comment><USER15> This seems like a field that could pretty easily be commodified. I can imagine a service like the Google prediction API could meet the needs for this kind of tech for many companies.

So while it's certainly an interesting field, I wonder how many hackers are really going to need these skills.

<comment><USER16> The biggest problem with machine learning occurs when people subscribe to the belief that it's a black-box solution. The truth is that you _can't_ just drag-and-drop your data into a pre-existing solution. The types of algorithms you use depend on the types of problems you're trying to solve (e.g., classification, regression, clustering). The data you collect depends on the algorithms you use.

Sure, prediction APIs could arise that give detailed use cases for each algorithm, but then there's a problem with the fringe cases: you might not know that two pieces of data are so heavily correlated that they completely shatter a conditional independence assumption, for example.

As a hacker who originally subscribed to the belief that a thorough understanding of machine learning was overkill, it is without hesitation that I admit being 100% wrong. The truth of the matter is that when it's done properly, artificial intelligence and machine learning ought to be inextricably linked with your core business processes.

<comment><USER15> I can certainly see a role for somebody that understands the tradeoffs of each of these algorithms and that understands how to properly select and prepare dataasets. But I wonder how many people will really need to be able to actually _implement_ these algorithms.

<comment><USER17> That was also the whole point of the stanford ML course. TO teach exactly that skillset.

Sure we did some basic implementations in octave, it helps to have some idea of the internals. But that wasn't the goal of the course.

<comment><USER4> Well, no. ml-class was a series of demos. Plugging in a formula is 1-line developing an algorithm. The original cs229 is more like what you describe.

</comment></comment></comment></comment></comment><comment><USER18> I have an early review copy if this book and know both the authors. It's good and I highly recommend it!</comment>


SEO Toolbox and Collectible Card Game  - <AUTHOR> https://www.thegamecrafter.com/games/serps-and-spyders-pack-1

<comment><AUTHOR> This is a game concept that's been bouncing around in my skull for over three years. It's called SERPs & Spyders and the website is here: <http://serpsandspyders.com>

Currently, there are three game packs available. The title links to the first game pack. The second game pack is here: [https://www.thegamecrafter.com/games/serps-and-spyders- pack-...](https://www.thegamecrafter.com/games/serps-and-spyders-pack-2) and the third game pack is here: [https://www.thegamecrafter.com/games/serps-and- spyders-pack-...](https://www.thegamecrafter.com/games/serps-and-spyders- pack-3)

Every collectible card reveals a different SEO (Search Engine Optimization) tactic that can be used in game play, or as a reference/learning tool.

P.S. I should mention I've done professional SEO for about five years now, and "recreational" SEO for about 12 years.</comment>


Covid-19 Is a Pandemic - <AUTHOR> https://www.theguardian.com/world/live/2020/mar/11/coronavirus-update-live-news-uk-health-minister-italy-lockdown-australia-us-china-stock-markets-outbreak-latest-updates <comment><USER2> BBC: [https://www.bbc.co.uk/news/world-51839944](https://www.bbc.co.uk/news/world-51839944)

PS the OP's link is a "live" link so the top (i.e. WHO declares pandemic) story might scroll down.

</comment><comment><USER3> Dupe: [https://news.ycombinator.com/item?id=22547223](https://news.ycombinator.com/item?id=22547223)</comment>


A Look Inside LEGO's Design Offices - <AUTHOR> http://sneakhype.com/architecture/2012/02/a-look-inside-legos-design-offices-in-denmark.html

<comment><USER2> Now _that's_ a creative workplace! How inspiring that is!</comment>


Man-with-a-hammer syndrome - <AUTHOR> http://blog.figuringshitout.com/man-with-a-hammer-syndrome

<comment><USER2> I get this aaall the time and the only way I have of dealing with the "must tell the world" part is to post anonymously on some forum I don't care about and then run away and not even look at the responses.

Later on I can look back at it and use the idea in a more considered essay.</comment>


Procedural Space Game – Limit Theory Cancelled - <AUTHOR> https://www.rockpapershotgun.com/2018/10/01/limit-theory-cancelled/ <comment><AUTHOR> Very sad to have read this, I followed his dev-blog. It was very interesting and inspiring, but also educational to know your limits.

Josh did not know his limits, as he literally went insane over the amount of work he tried to accomplish. The goals on the one hand and the reality on the other, but it never got close enough. And now he finally gives up, after he recovered from his total breakdown and got back on track.</comment>