tomwalsham

I'm in the 'sooner rather than later' camp, and have one more key driver.

Insurance. As soon as human drivers are provably poorer than automated drivers, the cost to insure a meat driver goes up. It will not take long to build a very strong case for the lower risk profile once the early adopter vehicles take the road.

You just literally described trains and buses. Don't assume the form of the vehicle remains the intimate 3-across sedan style.

The best way to improve email delivery is to understand that email addresses represent humans. Address validation and long-term deliverability is primarily a problem of social engineering, not technical.

Ordinarily I'm in favour of things that can improve data quality with minimal user friction, but in this case while it looks like an attractive solution, it's both dangerous _and_ broken.

It's dangerous because if you repeatedly open empty SMTP sessions with major ISPs (and some neckbeard boxen) to validate addresses, you will rapidly fall onto blacklists. Furthermore existence of an address says nothing of the end user's ownership of that address.

It's broken because of the myriad crazy responses that mailservers return -: 5XX errors for soft-bounces, 4XX errors for permanent failures, deliberately dead primary MX server... The web's email infrastructure is so massively fragmented and quirkily non-RFC-compliant you just cannot rely on technical solutions to these problems except at scale of an ESP (disclaimer: I work at PostageApp.com, a transactional ESP, and we tackle this problem on a large scale)

Finally, it fails my 'Spammer Sniff Test': If you think of a clever trick to improve email delivery/opens/responses etc, it's been thought up 10 years ago by spammers and long since added to blocked behaviours in email protection infrastructure.

Check for '@', and craft your email verification process to incentivize following through. For long term delivery (to bypass the mailinator issue) provide value, pure and simple.

This is definitely good email sender behaviour, but I would hesitate to purely put this down to the altruistic notion of 'keeping your inbox tidy' - Inbox Zero is a problem fairly isolated to the Newserati and similar thin slices of population.

Fact is, Email Deliverability is increasingly engagement-driven these days, especially with the major ISPs, and additionally sending email costs money.

--

At its most basic level, a sender's 'spamminess' is determined by percentage of spam reports against overall deliveries from that IP. Levels over 1% put your reputation in the 'severe' category, and risk lack of inbox delivery, blacklists and more. Having more engaged users leads to a better ratio - for this reason alone keeping your recipients 'fresh' is valuable.

Additionally, another common pattern of email (or more correctly a sender:template combination) falling into the 'spam' category for an ISP is to see a few percentage points in drop, followed by a complete /dev/null-ing. When the initial drop happens, whether or not your recipients correct that as a false-positive will determine whether you get the Full Monty. Naturally therefore removing the least engaged users has a significant beneficial effect on overall deliverability.

These days though, it's getting more complex, nuanced and ultimately more individual.

Gmail moved some time back from a centralized concept of 'spam' to a much more personal view by using your positive and negative engagement signals: opens, clicks, replies, 'delete without reading','report spam' etc. They explicitly modify the visibility of email in your personal inbox through the 'important' flag (http://support.google.com/mail/bin/answer.py?hl=en&answe...), but there is good evidence that negative engagement can carry an email all the way to the spam box for a given user and consequently affect the overall deliverability.

This has a strong benefit for Gmail in that they become much harder to 'game' - something Google Search team also has plenty of experience in avoiding. They essentially eschew the classic SMTP 5xx return codes for 'Accept All, Ask Questions Later' in all but the most egregious cases, and provide little to no feedback for senders to troubleshoot delivery problems on the basis that if your users want your mail, it would be getting through.

--

The second primary motivator here (still with me?) is that sending email also has a non-zero cost which is almost entirely driven by sheer subscriber count and delivery attempts.

Consider a typical mass-marketing email with a 10-15% open rate, delivered multiple times a month. Even assuming a varied engagement profile that mailer is engaging with at most 50% of their list over the month. A simple list of 1MM recipients would incur an increased cost of a couple of thousand dollars a month to send into the vacuum of disinterest.

There is, in certain circumstances, a benefit to be gained from 'eyeballs on subjects' for brand awareness, but that metric is near impossible to track, and as mentioned above unopened emails can be deleterious to your overall delivery to the more engaged segments.

For both the reasons highlighted above, mass-market email has been using the 're-engagement' method (breathlessly described in the OP as a customer-driven action), to keep their lists fresh and costs down.

I do applaud the application of metrics to provide intelligent subscription management. At PostageApp we see the best delivery rates come from our clients who take active interest in the concept of humans at the end of the SMTP pipe. The growing provision of engagement data through APIs is helping drive solutions like FAB's, and the end result is a better experience for the user. That said, this particular innovation came not from the consumer-friendly high visibility consumer and SaaS markets, but has been around for many years in the risk-heavy line treading bulk marketing industry.

I always like Eric Ries' take on this. You can test the theory:

If you have one 'great' idea, chances are you have more. Take your _second_ best idea and do all you can to get someone to steal it. Target individuals; shout from the rooftops; describe it in detail to everyone you meet. Nobody will run with it.

To execute on an idea you have to be personally invested, have domain knowledge and be deeply passionate. Ideas in isolation rarely have the qualities that would make them require 'stealth mode'. In fact, the best ideas come from a series of iterations on great execution.

Create success and you will have copycats and parasites, no question (Groupon, iPad, Paypal...the other examples from this thread), but at this point you should be in a position to leverage first-mover advantage, funding, and your more developed longterm roadmap.

People may copy your MVP, but Uber is a classic case where their first and prominent product (UberCab) is clearly not the actual longterm strategy. Cloning UberCab is really creating a cargo-cult startup.

The exception here would be markets - the Samwer brothers have a particular niche in cloning successful North-American scoped startups for European and African markets, but at the point you hit their radar, the 'Stealth Mode' boat has sailed anyway.

I would add one additional point of caution:

The Rails community seems unusually keen on the 'curl example.org/script | sh' as an installation method (see Pow.cx etc.).

I'd usually recommend reading these scripts before execution, but for now especially so as it would seem an obvious target if people are looking to leverage this exploit to acquire more boxen.

At PostageApp.com we focus on transactional emails, which these days are moving heavily towards HTML email as a standard now that deliverability is much more focused on IP reputation than content.

We provide a templating system which allows you to build and preview with separate HTML and CSS, and we compile to inline CSS at runtime to ensure compatibility with the majority of email clients.

The painful thing to remember is that html/css for email is a weird mix of HTML3 and HTML5 - meaning some major providers only allow for basic functionality, but other platforms support the bleeding edge while omitting some of the simpler aspects. In the end your demographics will strongly influence where you focus your efforts.

The templates from Zurb here are a great basis - as a start on a responsive email boilerplate this will be great value to the community - individuals using this for customization will hopefully push the development of these bases further.

Just as a reference point, this brought to mind an old app (in the desktop sense) from 2001 - http://www.16color.com/

The site is still up, and they claim 40,000 movies were created between 1999 and 2004 (timeline from the DVD : http://www.amazon.com/Best-16-Color-DVD/dp/B000BD98AO/)

I don't think content volume is an issue if the right channel can be found, but you're right that the Instagram comparison is not the correct order of magnitude.

disclaimer: I have no relation to 16color, apart from enjoying it over a decade ago, and just discovered one of my animations was actually on their DVD.

My personal favourite quick-fix (which doesn't stand up to targeted attacks, but is a very effective band-aid), is to put the following : <input type='text' name='website' style='display:none'>

Then disallow any form submissions server-side which contain a value for 'website'. Automated bots can't resist filling out that field.

These sorts of issues (primarily related to auxiliary functions in grep, sed, etc) can cause portability issues when developing locally for linux systems, but no worse thanks, say, writing for fedora on an Ubuntu box. Brew is okay but a bit sparse. For me I mostly miss Gnome

A nice visible reason why the Rails/Node/OSX FOSS community really need to stop doing the following sort of thing for their installations (seen most recently on yeoman.io, but common to get.pow.cx, npm...)::

curl get.totallytrustworthyapp.io | bash

The above examples are obviously legit, but encouraging this kind of lazy access to even local privileges from arbitrary remote scripts (and Yeoman even asks for sudo in a super-friendly way), is the modern equivalent of padlock.gif on your payment page - training poor security practices.

Primarily because the Web is a Pull medium, whereas email is Push. To get my eyeballs on the web you first have to trick me into going to your location. To get my eyeballs on Email you just have to know my easy-to-guess personal address.

There's an interesting disconnect between the public perception of email transmission and the reality, even from technically savvy observers.

The view you're espousing of the 'basic' nature of email can usually be summed up as : "It's just sending a bunch of ascii from machineA to machineB"

The reality of the complexity of email transmission is that it's an ad-hoc communications network built around an evolution of RFC standards, amended to accommodate i18n, combined with myriad third-party solutions and walled-garden 'standards' to combat a combination of real and perceived threats such as SPAM, DDoS, backscatter, spoofing, joe-jobbing, image encoding...

The main question around your proposed Auto-Updated system is what combination of these solutions are you using, how much are you paying for someone to maintain this, and do you care about the ability to customize for the inevitable false-positives caused by the necessary filters in place.

For large organizations there are solutions - Exchange being one - but they still require large amounts of custom work. The reality of Business A's needs still differ greatly from Business B, even though we're essentially just talking about sending 150Kb of ascii from machineA to machineB.

This is a great overview for people looking to run their own servers, with one of the clearest explanations of DKIM and SPF I've seen. Awesome. As a counterpoint, I'd like to add that from the point of view of an email sender (our company PostageApp is a transactional email service), individual Postfix (Exim, qmail, Exchange...) setups receiving email for small organizations are one of the largest headaches we face.

Large ISPs - Gmail, Hotmail, even Yahoo and AOL to an extent, are predictable. If you play nicely, tick the technical boxes and listen to feedback (SMTP return codes, FBLs, bounces etc) you get great deliverability. Even mid-size ISPs and larger companies usually have some reasonable visibility - responding to postmaster@, internal blacklist checkers, etc.

There are, though, still a nontrivial percentage of organizations and individuals who run their own setups using anything from 1998 'standards' through to modern configurations, combined with other filters like custom SpamAssassin rules, an out-of-date Barracuda appliance, or quirky ASSP installs. They often exhibit some unpredictable behaviours - sending permanent hard-bounce codes for simple inbox-full errors; marking completely innocuous email as spam; requiring three attempts for every email to block spambots (delaying delivery by hours); publishing broken MX records...

Dealing with these can be tricky - even finding the correct admin to contact is often an exercise in futility, all the while, the users are not receiving their critical emails. I guess my message is, when running your own email setup, Caveat Hack0r; if you're not in it for the long-haul, including updates, testing and responding to inquiries, you should really consider going with third-party providers.

I completely agree. These days there's very little wrong with sending HTML-based transactional email provided you've covered your bases on all other potential flags and send as multipart with a plaintext component. At PostageApp many clients have amazing inbox delivery with HTML transactional, and the benefits - improved tracking, better funnel direction etc. - outweigh the minor delivery drawbacks in many cases.

Frankly, many who send 'plaintext' transactional in fact end up sending as HTML these days in order to facilitate open tracking from embedded images, so aren't gaining much beyond avoiding the minor issues like 'HTML_IMAGE_RATIO' etc.

edit Apparently the MailRox invite email _is_ an HTML email for the exact reasons outlined above. I can see no reason why you wouldn't want to add some visual sparkle to this based on that fact. Incidentally, you're sending without a plaintext component which can cause delivery problems at some ISPs.

It was my first association as well, but I assumed it was used in a jokey linkbait fashion, rather than trying to trade off the reputation of McColo ;)

Always great to see new tools in the email space - would love to get an invite to check out the system and potential integrations.

Some stream of consciousness thoughts on the history of internet communities, particularly those centred around tech.

Usenet had immense value in well defined subgroups prior to the Eternal September (and for some time after, regardless of what people may say). IRC ha(s|d) similar values, and remains a force within niche communities on the tech side. Slashdot was an early mover in the moderated community space which had to arise from the newfound populist web.

I still think /.'s comment moderation was superior to the HN system (pre and post-visible comment scores), but the firehose was too late and too poorly implemented to solve editorial issues.

In the middle of this, Kuro5hin rose and fell, metafilter grabbed some component of the serious moderated discussion which it still retains. Fark came and went. Boingboing, SA, b3ta. All significant for a time but not names on people's lips today.

HN cannibalised a significant portion of /., but failed to convert the greybeards - the discussion here is noticeably different because of it (and lacking the perspective sometimes).

Digg suffered greatly from demagogues (as does HN to an extent), descended too rapidly into linkbait and celebpop trash, and fell to Reddit. The redesign was just the nail in the coffin of an already dead community.

Reddit became a very granular experience from its initial tech focus, with a current frontpage of dubious intellectual interest, but their popularity speaks wonders for the ad-hoc community created by diverse interest groups with a common central park. They struggle with discovery for new members, and an apparently descending base age group.

Communities come and go. Small herds migrate towards the latest point of interest and some stick. Groupthink is a large driver of community malaise, certainly within the tech discussion arena. Individuals dominate submissions and discussions and evolve to minor demagogue status. Some communities evolve to tackle a smaller arena than just the general topical discussion field, but topicality remains critical.

Quora has tackled 'big answers'. StackOverflow 'correct answers'. These are some minor elements of the value of the larger communities, much in the same way that Hipmunk, AirBnb etc have abstracted value away from Craigslist. Hyperlocal is the next big thing with FrontPorchForum and NextDoor tacking non-technical local discussion.

I still view the approaches to these problems as relatively unsolved and ripe for disruption, in particular the algorithms related to subject and comment popularity, user 'karma' (for better or worse), and approachable comment threading when a userbase grows beyond the 'scan a single page' scale. I'm not convinced that a one-size-fits-all approach will ever work, but even within niche tribes there remains a problem with staying 'current' while avoiding alienating the 1-2% who drive much of the discussion.

I fully expect a new dominant discussion forum to arise in the tech scene in the next couple of years, but Lobsters seems to be a kneejerk reimplementation of HN that even if it claws some traction would have to evolve rapidly to solve problems rather than dangling the 2013 model of a 2012 carrot.

Speaking of weirdly complex, I've always been a fan of the totally deadpan delivery of the 'Straight Line Tutorial' [gimp lacks a 'line' or 'shape' tool] http://www.gimp.org/tutorials/Straight_Line/

Sending HTML-only email is still a large spam flag, even at major ISPs, independent of the concerns about client compatibility.

At PostageApp our solution to the problem is a templating engine where you can write your HTML/CSS separately and we inline it at run time to ensure client compatibility. We then provide a separate Plaintext tab with an 'import from html' function which does most of the work for you for managing dual formats.

Email deliverability these days is heavily based on sending IP reputation, to a lesser extent domain reputation, and finally content.

Once you have ticked the core boxes of compliance - clean html in your templates, never send just HTML email but use multipart with plaintext, be sure of your MTA's RFC compliance, sign with DKIM/SPF - then reputation now strongly hinges on recipient behaviour at the largest ISPs. Marking an email as Spam is an obvious flag, but additional heuristics such as open rate, clicks, deletes etc. are used to determine your relationship with that recipient, and your reputation over time.

The most common issues these days with content-based filters come from smaller independently run installs - SpamAssassin, ASSP etc. As a legitimate sender you can usually cover inbox delivery to 90% of recipients by building a solid reputation on your IP with the large ISPs. The final 10% will be related to content, linked domains etc. at the smaller services.

A large reason for the growth in email-as-a-service platforms is the reputation component is already taken care of, and you can focus on content and engagement instead of the finicky aspects of core email delivery.

This strikes me as somewhat of an edge case - to add a full rules engine for what is essentially a very app-specific set of behaviours.

One main reason the application is the best place to manage these rules is that it's rarely just the email content that dictates the engagement pipeline. Whether a user has interacted with a component, or logged in, etc, are all app-side variables which may affect whether or not you wish to send a given email.

That said, one method some of our customers use at PostageApp to simplify some of the logic is to pass a UID to the API based on the unique parameter sets - e.g. recipient + template + hour - and rely on the engine to discard the duplicate API calls.

Can you comment on the status of Priceonomics (YC) in this context? They're building a rich interface on top of CL listings data, presumably using 3Taps to get the volume of data without drawing attention.

Is the endgame for these companies to replace the content source, or to hope (or fight for) a legal precedent to 'open' CL data for third party usage?

While I like the idea, I feel the dollar sign is a poor choice of character.

There are plenty of free chars that wouldn't expect to cause conflicts with things like sass, or appear at a glance to be a variable reference.

The representation of this move as a gateway for 'glory hunters' or wantrepreneurs is surely at odds with the intentions or the likely implementation (not that many of the applications no doubt fit this).

I don't imagine the interviews to be along the lines of "Do you really want this? Do you reckon you can make something awesome? Great, you're in", rather that this is more for successful teams 'in between ideas' or great combinations of proven individuals. Otherwise I find it hard to see what the selection criteria could be.

Different people have different aspirations, and not all them involve Sr. Moskovitz' opinions of 'success' or 'impact'.

While many jurisdictions hold the same, that 'facts' can't be subject to copyright, there is often a (lobbied for) grey area surrounding compilations of facts.

The usual suspects in these cases are recipes, Geodata and my personal favourite - Premier League Football fixtures. The latter is in the final stages of a European court challenge that is rightly claiming licensing such a simple set of data for thousands of pounds is absurd: http://www.bbc.co.uk/news/business-17218968

rπ is a great project, but it's hardly out of left field.

There have been plugins for years, at seriously affordable prices. You can buy a netbook for $100 these days and run Windows/Linux on it happily.

rπ is interesting because of its positioning as a learning platform equivalent to the BBC Micro which nurtured David Braben and many of the other backers. Not because it holds some magical quality over Gumstix, BeagleBoard, PandaBoard, CottonCandy, GuruPlug, DreamPlug, Arduino etc.

Asher's Gridlinked supposed a limited set of society [operatives & wealthy] who could manage this fulltime connection, and even then it was perceived as unhealthy.

Wikipedia has undoubtedly changed how our generation views knowledge, but it's still a pull-technology. Outbound messaging will still be a push-technology (nobody wants to compose an email of their stream-of-consciousness, and brains are poorly wired to retain full structure in mental 'RAM')

Wetware doesn't add significant differences to the existing protocols - merely a more rapid input mechanism than checking your phone. Assuming contact is voluntary, people will not opt for the PubSub model for comms. If you choose to use it for trivia, caveat emptor.

Some would argue Email is little more than USPS over IP.

I think the most interesting aspect of modern communications - accidentally in the 90s, deliberately in the post-twitter-era - is the simple addressability of people.

There was a tradition of letter writing for centuries (visit the British Library), but it required some level of introduction to connect. The academic roots of email broke some communication boundaries (to the time-detriment of prominent academics), and Twitter has opened the same addressability to celebrities and field-leaders (with a more voluntary twist I would say).

Facebook (and Twitter to some extent) solve one of the biggest problems of email which is the concept of verified sender.

I add it to the paradigm shifts as it resolves (in its own [large] namespace) a longstanding problem with email.

I add it to the 'transient' list as its solution is purely driven by network effects which leaves it vulnerable to the next player sideways market dissolution.

This perspective is interesting when applied to communications.

Parlay. Courier. Pigeon. Mail. Telegraph. Telephone. Transatlantic Comms. Fax. Early Internet. Email. Text Messaging. Live Chat. Voip. Twitter. Facebook Messages. Video Chat.

It's a naîve summary of communications history, but look at the persistence of some of the early players. Many have not been replaced to this day - snailmail, POTS, Fax, Email, Chat, VOIP, Videochat - there are fundamental reasons to stick with certain technologies (Fax, POTS, FB and Twitter excepted). There is disruption to be had, but there is still massive value in some of the oldest methods, with some evolutionary shifts.

The services need to adapt, and incumbents do restrict progress, but the 'email killer' notion is not well conceived. Most people don't use email as a 'todo' - that's an extension, not a replacement. This is why Rapportive has a market, but is not _the_ market.