From YC Rejection to 10,000 Users in 1 Month (with stats) - <AUTHOR> http://blog.codiqa.com/2012/03/from-yc-rejection-to-10000-users-in-1-month/ <comment><USER2> Believe it or not I like this being the top story. We know there are lots of bugs in our process and we want to hear the bug reports.

I went back to look at the application. It fell immediately below the threshold for invitation to interviews. I.e. if even one of us had given them a grade one step better, they would have made it to interviews.

When we make mistakes, it's usually in this phase. Most of the time when we screw up it's by not inviting a group to interviews, rather than by interviewing them and turning them down. So this startup is exactly where a mistake would be most likely to occur: in the applications that fell just short of the cutoff for interviews.

The good news is, we'd already decided to fix this problem. We're going to do 3 interview tracks for s2012, which will let us interview 270 groups instead of the 180 we did last time.

If we'd done that last time, we would have interviewed these guys. But last batch was the first time we did parallel interview tracks at all, and we needed to test whether it worked for 2 before we went to 3.

<comment><USER3> I don't know if I'm going to be able to express what I feel but I'll try.

YC "bugs" are

\- startups that are accepted and fail

\- startups that are rejected and fail, _but would have thrived had they been accepted_

(Of course this last kind of bug is extremely difficult to track down.)

But if a startup makes a killing after being rejected by YC it means they didn't need you.

If you consider this a bug, there's some kind of moral problem because it means YC is trying to siphon every promising team in order to maximize YC's success, independently of who YC is likely to help more.

You're not just betting on horses, you're also training them: it seems what you should want to maximize is YC's impact...?

<comment><USER4> You're considering success or failure as a binary outcome. It's possible that a startup is accepted and wouldn't have failed anyways, but that being in YC makes it a bigger success than it otherwise would have been (through mentoring or other intervention by YC). My understanding is that is the sweetspot for YC anyways - everyone is a winner there.

<comment><USER3> > _You're considering success or failure as a binary outcome_

I think that's how it is, yes, and PG seems to have stated as much; in essence, you either die or don't die; if you don't die, the scale of your success depends on a lot of things that are beyond your control.

(Actual quote from PG: " _The formula for the success of a startup includes a random multiplier of roughly zero to a thousand._ " — <http://news.ycombinator.com/item?id=3050280> )

If one subscribes to this point of view then the purpose of YC is to help startups not die, and the purpose of the YC admission process is to

1\. select all startups that have a chance of not dying if admitted (eg, refuse startups that don't stand a chance in hell of not dying)

2\. if the sample from #1 is too large, reduce it at the low end first (startups that are not very likely to not die) but maybe also at the high end (startups that seem certain to not die no matter what)

Maybe reducing the selection from the high end is just plain stupid / counter productive, but if you don't do that, it's not very clear why one would be in this business in the first place (as opposed to other lucrative businesses).

<comment><USER5> I think you're both right. Success can be understood as binary, depending on how you interpret it. You either fail or you don't. But YC can help you find that faster than without YC. So there's room for improvement even if success is binary.

These guys got 10k users in a month. But maybe they'd get 100k in 3 if they had YC. Even if you understand that either way it would be a success anyway. It's still reasonable to assume that it would be a worthwhile deal for them. If YC missed the opportunity to help them get even better, even faster. It's reasonable for both sides to treat that as a bug.

</comment></comment></comment></comment></comment><comment><USER6> I just want to add one thing: The quality of the presentation, design, and execution is better than many Ycombinator start-ups (at launch day/ first couple of months). I haven't tried the actual product, but from outside it looks neat and well presented.

Now there are lots of pretty damn good sites that YC alumni are making from launch day; but the fact that a good number isn't, suggests that PG might want to improve his filter process a bit.

<comment><USER7> > suggests that PG might want to improve his filter process a bit.

I'm not sure how this is related. From what I've observed, PG selects promising founders, not great site-builders. Is it fair to expect all of them to create beautiful sites?

<comment><USER8> yes. If you in theory pick the "best of the best" you expect .... the "best". that include the visual packaging and presentation of the companies products / services.

<comment><USER9> I agree. Having a great website is very important and these guys look professional on day one.

<comment><USER10> The pressure on them to have a good website is stronger than for most startups, because they are selling a web development tool.

</comment></comment></comment></comment></comment><comment><USER11> It's great to see bootstrappers getting some well deserved love. Lots of attention goes to the startup lottery winners and it's good to have a reminder that you really can do it without funding just as well.

<comment><USER12> Not only that, but the longer you can delay taking funding, the less of your business you'll have to give away.

I hate the thought that getting funded is like winning the lottery. Yes, it is absolutely necessary for some startups, but far too many seem to treat it as an end in itself (presumably there are bragging points associated with being able to say you've been funded to the tune of X million)

Bootstrapping encourages you to keep your costs tight, focus on profit and revenue, ship early, quickly and often, and build something people want.

<comment><USER11> Bootstrapping profitable companies also have more leverage when ready for funding.

My use of the term startup lottery was meant to describe the communual celebration and veneration of quite often earning some runway.

The businesses that need it are ones that have to find a product-market fit and a repeatable business model. I just think you're better equipped to find validated scalable business models once you've done it without money.

There's nothing quite like having to find and build what people are willing to pay for out of the gate instead of putting it off. From where I see it, I don't see enough technologically complex startups that need a runway, and in hindsight could have been built without funding.

The startups that would, tremendously benefit from the coaching, introductions, and business model development are rare, and special, and maybe that reflects in the small number of startups accepted to Y!. The rest shouldn't consider themselves a failure either... this startup certainly fit the mantra build something people want (and will pay for)

</comment></comment></comment><comment><USER13> I'd never heard of Codiqa until I read this post, but I'm glad I did. Really impressive app, I'll definitely be using this to build mobile apps in the near future.

</comment><comment><USER14> Congrats guys! I wholeheartedly believe in bootstrapping over funding. Keep that company to yourselves. I played around with Codiqa on the jquerymobile site and what you've put together is truly impressive. I've worked with startups in the past and I haven't seen any as well put together.

Need a marketing person? Give me a call.

</comment><comment><USER15> I've been putting off developing a mobile app for my startup. With codiqa it looks like I can get a decent one going in a weekend. I'm pretty stoked.

</comment><comment><USER16> Well done guys! Your web site looks pretty great and I'll be trying it out in a sec. I wondered myself if submitting early is a wise decision. I submitted our application a month before the due date but then we changed our idea entirely. I would hope the guys didn't read the original one and moved on.

Edit: I also think that YC should not be what decides whether you create your startup or not. It is great to see you guys kept going. The people that decide to change ideas or abandon their startup because of not getting into YC tell me that they are pretty good at picking people that aren't serious about creating a successful business.

<comment><USER17> I like the edit. Anyone that would stop working on their startup because they didn't get funded by YC or TechStars probably shouldn't be doing a startup in the first place.

</comment></comment><comment><USER18> This is what i like to hear! In the future, more and more start ups will be the ones choosing who to get funding from. Power always lies with those who create. Congrats, and keep up the good work!

</comment><comment><USER19> Max & Ben are some of the best developers in the midwest. Very excited for this project and for them!

<comment><USER20> Agreed, Great product and Great write up. Keep up the amazing work!

<comment><AUTHOR> Thanks guys!

</comment></comment></comment><comment><USER21> Congrats on the success here. You asked for some suggestions in the blog post. I'm going to make them publicly for the benefit of other HNers but if you want rationales and don't want the followup public just find my email.

1) Strongly, strongly consider capturing CCs at signup. Yes, this takes a bit more work. Yes, this will decrease your conversion rate. However, you're going to get more people successfully charged than you do currently.

2) There exist things you can do to increase user engagement with the app which will increase conversion rate from "user" to "signup", even if you don't take advice #1. I have a video coming out in a little while about this. Short version: go take the free trial of Balsamiq Mockups and take copious notes about what they do. In particular, note how Balsamiq doesn't start you out with a blank screen and note the timing and frequency of prompts for you to signup. Implement both of those things. Your conversion rate will increase.

3) You captured my email address for a "paid" signup. Good! I got no email from you. Bad! You should, bare minimum, hit my inbox with "Thanks for signing up for Codiqa. Your free trial lasts until XX/YY." followed by the best three bullet point sales copy you can come up with, linking back to your site extensively. Why? Because I already forgot your domain name (literally true) and statistically speaking I already forgot I signed up for Codiqa. Hitting my inbox is a free chance at recapturing my attention tomorrow when I do my morning email pass.

4) But wait, if one email is good, isn't five emails better? YES! Put a wee little checkbox on your signup form saying "Can we email you a free course about JQuery mobile? Five emails, absolutely no spam, opt out any time." You'll get 40%+ signups. If they sign up, you hit them on day 0, day 6, day 15, day 20, and day 28 with emails of approximately the following format.

 _Thanks for signing up for a free month-long course on JQuery Mobile by Codiqa, the jQuery mobile design app you used recently. (You asked for this when you signed up. Don't want it? No problem, click here.) This is your 2nd email out of 5. Today's topic is how jQuery mobile cuts app development costs while increasing revenue.

(h2) jQuery Mobile Cuts Development Costs by 50% (/h2)

Paragraph of copy. (~300 words) Link to codiqa docs or blog in here somewhere.

(h2) Another bullet point (/h2)

Another paragraph.

(h2) Another bullet point (/h2)

Another paragraph

Conclusion paragraph goes here. Early in the email sequence the conclusion paragraph just mentions your service, establishes expectations for the next email, and invites them to email you at any time. Later in the sequence you get salesy as heck._

What does salesy as heck mean? By the fifth email you should, if you're good at writing and jQuery Mobile, have your most engaged customers eating out of your virtual hands. The fifth email is less about education and more about one focused case delivered by their favorite jQuery Mobile expert on why buying the $30 a month plan, specifically, today, is the best possible thing they can do to improve their life today.

Execute correctly on this and you will _print money_. How much money? Just a comparable: for BCC, which is _far_ less sophisticated on the email than this trick is and which has _terrible_ unit economics, I make about twenty cents per email I send. If I tell you how many orders of magnitude that number can be improved by, four different consulting clients are going to demand my spleen sauteed with a glass of chianti.

5) Charge more! Or at least give an option for charging more. $30 a month is rat droppings to a business doing mobile development. (You will not get that feedback from some HNers. That's OK. Five hundred HNers refusing to buy your product plus one business charged $500 a month = $6,000 of revenue a year.) Put a $250 a month plan in there. You _will_ sell it, to someone who a) does not need to pay $250 of his own money to buy it and b) receives well in excess of that much value from your service.

<comment><USER22> _Strongly, strongly consider capturing CCs at signup. Yes, this takes a bit more work. Yes, this will decrease your conversion rate. However, you're going to get more people successfully charged than you do currently._

Does anyone else have any other opinion on this? I am currently trying to decide whether CC should be a mandatory field or not for my app (which will have a 30-day free trial). What kind of impact on conversion are we talking about?

<comment><USER21> You'll lose a _lot_ of signups. On the other hand, your signup-to-actually- pays conversion gets _dramatically higher_. (Appointment Reminder captures CCs at signup and will successfully charge north of 50% of those accounts at least once.)

<comment><USER3> It would be ok to lose signups from people who would not ever buy your product, but I don't think that's the case.

I for one, subscribe to a lot of SaaS but would never put in my CC number just for a trial.

And what about corporate customers? I think many subscribers can come from corporations where someone somewhere tried the product and liked it, and then made sure his company paid for it. If he had to enter his CC# before he could even try he would probably not do it.

<comment><USER23> #1 _least useful insight_ to be gleaned from HN for people selling software:

Data points of HN readers who would never do X or would be annoyed by Y in the process of evaluating your software.

 _Fixed typo_.

<comment><USER3> "cleaned"?

I think the target population matters. If you're selling to teachers or dentists, then you should speak to teachers or dentists to learn what they will do or not do.

If you're offering a jQuery framework, then HN seems pretty relevant as far as the people susceptible to subscribe to your services.

<comment><USER23> Don't sell software development tools to HN'ers.

</comment></comment></comment></comment></comment></comment></comment><comment><USER24> Great idea and it does look very slick and well executed, but from the little playing around I did it just didn't feel as fluid as a desktop app would. I'd definitely prefer a native desktop application to html and js, perhaps with an option to view and tweak my creations with the web interface when I'm off site.

</comment><comment><USER25> Y combinator should only be one of the avenues to be explored by an entrepreneur. My team (PayGuard) submitted an early application hoping that they would have more time to look at it, we still plan to update it before the March 28 deadline. We will apply again in the winter if we don't get in this summer since we're already quitting our jobs anyway. Getting accepted in the program will certainly jump us in the fast lane but we will not even slow down if we don't get in. My team have debated and made improvements to the idea for the past 6 months then we realized that the time for theorizing has ended and the time for building a product is now. We can't wait to test this out in the real world because we think there is a serious need for a payment system specializing in long distance and cross-border transactions.

</comment><comment><USER26> Any chance you have screenshots for Gobuzz, or a more thorough explanation of product, or feature list?

<comment><AUTHOR> Gobuzz was basically google alerts for people and companies that matter to you. We would send you an email each day (or more) with news about these people and companies. Near the end we also supported NLP stuff to find new people mentioned alongside your important contacts.

I still think it's a missing piece of the news world, but we lacked experience and did not dig in and focus.

<comment><USER26> I am working on what could be considered an MVP for GoBuzz. Did you guys use Google Alerts and souped it?

<comment><AUTHOR> No, we did the indexing and searching ourselves utilizing Solr and using a document service (can't remember the name, starts with an S, which was pricy). This let us take out a lot of "fuzzy" tokenization requirements and rely on pretty exact matches in content. I'd love to talk more about it with you. My email is in my profile.

<comment><USER26> Definitely will do. Thanks.

</comment></comment></comment></comment></comment><comment><USER27> Am I reading this right? 10,000 users - 1,400 on free trial = 8,600 paying subscribers.

If so, congratulations! =)

<comment><USER13> The blog has a graph showing around 1500 paying customers, which is still amazing (nearly $15k / month revenue!). I'm guessing the missing 6000 odd are staying on the free plan.

<comment><AUTHOR> Sorry, that's misleading (though I do wish :)) There are about 1500 customers in a trial plan that hasn't expired and doesn't require a credit card, so we will only convert some percentage of them to paying customers.

However, we just pushed an update last night that has dramatically increased our conversion rate from free to paid trials. Only time will tell by how much!

<comment><USER28> I'm surprised the potential here wasn't recognized; seems like a no brainer given the target market (one that's growing ridiculously fast with no signs of slowing down) and the obvious level of quality! Of course what doesn't look like a no brainer with the benefit of hindsight ;) Out of curiosity what change did you make that led to your conversion rate increasing so dramatically? You mentioned something in your post too, but didn't elucidate.

<comment><AUTHOR> For the free builder we added a feature to immediately upgrade and save your work in progress in your dashboard, instead of just telling you to upgrade, forcing you to decide between losing your work or doing it all over again.

</comment></comment></comment></comment></comment><comment><USER29> I played with your app on the jquerymobile site... what immediately frustrated me is that it doesn't seem to be possible to align elements to the bottom of the frame. At least have an option for Footer elements!

</comment><comment><USER30> Checked out the homepage on FF 11.0 and the gray text under "Pure jQuery Mobile" shows up as an unreadable light gray (vs. Chrome where it shows up fine). Might want to check that out.

<comment><AUTHOR> Hmm. Thanks for pointing that out, we'll look into it!

</comment></comment><comment><USER31> Compliments on the execution of your site, platform and branding. This is well deserved success. Keep pushing and reapply to YC, I you want to, you'll make it!

</comment><comment><USER32> Congrats guys - very interested to see what happens when the free trial period ends for the users who joined after Codiqa showed up on the jQuery Mobile site.

</comment><comment><USER33> Really cool. Something that I'm going to look into in the future - one of the very few online tools that I might actually use!

</comment><comment><USER34> It just goes to show that even though others don't share your vision, you shouldn't necessarily give up on it.

</comment><comment><USER35> Well done and looks quite useful - bookmarked for the future. However, I have a really hard time reading some of the copy (contrast) on my laptop: <http://i.imgur.com/fRzAe.png>

<comment><AUTHOR> What browser are you on? Thanks!

</comment></comment><comment><USER36> Somewhat off topic, but what do you Codiqa guys think about Sencha Touch 2?

</comment><comment><USER37> Codiqa seems really awesome. I bookmark it for this week end : There is StartupWeekend in Oslo. I will advertise it there and I'm sure you will get many subscription from Norway this weekend.

</comment><comment><USER38> Interesting aside? <http://maxlynch.com/a-website-design-trend-that-needs-to- die>

<comment><USER39> I disagree with that. A lot. The Pricing page is one of the most viewed pages on a typical app sales site (in my experience, at least), and the one that does the lion's share of the selling. People head to it straight away for a reason, and they need to be able to find it without effort - hence the obvious title. It's too important to not be bold and explicit.

<comment><AUTHOR> Which is why I didn't take my own advice this time around :)

</comment></comment></comment><comment><USER40> users , revenue beats everything else. well done.

</comment><comment><USER41> Congrats guys! And way to represent Wisconsin!

</comment><comment><USER42> Gotta admit,

I was blown away by the builder interface design.

Well done, guys.

</comment><comment><USER43> Since you guys are at it, may be I can ask.

Is there a little something extracted from jQueryMobile, which lets me use only 'form-styling' of their otherwise huge piece of work? I want only the relevant css and javascript out of the entire thing.

Any help would get a huge hug from me. And thanks, in advance.

BTW nice work with Codiqa, I am in. [Edited for grammar]</comment>


ZeroKit for Realm: Easy End-To-End Encryption - <AUTHOR> https://news.realm.io/news/end-to-end-encryption-for-realm-by-tresorit-zerokit/ <comment><USER2> > If you're building an app dealing with highly sensitive data, we definitely > recommend you check out ZeroKit and give it a try!

ZeroKit's website says they offer "hack proof encryption" and a $50k prize with a quote from The Next Web about "1,000 hackers" failing to break it.

If I'm handling highly sensitive data, I'd prefer any service I'm using to do that have multiple third party security audits on a source code level. Look at TrueCrypt's audit -- which gets into actual lines of code and details potential attack vectors -- as an example. Without any kind of auditing, it's a very tough claim to be hack proof.

Not to mention the fact that $50k might just not be enough to entice reporting. It's a good bounty for sure, but if you can compromise highly sensitive data sources, it stands to reason that the value on breaking that crypto is much, much higher than $50k.

<comment><USER3> Good catches. ZeroKit seems too much marketing vs. too little security.

</comment></comment><comment><USER3> From reading this, one of the lynchpins seems to be a user password that encrypts a keychain containing stored key material used in the encryption.

This article doesn't say enough for me to attempt using this as a security product.

What are the key sizes? What is the kdf used to create them? How many iterations? What entropy requirements are enforced on the passwords? Where and how are the keys stored on the other side of the connection? How do the keys get there in the first place?

Also, what mode of AES is used? What bit strengths?

There is a lot that is unsaid in this, and what is said uses marketing not security terms. Together these lead me to believe there weren't security people involved in the actual design.

<comment><USER4> We are working on fully detailed whitepaper, meanwhile you can read about some of this in our documentation. Here is some clarification: The user password is critical, because we need some kind of secret from the user, as we want them to be able to log in from multiple devices. The password requirements are entirely application dependent, we don't handle them: we provide feedback based on zxcvbn that the app can use to judge password strength. Regarding kdfs: the user password is first stretched using scrypt, then we use pbkdf2 to derive different keys for a few different uses. These keys are used to encrypt the user profile (which is just a collection of generated keys) before storing on the server. The keys derived from the user password won't travel to the server, they never leave the client, only data encrypted by it does. This data is mostly just other keys, we don't store any user data. We use AES GCM-256 Most keys are 32 bytes, for asymmetric key exchange we use the X25519 curve.

<comment><USER4> Ah I forgot, I'm one of the developers working on zerokit

</comment></comment></comment><comment><USER5> From my reading so far, it sounds like ZeroKit's stores the private keys? Am I mistaken? Because if so, this is definitely not end-to-end encryption because ZeroKit is a middleman that can be attacked to gain access to keys.

Edit: It says ZeroKit doesn't have access to the password, so asking for clarification here - is ZeroKit running entirely on the client then? Or do passwords ever get sent to the server (even if they are not stored or are session encrypted)? If that is true, why does one need to make a ZeroKit API call? Edit again: Quote from the article "which enables you to log in a ZeroKit user on the server", perhaps cool that they have this option, but that is a huge red flag to me that there is a server side attack vector.

Full disclosure: I work on a competing system that has uses real end-to-end encryption. It works like this:

\- First, PBKDF2 extend a user's password into a proof of work.

\- Use that proof of work to AES encrypt/decrypt an ECDSA private key.

\- Now use that private key AES encrypt/decrypt private data, or a public key of a trusted user to encrypt/decrypt private messages.

Note: The user authenticates strictly against their device, the password is never sent to any servers. Same with the private key, it can only be derived from a local process PBKDF2 extending the password (to prevent brute force attacks) and decrypting the private key with the proof of work. The private key is never shared or known by any middleman servers.

To read more about how this works, see a working prototype demo, and watch our 1 minute animated explainers on cryptography, check out this link: [https://github.com/amark/gun/wiki/auth](https://github.com/amark/gun/wiki/auth) (Note: All our code is MIT/ZLIB/Apache2 and open for auditing).

<comment><USER4> Hi, one of the devs here working on ZeroKit. We encrypt everything on the client, so the it is end-to-end encrypted. We only store the private keys on our servers in an encrypted form. The server only provides ACL (so users don't get access to encrypted data they shouldn't, even if they wouldn't be able to decrypt it), checks the password using SRP-6a and provides OpenId Connect that realm uses to authenticate the users

<comment><USER5> Thanks for the more info.</comment></comment></comment>


OAuth.io - OAuth that just works. - <AUTHOR> http://oauth.io <comment><USER2> With respect, this is yet another library that should be a small piece of open source software rather than a hosted service which I'll probably eventually have to pay for and which is likely to eventually go defunct, requiring me to rewrite my code to use another library. It's useful, but not big and important enough to be its own service. _Grump._

<comment><USER3> Occasionally I wonder whether the mantra to "solve your own problems" when looking for startup ideas is making things harder for ourselves.

We stand on the shoulders of giants, the least we can do is help lift others to that level.

If you were to build a business by implementing other people's cloud based product, be it an OAuth provider, MapBox, Embedly, Mailgun, AWS, etc... the barrier to profitability has been raised significantly. The raw costs remain low, but the costs for even a low number of users is quite high.

Maybe this is just the natural order though. It's never really been possible for the author of a lib to be able to charge, let alone charge on a recurring basis, before.

</comment></comment><comment><USER4> Interesting. It took me a minute to figure out what you're actually doing here, but once I found the important bit on the page ("Setup your API Keys in OAuth.io"), I can at least be confident this isn't a glaring security concern. :) And yes, that was a legitimate concern when I first looked at it, given how little information is currently available.

While building <https://foauth.org/>, I had wondered if it'd be possible to do something like this, but it wasn't really my use case so I didn't really pursue it. I was more interested in people just trying to get access to their own data, so I built a solution for that side of things.

Still, I can speak from experience that wrangling 50+ OAuth providers into a single system is hard enough, and trying to provide a unified API to all of them is even harder. I'm not sure how many sites need to support that many sites, but for people like us trying to simplify the API for others, it becomes a pretty big necessity. As it is, <https://github.com/gulopine/foauth.org/tree/master/services> is something of a living tribute to the differences between the various service providers.

So yeah, I'll be very interested to see where OAuth.io goes, and for anybody else here who just wants to get their own data (but not run your own service), you might also want to checkout <https://foauth.org/>.

<comment><USER5> OMG I needed something like foauth.org a couple of weeks ago. Oh well for next time, now I know.

</comment></comment><comment><USER6> There's no shortage of simple OAuth consumer libraries out there, what I really want to see is a simple way to set up my app as an OAuth _provider_. As far as I know there's nothing out there to make that simple yet.

<comment><USER7> Or even if there was a simple, detailed guide on what your own OAuth needs to do to be secure - and a basic overview of how to implement it (not language specific, just concept-wise).

<comment><USER8> The TLDR version is: use https and OAuth 2.0, and this guide: [https://github.com/Mashape/mashape- oauth/blob/master/FLOWS.m...](https://github.com/Mashape/mashape- oauth/blob/master/FLOWS.md)

<comment><USER9> Why Oauth2? I've read about it being less secure [http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to- hell...](http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/) but would like to hear the case for it.

<comment><USER8> Well if you implement OAuth 2 properly, you'll prevent session fixation and hijacking attacks, and with https you will also prevent man-in-the-middle attacks.

The hueniverse guy was one of the people drafting the standard and as far as I can tell he laments that the providers can return a "bearer token" instead of a "mac token". That means the token is sent on every request to the provider, and without https it can be intercepted. But with https everything is fine!

OAuth 1.0 didn't rely on https to prevent MITM attacks an instead used the "mac token" to sign each request to the provider, along with an increasing timestamp/nonce to prevent replay attacks.

[http://www.codinghorror.com/blog/2012/02/should-all-web- traf...](http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be- encrypted.html)

</comment></comment></comment></comment></comment><comment><USER10> I wish there was more there than a mailing list signup and a teaser. What is it you're actually showing HN? Some animations?

<comment><AUTHOR> yes it's maybe more a kind of ASK HN if this API could interest people as we are finalizing it

<comment><USER10> Ah, cool. I'm kind of interested in how you work on the security aspects of it (will you give guidance on how to configure your client info for the various APIs (what do I fill in for all of the different URIs in my Facebook app config?), as well as more complicated scenarios (storing tokens in DB, associating tokens to accounts, etc.)

</comment></comment></comment><comment><USER11> The most confusing thing to me about this page was the changing provider names. I was looking at the page and could tell that something was changing but it took me about 15 seconds to figure out what it was.

<comment><USER12> Hah.. I actually read this comment first and I was STILL just staring at my screen completely dumfounded. I'd see the little animation on the right update, and then something else would change. It was mystifying.

<comment><USER13> Made it really hard for me to focus on the content. I know exactly what was changing, and it wasn't that much, but it took a really long time (in comparison) to read the examples.

<comment><AUTHOR> Alright, listening to your feedback it seems the animation was too much of a distraction, so we removed it. Thank you for your feedback!

</comment></comment></comment></comment><comment><USER14> _1\. Setup your Facebook API Keys in OAuth.io_

lost me.

<comment><USER15> That's 1 out of 50+ examples. Facebook is easily the most commonly implemented, so why would they not make that the default example?

</comment></comment><comment><USER16> Shameless plug: We wrote a backend app, Checkpoint, that works similarly to this. It's open source [1] and in use with a number of production apps. Admittedly it does not have the JavaScript stuff, but that's easy enough to add.

Basically, Checkpoint is a facade that abstracts authentication into a simple API. You set up Checkpoint with your OAuth keys (for, say, Facebook), then just redirect your app to /login/facebook. Checkpoint will do the OAuth interaction and return to your app with a key that can be used to access the login session.

Checkpoint abstracts the notion of logins into identities and accounts. An identity corresponds to a user, and can have more than one account associated with it. Identities are logically partitioned by "realm", so it's ready for federated installations.

[1] <https://github.com/bengler/checkpoint>

</comment><comment><USER17> If you'd like something similar to this that's available today, check out our startup: <https://www.dailycred.com/>

We also support email & password (using the same OAuth API) and Mozilla Persona, as well as take care of headaches like password reset, email validation, and account de-duplication (for example, if a user signs in using Facebook on day one and then email on day two).

Best of luck to oauth.io however -- the simple js approach is interesting.

</comment><comment><USER18> +1 for the animated image or gif or whatever, instantly caught my attention. I would maybe speed it up however, I was curiously awaiting to see the full animation.

</comment><comment><USER19> I wish this existed before. For node.js stacks that support connect/express based middleware, we wrote oauth-flow instead

<https://github.com/doxout/node-oauth-flow>

The idea is to point the user to your oauth-flow route and they will complete the oauth flow. your middleware will then be called with req.oauth containing all received oauth credentials and the url containing all the original parameters.

<comment><USER20> There's also <http://everyauth.com/> and <http://passportjs.org/> for node.js

How does yours compare to those?

<comment><USER19> In short - it doesn't assume that you want to use oauth for user authentication and authorization.

Maybe you just want users to add their dropbox or box account to an existing account. Maybe you need to make a one-time call to a service in their name.

Passport and everyauth simply assume too much: that you will need an authentication strategy, that the strategy will have a getter function for the user, that you actually have users...

oauth-flow just implements the authorization flow: redirects the user to the oauth provider (facebook, twitter, etc), then when the user returns, they return at the same URL and the next middleware is called with req.oauth containing all oauth data such as tokens.

Then you can do whatever you want with those - make an API call, authorize the user using their external ID, register a new user...

Its a smaller, more focused module, better aligned with the principle of doing one thing only and doing it well. And it doesn't require adding any global middleware inside the app.configure block such as in passport.

</comment></comment></comment><comment><USER21> I was getting so impatient waiting for the stubborn programmer animation to finish. Inspect -> sources -> stubborn.js -> ohhhhhh... well done.

On the other hand, I first thought this was a Facebook thing since it started with "Setup your Facebook API Keys in OAuth.io". Perhaps something like "Setup API keys for the provider of your choice in OAuth.io"?

</comment><comment><USER22> Comments on the animated UI aside, as someone who recently pulled their hair out trying to get StackOverflow oauth working, a simple solution would be extremely welcome. My scalp shall thank you!

</comment><comment><USER23> I thought the comic programmer would be successful by step 100 or so, so I kept watching.

I am now at step 125. Still watching...

<comment><USER24> You can check out how they did the comic programmer here: <http://oauth.io/js/stubborn.js>

</comment></comment><comment><USER25> Does this service require me to give up my private key for a given API? Seems like a huge security risk to me.

<comment><USER26> It beats putting your private keys in client-side code (JS-only apps being those which this solution seems to be built for).

</comment></comment><comment><USER27> This REALLY could have helped me a week ago. Two oauth consumers later, it's not as easy as it seems.

<comment><USER28> Yes, it really is not. OAuth on mobile is frustrating experience of matching up responses and posts and figuring out which of the 5-10 variables and secrets or keys or tokens to give.

</comment></comment><comment><USER29> The little comic programmer guy is hilarious. And actually, as someone who's fooling around with oauth right now, this looks very appealing.

But yeah, the changing provider names might not be a good idea. Or at least decrease the interval.

<comment><AUTHOR> I decreased the interval to 10s.

</comment></comment><comment><USER30> There is a little too much changing text going on in my opinion. It was difficult to read the sample code because my eyes kept jumping to the changing text all over the screen.

Edit: It looks like you changed the intervals. Much better now.

</comment><comment><USER31> It might be nicer to follow the convention in EventEmitter on Node.JS rather than your own. Put (err, accessToken) instead of (accessToken, err).

</comment><comment><USER32> the little programmer cartoon made me lol! good job!

</comment><comment><USER33> This is cool.

Is this for login alone or do you return API keys (and are the keys for the provider service or for OAuth.io)?

</comment><comment><USER34> Cool!!</comment>


Time-saving technology destroys our productivity - <AUTHOR> http://www.spectator.co.uk/2017/01/how-time-saving-technology-destroys-our-productivity/ <comment><USER2> >In 1929 John Maynard Keynes predicted that by 2029 people in the developed nations could enjoy a perfectly civilised standard of living while working for 16 hours a week.

This is true today if you wanted to live at the same standard of middle class living in 1929, complete with eating only meals hand cooked from base ingredients and no concern with the environmental effects of things like burning coal and garbage.

<comment><USER3> In real dollars, US per capita income has more than quintupled since 1929. [http://www.demographia.com/db-pc1929.pdf](http://www.demographia.com/db- pc1929.pdf) (2016 is higher than 2008, to fill in the missing info).

So even if you want a rising standard of living, work hours could conceivably be shorter.

That said, the fundamental point that most of us wouldn't accept 1929 lifestyles for any amount of leisure is right.

<comment><USER4> Disproportionate growth in housing costs and the impossibility of opting for 1929 healthcare are other factors making it difficult for the average person to afford a 1929 lifestyle on part time work in most developed countries, even if they're happy with cycling and gramophones.

<comment><USER5> It's also often illegal to opt for 1929 building standards. There's minimum lot sizes, minimum apartment sizes, and other zoning standards that almost make me believe they were deliberately designed to raise housing prices.

<comment><USER6> Historically, working- and middle-class people have spent all and almost all of their money respectively on 'just living'. House prices are really high now, but other things have dropped. Whatever the combination of prices, 'just living' will always consume all of the income of the poor... unless something truly unusual happens.

</comment></comment></comment></comment></comment><comment><USER7> I don't agree with the title, even though it's the original from the source.

The author argues that technology has made us more productive, and as a result we spend more of our time doing ancillary tasks (e.g. writing emails, attending meetings) and that since this isn't directly producing value, it's reducing productivity.

I'd argue that as the work has become more complex-- designing software is not as easy as say manufacturing the same widget 200 times each day-- the planning tasks (e.g. writing emails, having meetings) have grown, though perhaps not entirely linearly.

The author also implies that people are spending more time now looking busy and being busy, perhaps over fears that if they completed their job in 16 hours and spent the remaining 24 hours of the work week twiddling their thumbs, they would be fired.

<comment><USER8> I totally agree with your point about looking busy. But that just means there's a management failure somewhere, right?

Shouldn't management recognize such an abnormally productive employee and a) let them go home after their work is done, no matter when that is, or b) give them more work to do (and a corresponding salary increase)?

<comment><USER7> > Shouldn't management recognize such an abnormally productive employee

Using what metric? This is really hard to implement in reality, especially when the average corporate management has no idea what engineers spend their day doing.

> b) give them more work to do

This already happens. See companies looking to hire "heros"

> and a corresponding salary increase

Hah! Yeah, maybe at your company. Mine would work you 80 hours per week for peanuts if they could.

<comment><USER9> Oh, and in an exit interview for a layoff once:

\- He: I never see your car in the parking lot after hours. \- Me: Yeah, I've been done with everything I was given for months now.

Please note - it was a layoff exit interview.

</comment></comment></comment></comment><comment><USER10> Counter-argument: The work described here as "bullshit" \-- administration, bureaucracy, ever-finer metrics of people and products -- actually _DO_ generate "real" value in increasing the speed at which information asymmetries resolve themselves. E.g. people metrics actually make it _harder_ to maintain the cocoons of bullshit the author describes, product metrics make the disparity between what's provided and what's desired more apparent more quickly, etc.

The proliferation of these kinds of work is not necessarily out of "filling space," but because information technology has drastically decreased the marginal costs of this kind of information-only work, and so lowered the barrier of marginal utility required to justify it. So, we have information work where the workers actually carrying it out can't perceive the value, because it's too distributed and too many layers removed from the individual, but it's there. The apparent lack of productivity increase is because those metrics, too, are flawed and do not account for these kinds of value.

Now, the question of whether that work is then _worthwhile_ at a societal level is entirely different.

<comment><USER11> Your argument boils down to 'the productivity metrics are broken'. But since I think we're talking about GDP basically, I doubt you're right.

TFA argues that productivity is squandered by Office Space style ass-covering wastes of time. But I think even good intentioned beaurocratic nonsense can still account for the strong headwind against productivity.

Take a look at the great improvements in supply chain management and JIT manufacturing techniques for true process improvements which result in measurable productivity rise. Kanban works there in ways it simply does not for software, for example.

<comment><USER12> Similarly, "good" overhead like A/B testing can suck up an enormous amount of time without producing anything useful. Badly-executed A/B tests are an easy way to show single-digit "gains" over and over again without ever producing actual movement, and since executing them well is genuinely difficult there are a lot of companies which are running frantically on a treadmill.

There's a lot of business 'motion' that's fundamentally a mismatch between something looking good at an individual level, and achieving nothing on a corporate or national scale.

</comment></comment></comment><comment><USER13> A really good example is Microsoft Outlook.

Features like auto-complete make it a breeze to invite 8 people to a meeting. You can burn up 16 person-hours of time with a few keystrokes (assuming these are actual productive people like developers, whose schedules are impacted by more than the duration of the meeting).

</comment><comment><USER14> > Rory Sutherland is vice-chairman of Ogilvy Group UK

I wonder if the OP observations of "(box-ticking, arse-covering, fatuous self- exculpating emails, the collection of ever more stupid metrics)" occurs more often in the advertising business? I searched for a chart that broke down stupid metrics by industry, but the closest one I could find is this: [http://www.infosecisland.com/uploads/remoteimg/aa043ae12a097...](http://www.infosecisland.com/uploads/remoteimg/aa043ae12a09714b10a9f400d16aba67.jpg)

<comment><USER12> I mean, advertising is a bit infamous for this. Outside of immediate-action advertising ("Want to buy this?" and "Click here"), it's very hard to prove the effects of a given program.

Sales boosters like coupons are already tricky - did they create new buyers, reengage existing buyers, or do customers just hold off on buying until there's a discount? And brand awareness ads are even harder - did your Toyota add two years ago drive a sale today? You can't even survey for that, since in theory it works on people who don't remember it consciously.

So I have a dark suspicion that advertising is more full of stupid metrics than most roles, simply because real analytics are harder to produce.

<comment><USER15> The most important problem with advertising is that it is competive waste:

If firms A and B can create a product a cost $X that sells for $X+$Y firm B can create the same product for $X, then A and B will waste $Y on advertising in an attempt to win consumers for each other, for no benefit to anyone (except in any artistic/entertainment value in the advertising, and the possibly useful wealth-redistribution from firm's owners to advertising employees).

<comment><USER16> I remember reading an article on marginal revolution about how wasteful are charities: The paying customers are scarce and the competition is so fierce that a big sum of the money you donate goes on advertising to gain new donors. In the worst cases most of the money goes into that ...

<comment><USER12> This is definitely a huge problem, especially with socially-competitive charities. Things like breast cancer awareness and helping the local needy around Christmas are so popular that they're locked into ugly advertising struggles. And if people don't do their homework, the most efficient fundraiser will be the charity that spends _no_ money on the cause (or just enough to stay exempt).

This seems like a good time to plug Givewelll. Their entire goal is quantifying the good done by charities and promoting the most efficient. They compare globally, but even if you want to give to something specific like animal welfare or local homelessness, they have some good efficiency tips.

[http://www.givewell.org/](http://www.givewell.org/)

</comment></comment></comment></comment></comment><comment><USER17> The author's theory is completely unsubstantiated. They make a surprising conjecture and instead of proving, asks the audience to disprove it:

"I defy anyone who has worked in an office over the last 25 years to write and say that my theory does not fit the observable facts"

Seems a bit lazy.

<comment><USER18> Well, have you?

<comment><USER19> Not the OP, but... that's not how it works. (a) It is the responsibility of the person making an assertion to back it up. If you disagree, god says you need to give me all your money. (b) The proposed test (compare with 25 years ago) is worse than useless, for the same reason people, as they age, tend to think the Kids These Days are lazier/ruder/dumber/more helpless/whatever than Back In My Day. It is designed to solicit agreement with the writer, not actually demonstrate the validity of anything.

</comment></comment></comment><comment><USER20> The money quote:

«Keynes was partly right, and many people today _are_ working a 16-hour week. By which I mean that they spend 16 hours each week engaged in activities which create some useful form of economic value. The other 20+ hours in the office are spent supporting the monstrous extra informational, bureaucratic and administrative burden made possible by new technology.»

Is the bureaucracy in your company so huge? Are engineers in a startup, where bureaucracy is close to zero, several times as productive as in a large company? Are any commercial companies shrewd enough to kill most of internal bureaucracy and crush the competition? Are there any numbers to support this?

<comment><USER21> This 'lower work week thing' misses the point of social dynamics.

Yes, we could call work '16 hour weeks' and maintain a 1940's standard of living. But to make progress, we need 40 hour weeks.

At least for the time being, we've come to resonate around 40 hours as being 'how long someone should work' \- and so we will work those kinds of hours.

Sure - we could all work less hours, but it would mean another kind of social contract.

You can see this in Europe vs. USA vs. Asian attitudes.

And yes, 'more hours' generally does mean less productivity per hour, but you still get more output.

<comment> rm_-rf_slash If income distribution still worked the way it did in the mid 20th century, most people wouldn't need to work 40 hours a week for the paltry income they receive today.

<comment><USER20> How, in your eyes, the income distribution has changed?

<comment><USER22> Did you seriously just ask a stranger on HN to explain one of the biggest sociopolitical issues of the last 10 years?

Here's an introduction: the GI Bill sent 2 million men to college for free from 1945-1955. In 2017, by contrast, the US has $2 trillion in outstanding student loan debt.

<comment><USER21> That's comparing Apples to Oranges. More like Apples to Cars.

The US spends more as a % of it's GDP and more $/capita than any nation on earth on higher education - and sends a considerably larger share of it's population to college than most other nations, certainly any European nations where college is free.

The % of young people going to college has increased dramatically from 1950 to 2016.

And FYI - if you join the Army today, you can still get your education subsidized :)

'Raw' dollars debt doesn't help us understand the picture that much, moreover, if everyone in America started going advanced degrees, that would also increase student debt, but that would be a good thing, no?

Americans are on the whole much wealthier, and the opportunity that young people have today vis-a-vis 1950 is so much that it's basically unthinkable back in the 1950's.

That said, it's not so good for working class people without jobs, and little job stability.

</comment></comment></comment></comment></comment></comment><comment><USER23> Taking the idea that most "work" done at work is a waste of time, doesn't that suggest there's a big opportunity for an enlightened competitor to eat an established company's lunch? You could do the same amount of productive work for a fraction of the cost . . .

Is this type of thing happening and not widely reported? Is it an under explored opportunity waiting to be tapped? Or is there something else going on that leads the inefficient model to win in the long run?

<comment><USER24> Startups

<comment><USER25> Startup employees do just as much bullshit to make it seem like they're busy. Their main incentive is to keep their job, not make the company successful.

<comment><USER20> Startup employees are partly paid in stock, so they do have incentives to make the company successful. At the very least they want the company to break even before the runway money end, else the payroll will stop rolling.

<comment><USER12> I did some startup (and pseudo-startup) work in college, when I wasn't getting any stock.

From personal experience, it's still motivational to wonder whether your next paycheck is coming out. Not always _pleasant_ , but it was a great incentive to push back against busywork and time-wasting management even if the reception was bad. "We might go bankrupt" really shifts the balance on "how much should I invest in fighting for good decisions?"

</comment></comment></comment></comment></comment><comment><USER26> I could retire today and be very comfortable for the remainder of my days (I am 41) but man would life get boring. Even if I work on projects I haven't had time for and travelled to places I wanted to go there is still something about working day in and day out, with a sense of urgency and with a group of people to make something greater than you could do on your own that leads to a sense of purpose. I also think that if you are spending that much time covering your arse you are working for the wrong company. You should revel in doing quality work not in covering your arse.

<comment><USER27> I wish i was in the same position as you. Sounds like a lack of imagination to me.

</comment></comment><comment><USER28> >... fatuous self-exculpating emails

I think the author is on point, but i sense the article will be a litmus test of reader's perception of what Harvard Business School calls 'bullshit' in modern business.

</comment><comment><USER29> > _Why has IT contributed so little to productivity? To understand this, it > might help to understand that people in any organisation have two > motivations. One is to create genuine economic value; the other is to > generate a protective carapace of bullshit to protect their continued > employment._

TL;DR - If automation could save work, but people are dependant on work to survive then automation will not actually save work. Who'd have known.

</comment><comment><USER30> > Robert Solow's famous observation that 'you can see the computer age > everywhere but in the productivity statistics'.

Does anyone know what this observation is based on? GDP per capita adjusted for inflation has been rising for at least the last hundred years.

<comment><USER31> Productivity growth has not recovered from the last crisis very well, well, basically everywhere

Found a primer (Google link in case paywall) [https://www.google.com/url?sa=t&source=web&rct=j&url=/amp/s/...](https://www.google.com/url?sa=t&source=web&rct=j&url=/amp/s/amp.ft.com/content/a82be370-23f9-11e6-9d4d-c11776a5124d&ved=0ahUKEwjI_u3B6r7RAhVF6oMKHY2tC5kQFggfMAA&usg=AFQjCNHsz2TTVDGkrIxImsEKGK4bfmBR_w&sig2=TBuqf6TtHBL9rqswP23WoQ)</comment></comment>


Nvidia CEO disappointed by Android tablet sales, blames pricing and apps - <AUTHOR> http://www.engadget.com/2011/05/15/nvidia-ceo-disappointed-by-android-tablet-sales-blames-pricing/ <comment><USER2> I suppose it's difficult for him to reflect on the below par quality of the Xoom tablet, at least for the price. But yeah, $800 is sort of set up to fail.

I picked up a Xoom tablet for some work use and though it feels advanced compared to my iPad I found it to be very unreliable. Every so often the thing would completely freak out with random UI events. Sure, it will get better, but until then...</comment>


Ask HN: Are there any advantages to distributed Machine Learning? - <AUTHOR> <comment><USER2> the only advantage is performance, for problems too large to fit on single machines.

</comment><comment><USER3> It's faster.</comment>


Beyonce, Jay-Z move to trademark Blue Ivy - <AUTHOR> http://latimesblogs.latimes.com/gossip/2012/02/blue-ivy-trademark-beyonce-jay-z.html <comment><USER2> Maybe they only intend to trademark it so as to prevent others from using the name and exploiting their child?

<comment><USER3> giving your kid a regular name is probably a way easier solution</comment></comment>


Turn any program that uses stdin/stdout into a WebSocket server - <AUTHOR> https://github.com/joewalnes/websocketd <comment><USER2> 1st thought: Reminds me of inetd Clicked link: This is inetd ;-)

Inetd on wikipedia: [https://en.wikipedia.org/wiki/Inetd](https://en.wikipedia.org/wiki/Inetd)

Inetd on NVD: [https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&...](https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&results_type=statistics&query=inetd&search_type=all) I expected worse ;-)

</comment><comment><USER3> This is a dupe.

For more comments checkout: [https://news.ycombinator.com/item?id=19000109](https://news.ycombinator.com/item?id=19000109)

</comment><comment><USER4> It must be a big whole in security, 'cause it's really too good! :)

<comment><USER5> Exactly my thought. I wont be using this for exposed/public access. Which websockets are.

First vector that comes to mind the stdin escape sequences, then there is the inevitable leaking of sensitive information (besides bugs in the process, what about its unhandled exceptions, segfaults, or other system errors), and then there is the denial-of-service unless it can throttle before invoking a process, and lets not forget about command injection.

But still i must say the idea is nice in simplicity..

<comment><USER6> What stdin escape sequences?

<comment><USER7> terminal-related sequences?

but a websocket/PIPE fails isatty(3), so i don't think any kind of escape sequences are possible, here.</comment></comment></comment></comment>


Show HN: Comicslate – free crowd applicable translation of webcomics - Rainbow-Spike https://comicslate.org/fr/sci-fi/freefall/d0000 <comment> Rainbow-Spike [https://comicslate.org/en/sci- fi/freefall/d0000](https://comicslate.org/en/sci-fi/freefall/d0000) Now prepared original English wordbase

[https://comicslate.org/fr/sci- fi/freefall/d0000](https://comicslate.org/fr/sci-fi/freefall/d0000) French version

Next will be German, Spanish and Esperanto. Fast & clonable</comment>


(Re) Writing Code [2001] - <AUTHOR> http://www.fastcompany.com/magazine/45/faststart.html

<comment><USER2> I thought it was funny in the story where they were talking about the company that had all this code locked in this old legacy language called HPS Seer or whatever, and wanted to upgrade it to something more modern with more programmers available.

And it was _COBOL_.

This article was only written in 2001. If it was written in 1985, maybe, I could see that making sense. And even that would be pushing it.

</comment><comment><USER3> If you can get (or write) a lexer/parser to generate an AST from the code, can't you easily translate it to any other language?

<comment><USER4> The semantics may be very, very different. Let's take an example with two similar languages, Java and C++. You have the AST for a piece of code which creates a struct, zeroes its memory, calls a function pointer, then calls Qt library functions to display a GUI with a few signal/slots to handle user input. How does a program 'easily' translate this into Java?

Now, imagine a similar problem with Haskell, Prolog, Factor or 8-bit assembly...

<comment><USER5> The stuff he's talking about is mainly algorithmic e.g. pricing, the sort of stuff that you could easily write in vanilla code (e.g. no platform specific libraries).</comment></comment></comment>


A REST View of GraphQL - <AUTHOR> https://hasura.io/blog/rest-view-of-graphql <comment><USER2> I'm resistant to GraphQL, although I take the caveat that I was also initially resistant to JSX and CSS-in-JS and my thinking has since evolved.

My two main annoyances are a) GraphQL could be thought of as a custom media type that almost "slots in" to the REST model by defining a request content- type and a response content-type with almost entirely optional fields, and b) the incessant idea that REST has to replicate the n+1 query problem.

For a) "it's strongly typed" has never struck me as much of an argument. It's appealing if you're already lacking a strong definition of your data model, but GraphQL doesn't inherently fix that, it just forces you to confront something you could fix within your existing architecture anyway.

For b), it seems that people tend to map something like /users to `SELECT * FROM users`, and 12 months later, complain that it's retuning too much data, and they have to make N queries to /groups/memberOf.

Am I alone in thinking the obvious solutions are to i) add a comma-separated, dot-notation `?fields=` param to reduce unnecessary data transfer, ii) add an endpoint/content-type switch for `usersWithGroups` and iii) realise this is a problem with your data model, not your API architecture?

As an additional c), my other concern is GraphQL touts "one query language for all your data", but tends to skip over the N+1 problem when _implementing_ the queries to disparate data sources. If your existing queries are bolted into `foreach (input) { do query }` then GraphQl isn't going to give you any speed up, it's just going to give you slightly more simplicity to an already-slow backend.

Granted, I work with "legacy" (i.e. old but functional) code, and I secretly like the idea that adopting GraphQL would force us to fix our query layer, but why can't we fix it within the REST model?

(I happen to be about to sleep, but I am genuinely interested in waking up to see what HN thinks)

<comment><USER3> Many outlets gloss over the n+1 query problem, but I find it to be a _major_ shortcoming of the gql spec. Sure there are solutions, but they are not very ergonomic. In one of our products we found simple requests blowing out to 100s of downstream calls to the legacy REST APIs. The pain in optimizing the GQL resolving layer negated almost any benefit of the framework as a whole.

Im happy GQL brought api-contract-type-saftey to a wider audience, but it is similarly solved with swagger/OpenApi/protobuf/et al.

Folks may be interested in dgraph, which exposes a gql api and is not victim to the n+1 problem since it is actually a graph behind the scenes.

<comment><USER4> > gloss over the n+1 query problem, but I find it to be a major shortcoming of > the gql spec.

Why would an implementation detail like n+1 be part of the spec?

<comment><USER5> The n+1 query problem arises from having an API that doesn't let you express the full query that you want so the server can send you back all the data in one go instead of N+1 goes. The n+1 query problem arises naturally from bad API design. That's a spec problem.

<comment><USER6> Unless I'm missing something in the conversation, this is exactly what GQL is designed to solve.

</comment></comment></comment></comment></comment><comment><USER7> I'm becoming somewhat suspicious of _both_ REST and GraphQL for APIs. Not in the sense of thinking that they're bad or antipatterns or anything so hyperbolic as that, but in that they make some fundamental assumptions about how APIs are going to work that I don't think we should ever just take for granted.

On the REST side, it's the assumption that the API is for state _transfers_. Transfer is a heavy word there. You're not just assuming that the service is stateful, and you're not just assuming that clients can ask for state changes. You're assuming that the dominant model for effectuating those state changes is that the client determines what the new state should look like, and transfers a representation of that state to the server.

And then, on the GraphQL side, you're assuming that the service is basically just a big database. Perhaps one with lots and lots and lots of behavior that, from a high level, looks a lot like triggers. But still, a database.

Both these assumptions may work well for a whole lot of applications. If CRUD's your ticket, then both can serve you well. But choosing either might force you to make some compromises if you were instead hoping to do come up with, for example, a more domain-driven design.

<comment><USER8> What is commonly referred to as "REST" isn't actually REST, and trying to cram that round peg into that square hole is a hobgoblin of little minds IMO. In practice, "REST" can be simplified to RPC over HTTP using JSON as a wire format. Or you can use gRPC and get strong typing _and_ explicit RPC semantics instead.

<comment><USER7> It's not just using JSON as a wire format, it's overloading HTTP verbs and status codes as part of your protocol.

HTTP verbs and status codes map fairly cleanly to CRUD and, more generally, the "state transfer" paradigm. For generic RPC, though? Tends to get quite a bit messier.

<comment><USER8> While that's true in the general case, there's some rules of thumb that get you most of the way there. Use GET for read-only, side-effect-free operations and POST for everything else. Return 2xx for success, 4xx for "client error", and 5xx for "server error". Use Swagger to document payload formats and expected response codes. Getting too much farther beyond that is a slippery slope that leads straight to the REST hobgoblin, who is a mere distraction from the dragons a service owner actually needs to battle.

</comment></comment></comment></comment><comment><USER9> One consideration I rarely see mentioned when discussing REST vs. TechDuJour is:

        who are your users?

If you develop an API for your front-end team, use the fastest, most efficient protocol. Use something that you can change quickly. Optimize for speed in all regards.

If you develop an API for other users and they expect that API to be around for a while and gradually grow, then you need to think about how much pain are you going to subject your users to when your API changes.

GraphQL: You will not get your domain model right on the first attempt. So you will need to change your "Graph". Your "Graph" might change substantially. How do you deal with that?

REST: Same thing: There are well-known standards how to grow and evolve a true RESTful API. Yet, you may still mess with your users, declare a /v2/ endpoint and discontinue /v1/

<comment><USER10> Not a general solution, but with Hasura, one approach we have seen is to use Postgres views to keep the old graph around as your data model changes.

In general API evolution is tricky and perfect decoupling between API clients and servers not possible (the article talks about this). What one can aim for is a combination of:

1) Adding new query parameters should not break clients 2) Adding new fields to the responses should not break clients 3) Adding new serialization formats (for newer clients) should not break existing clients

#1 & #2 is roughly what you get with GraphQL optional fields.

Phil Sturgeon has good articles on API Versioning[1] and Evolvability[2] for REST API's

[1] [https://apisyouwonthate.com/blog/api-versioning-has-no- right...](https://apisyouwonthate.com/blog/api-versioning-has-no-right-way) [2] [https://phil.tech/2018/api-evolution-for-rest-http- apis/](https://phil.tech/2018/api-evolution-for-rest-http-apis/)

<comment><USER9> "perfect decoupling between API clients and servers not possible "

Well, the ultimate REST client: the browser, comes pretty close to that. It doesn't care if you are rendering an app to manage your bank account or a blog or Hacker News.

</comment></comment></comment><comment><USER11> I've used GraphQL and Hasura extensively for my project ([https://pagewatch.dev](https://pagewatch.dev)) and it has been a huge timesaver to get a realtime service up and running. BUT, I'm still using REST for mutations (The POST/PUT part really). At least for my use case I find that almost every time you are modifying data there is some other component also involved (eg starting a background task), so it might as well be a REST server endpoint. (Also I find the mutations language of GraphQL is really the weakest/hardest to really understand part)

<comment><USER12> Mutations don't have the really clear advantages that queries do (compared to their REST counterparts), but the one thing that I think does make them worthwhile is that you get the cache updates/re-renders based on the mutation result (instead of needing to re-fetch data or whatever to get your UI to update).

<comment><USER11> True, but then I'm using the subscriptions model that Hasura provides, so in my case the UI update is actually automatic, its just initiated by Postgres triggers instead of cache (so a bit slower, but still fast enough)

<comment><USER13> How have you found the performance / resource usage of widespread usage of Hasura subscriptions. We're using them in a few key places, but have been reluctant to rely on them too widely because it seems that they are actually based on the polling the query every second.

<comment><USER11> Traffic for my service is too low to say for sure yet, but the hasura docs seems to indicate that it could be quite scalable: [https://github.com/hasura/graphql- engine/blob/master/archite...](https://github.com/hasura/graphql- engine/blob/master/architecture/live-queries.md)

</comment></comment></comment></comment></comment><comment><USER14> Great article.

REST with JSON has always been a category error: JSON is not a hypertext and thus, as the author says, violates the most important and distinct aspect of the REST architecture.

I have written quite a bit about this:

[http://intercoolerjs.org/2016/01/18/rescuing- rest.html](http://intercoolerjs.org/2016/01/18/rescuing-rest.html)

[http://intercoolerjs.org/2016/03/15/hypertext- hypotext.html](http://intercoolerjs.org/2016/03/15/hypertext-hypotext.html)

[https://threadreaderapp.com/thread/1276556432385531906.html](https://threadreaderapp.com/thread/1276556432385531906.html)

</comment><comment><USER15> My main qualm about REST is the number of inputs for doing something: Path variables, query variables, POST input, headers and for shits and giggles the Http METHOD. To top it off, because people want "beautiful" REST APIs everyone has a playground to do these kinds of things differently. And boy are they done very differently from company to company. And that leads to massive opinionated people. Finally, REST is tied to HTTP too tightly. It can't be independent of it, ever. I know a lot of people believe that's a good thing, in that there are metrics, logs, and a variety of data that assists architecturally. But it has only reached that status because we're sitting at 15 years of REST toolchains.

I'm not saying GraphQL is the long term answer, but personally I'd rather be in a project using GraphQL (and hopefully not backed by REST at all)

<comment><USER16> This is partly because REST is not a standard like GraphQL, and you can't really treat them as being equivalent.

If you want a closer comparison, I think it's better to look at standards like OData, JSON:API,or even just for example [Microsoft REST API guidelines]([https://github.com/microsoft/api- guidelines](https://github.com/microsoft/api-guidelines)).

REST by itself is a pretty general description of a type of architecture that isn't even tied to HTTP. Even HN by most definitions is a REST service that primarily uses `text/html` as it's format.

</comment></comment><comment><USER17> We should resist attempts to turn technology choices into religious devotions. Here's an example of a project that brings some of the most significant benefits of GraphQL to an established, mature framework for building REST APIs:

[https://github.com/yezyilomo/django- restql](https://github.com/yezyilomo/django-restql)

It's tempting to think your new paradigm/framework/whatever is so groundbreaking, so purely beneficial, that it warrants asking people to demolish everything and start over. Those kinds of breakthroughs have happened and will continue to happen, but the signal/noise ratio, especially in the world of Web Development, is incredibly low.

<comment><USER10> (Author here) Couldn't agree more on not turning technology choices into religious devotions.

It is of course completely possible for you to build a query language from grounds up. django-restql seems to be doing this. Sparse fieldsets and Netflix Falcor other alternatives I've heard of. GraphQL however has good tooling and if you do see the need for a query language on top of your APIs using it is a good choice IMO.

GraphQL does not necessarily mean you have to throw away your existing backend and rebuild from scratch either. It's perfectly fine to use GraphQL as an additional API endpoint alongside existing APIs. A model we are seeing evolve with Hasura is to use Hasura for all the reads and delegate writes via the Actions framework either to a serverless function or another HTTP service.

<comment><USER17> Thank you for writing a nuanced, non-dogmatic article, and for your thoughtful response here!

I should have clarified that I am not criticizing your article. Rather, I am criticizing some zealotry that has emerged in the community promoting GraphQL as the end-all solution.

I have been - at different times and in no particular order - ambivalent, intrigued, fascinated, and skeptical in regards to GraphQL. I need to learn more and do something hands-on with it, of course.

It seems some of the biggest benefits of GraphQL are 1) accommodating client- side needs that the server-side developers did not anticipate and 2) avoiding over-fetching and under-fetching. Is that fair?

If so, it seems many would be served well by "retrofitting" their REST API with the ability to accept dynamic field requests and respond accordingly, as is done with django-restql.

As for tooling, REST is served well in that area with things like OpenAPI and Postman, although it is not clear (to me) how well they can adapt to non- standard GraphQL-like querying capabilities "tacked on".

</comment></comment></comment><comment><USER18> I have been working on an idea to leverage SQL + REST APIs instead of GraphQL to solve the similar problems, and I would love to get some feedback on it.

GraphQL is great during development, but in production you often use "persisted queries" to prevent abuse. Persisted queries are also a way to use HTTP GET instead of POST, and thereby leverage HTTP caching. As such, if you swap out graphql and use sql during the development phase, you perhaps can get similar benefits.

My solution ([https://github.com/hashedin/squealy](https://github.com/hashedin/squealy)) uses SQL queries to generate the API response. Squealy uses a template language for the sql queries, so you can directly embed where clause from the API parameters. The library internally binds the parameters, and is free from SQL injection.

Handling many-to-many relation, or many one-to-many relations is done in- memory after fetching data from the relational database. This provides the same flexibility as GraphQL, but of course requires you to know SQL.

Here is an example that builds various StackOverflow APIs using just a YAML+SQL based DSL - [https://github.com/hashedin/squealy/blob/master/squealy- app/...](https://github.com/hashedin/squealy/blob/master/squealy-app/squealy- home/dba.se.com.yml)

Squealy is still work in progress, so don't use it in production. But I would love to get some feedback!

<comment><USER10> This looks really cool! Particularly for the embedded analytics use case.

Do you have an example of how this would work on the front end with relationships. For example if I want to fetch posts and their comments how would the front code look like?

<comment><USER18> Yes, following relationships is a key feature of Squealy. Here is an example for a recent-questions API - [https://github.com/hashedin/squealy/blob/master/squealy- app/...](https://github.com/hashedin/squealy/blob/master/squealy-app/squealy- home/dba.se.com.yml).

In short, with 1 GET API call that uses 3 SQL queries, you are getting a list of questions, related answers and related comments.

You should parse that example as follows - 1\. The first SQL query fetches all the questions, filtered by API parameters 2\. The second SQL query fetches all comments for the questions selected in the first query. See the `WHERE c.postid in {{ questions.id | inclause }}` part - questions.id is coming from the output of the first query 3\. The output of the first and second query is merged together on the basis of the questionid that is present in both the query output. 4\. Similar approach is used for all the answers

</comment></comment></comment><comment><USER19> Im right now building my backend on GraphQL and TypeScript.

Great DX.

GraphQL Modules + TypeGraphQL, Apollo Server, TypeORM (pg for prod and sqlite3 for dev/test)

Works pretty nicely auto-generating both graphql fields/querys/mutations/schema and entities/models from database from a single source of turth. I made a template from type-graphql's graphql-modules example to work as a separate codebase, if someone is interested I could switch it from private to public and share the link here

<comment><USER20> Wow, I hadn't seen before how you can mix model and gql code with TypeORM and TypeGraphQL before. Looks really convenient, especially with an auto- generator. Have you ran into footguns?

Did you try postgraphile? Any thoughts?

Curious to see how you string it all together...

<comment><USER19> Hey haven't tried postgraphile, but have tried Prisma/Hasura which seem to be on the same SaaS-GraphQL space. They're all valid products, but my stack is 100% fully open source, and there's no PRO to buy for any of the options.

I based it off the creator of TypeGraphQL GQL-Modules+TypeGraphQL v1 example: [https://github.com/MichalLytek/type- graphql/tree/master/exam...](https://github.com/MichalLytek/type- graphql/tree/master/examples/graphql-modules)

And a LogRocket's blogpost about TypeORM+TypeGraphQL: [https://blog.logrocket.com/how-build-graphql-api- typegraphql...](https://blog.logrocket.com/how-build-graphql-api-typegraphql- typeorm/)

I need to add typeorm/models to my template before sharing, but as an example here's a model which is also a type, using both @ObjectType() & @Field() (type-graphql and @BaseEntity() & @Column() (typeorm)class decorators.

```user.model.ts import { Field, ID, Int, ObjectType, } from 'type-graphql'; import { BaseEntity, Column, Entity, PrimaryGeneratedColumn, } from 'typeorm';

      @Entity()
      @ObjectType()
      export default class User extends BaseEntity {

        @Field(() => ID)
        @PrimaryGeneratedColumn()
        id?: typeof ID;

        @Field()
        @Column()
        name: string;

        @Field()
        @Column()
        email: string;

        @Field(type => Int)
        @Column()
        age: number;

      }

```

and this is what type-graphql auto-generates for a user schema.

```user.schema.ts

# !!! THIS FILE WAS GENERATED BY TYPE-GRAPHQL !!!

# !!! DO NOT MODIFY THIS FILE BY YOURSELF !!!

type Document { author: User! authorId: ID! }

type Notification { author: User! authorId: ID! }

type Query { users: [User!]! }

type User { age: Int! email: String! id: ID! name: String! } ```

<comment><USER20> Nice, thanks!

Fwiw, postgraphile is open source and can be plugged into any express app. But I don't think it provides an orm layer or equivalent, so I can see the advantage of this approach too!

<comment><USER19> Sorry, my bad, I briefly checked their homepage and saw a pro button somewhere: [https://www.graphile.org/postgraphile/pricing/](https://www.graphile.org/postgraphile/pricing/)

Although it's a totally acceptable monetization strategy for any OSS to offer cloud+enterprise support, for my personal projects at least I prefer to choose projects which are more personal/community driven than commercial to put it simply.

But yeah I basically like TypeORM generally also gonna use typeorm-seeding on the mix to stress test the app.

<comment><USER21> _< checks the income from the pro plugin versus that from sponsorship>_ I can definitely confirm that we're significantly more personal/community driven than commercial.

</comment></comment></comment></comment></comment></comment><comment><USER22> Thanks for this article! I'm currently writing my Bachelor thesis, designing a new API for an existing architecture is part of my project. I've been considering going with GraphQL instead of just overhauling the current REST API and this is a pretty good starting point.

</comment><comment><USER23> Use Graphql if you have multiple teams that don't own their back-end, and you have multiple clients (Web, Mobile, SPA, Desktop...) consuming your data, and your front-end always has to consume multiple APIs and resources, and you don't count every milliseconds.

</comment><comment><USER24> I love GraphQL because it is a standard people can agree on, if nothing else.

It is a very long list of decisions your team does not have to make. How to handle mutations and queries, how to represent your domain objects, all of this can be decided through referencing the spec and best practice.

Throw in the fact that it REQUIRES you to define a strict schema that has validation, and I am sold. The tooling is great, you get great documentation out of the box, the architecture is good enough, it is totally win-win in my book.

I feel like with REST you have to reinvent the wheel over and over again, and the lack of standards leaves the burden on the team, who may not be senior level engineers.. ( If I have to write another validation library I am going to flip out. )

</comment><comment><USER25> GraphQL == Modern SOAP

</comment><comment><USER26> Having written [https://glennengstrand.info/software/architecture/microservi...](https://glennengstrand.info/software/architecture/microservice/graphql) which is a blog entitled "GraphQL vs REST" I must admit that I was initially on guard with this blog. In then end, they did compare and contrast GraphQL with REST. I don't wish to go over this article point-by-point but their main arguments against REST seems to me to be this...

1\. too many endpoints

2\. too much data retrieval

3\. too much coupling between clients and servers

The blog does not discuss when to choose REST over GraphQL since that would be in conflict of interest with those who hold Hasura equity.

Technically, GraphQL does decrease the amount of endpoints to one but at the cost of increasing client-side complexity because now client devs have to write what is essentially a query. To do so, they have to understand the backend schema. I would argue that this is not the greatest in terms of clear separation of concerns. I would also argue that this means that there would be even more coupling between client and server.

I won't cover the n+1 point since others here have already done so.

</comment><comment><USER27> GraphQL with Apollo on the front-end provides very nice front-end global state and cache management, but at the cost of increased complexity. For example, fetching data updates the global state so that any page accessing that data is updated automatically.

Are there any lighter weight RESTful JS client state/cache management solutions out there people can recommend?

<comment><USER28> No there's not, and your argument of data updating page automatically is not applicable if you are using react for example you can pass the right data to the right component, and this is the point of Graphql, if you have your data at the root component, you are not getting the point.

</comment></comment><comment><USER29> I think REST works if you need to fetch data but when you want to query data, I prefer a well defined language instead of hacking my http headers into a query language that I need to define, implement and maintain.

</comment><comment><USER30> Check out [https://open-rpc.org/](https://open-rpc.org/) if you haven't seen it. Brings GraphQL-like tooling to JSON-RPC.

</comment><comment><USER31> The primary difference here is that REST is an actual architectural style with constraints.

GraphQL isn't. It's a data query mechanism expressed in JSON.

</comment><comment><USER32> GraphQL makes sense if it is consumed by UI(frontend). But REST still the best for server side consumption. That is one application interacting with another application in the backend. I have seen people interacting with GraphQL for server side as well - but it is over-engineering and increases complexity. IMHO GraphQL is for humans, REST is for machines.

</comment><comment><USER33> I like what AWS built on top od GraphQL.

AppSync + Amplify DataStore is pretty nice tech!</comment>


Poloniex loses around $50,000 in Bitcoin - <AUTHOR> http://arstechnica.com/security/2014/03/yet-another-exchange-hacked-poloniex-loses-around-50000-in-bitcoin/

<comment><USER2> This story was already discussed [https://news.ycombinator.com/item?id=7340908](https://news.ycombinator.com/item?id=7340908)

</comment><comment><AUTHOR> I'm getting a bit of fatigue with these stories.

</comment><comment><USER3> Exchanges are a thing of the past, use a much thinner intermediary-layer such as localbitcoins.com (only mediates, doesn't hold fiat).

<comment><USER4> They hold bitcoin, however, probably tens of thousands of them.</comment></comment>


Twitter: music Page is Live. - <AUTHOR> https://music.twitter.com/ <comment><USER2> sends me back to sign in and on second attempt:

        Whoa there!
        The request token for this page is invalid. It may have already been used, or expired because it is too old. Please go back to the site or application that sent you here and try again; it was probably just a mistake.

</comment><comment><USER3> Signing in for me just redirects me to the sign in page. Limited to certain countries perhaps?

</comment><comment><AUTHOR> Here is a good article that covers the launch.

[http://www.theverge.com/2013/4/12/4215994/twitter-music- site...](http://www.theverge.com/2013/4/12/4215994/twitter-music-site-goes- live)

But, How is music discovery not solved yet? I thought the best machine- learning experts in the world were working on this problem from a long time.

And I feel, twitter can help in music discovering even better with such a service( niche interest graphs)

<comment><USER4> Musical tastes are strongly personal. I might like an artist for entirely different reasons than someone else does so it's often a mistake to assume our tastes correlate. None of the recommendation engines I've tried so far have been nearly as effective as cultivating a network of friends whose tastes I trust.

</comment></comment><comment><USER5> Signing in merely redirects to the home page

<comment><USER6> Ditto. Perhaps this is just a teaser to pique interest for now?

</comment></comment><comment><USER7> What for this app wants to post tweets from my name? Decline.

</comment><comment><USER8> I'm trying to sign in, but every time I push the button, an algorithm sends me two seconds back in time and I am forced to start the process over.

</comment><comment><USER9> Cannot sign in. I wonder if this is country restricted or something. Or probably some bug ..

</comment><comment><USER10> Sign In Sign In Sign In

orrr twitter...

<comment><USER11> I get a 403 error. Maybe certain users only?

</comment></comment><comment><USER12> I can't login there. :(

</comment><comment><USER13> SignInOverflow

</comment><comment><USER14> forever in sign in page

</comment><comment><USER15> yup, can't sign in.

</comment><comment><USER16> hhahha sign in doesn't even work for me and gives no error.

Pretty funny considering it's all their system</comment>


Towards Understanding Linear Word Analogies - <AUTHOR> https://arxiv.org/abs/1810.04882 <comment><AUTHOR> Hi, first author here! Feel free to ask any questions.

TL;DR: We prove that linear word analogies hold over a set of ordered pairs (e.g., {(Paris, France), (Ottawa, Canada), ...}) in an SGNS or GloVe embedding space with no reconstruction error when PMI(x,y) + log p(x,y) is the same for every word pair (x,y). We call this term the csPMI (co-occurrence shifted PMI). This has a number of interesting implications:

1\. It implies that Pennington et al. (authors of GloVe) had the right intuition about why these analogies hold.

2\. Adding two word vectors together to compose them makes sense, because you're implicitly downweighting the more frequent word -- like TF-IDF or SIF would do explicitly.

3\. Using Euclidean distance to measure word dissimilarity make sense because the Euclidean distance is a linear function of the negative csPMI.

<comment><USER2> Based on a first glance, this looks like fabulous work. I've added it to my reading list. Thank you for sharing it!

The first question that comes to mind is whether this property and its implications might hold for deep "contextualized" word embeddings such as ELMo[a], which, as I'm sure you're aware, have proven superior to "shallow" word embeddings like Word2Vec/SGNS and GloVe in a growing range of NLP tasks.

A deep contextualized word embedding model maps words like "leaves" very differently depending on context. For example, the deep contextualized vector for the word "leaves" in the sentence "In the Fall, children love to play in the _leaves_ " will be closer to the vector for "foliage" than to the vector for "leaves" in the sentence "Children don't like it when their father _leaves_ for work," which will be closer to the vector for "departs."

I strongly suspect the csPMI property and its implications would hold for the pair (vector("leaves"), vector("foliage")) in the first case and for the pair (vector("leaves"), vector("departs")) in the second case.

What are your (speculative) thoughts on this?

[a] [https://allennlp.org/elmo](https://allennlp.org/elmo)

<comment><AUTHOR> Interesting question! I think you have the right idea: the GloVe or SGNS vector for a word is some composition of the word sense representations. The number of senses for a word isn't necessarily finite either -- one could argue that each possible context a word could appear in denotes a unique word sense.

I suspect that ELMo (and others) work by mapping a word vector to a word sense vector conditioned on the context, which is much larger than what is used in shallow embeddings like GloVe. If GloVe and SGNS are implicitly factorizing word-context matrices containing a co-occurrence statistic like PMI, then ELMo might be implicitly factorizing a (word sense)-(context sense) matrix containing the same co-occurrence statistic. If this is true, then we'd expect the csPMI property to hold at the word sense-level as well. It'd be much harder to prove though, due to the relative complexity of ELMo compared to GloVe/SGNS.

<comment><USER2> Thank you. Yes, exactly, that's my sense too (pun intended) :-)

Naturally, I'm wondering whether it might be possible somehow to approximate a (pretrained) ELMo (or similar) model with two simpler transformations: first a transformation to the space of word-sense _compositions_ (e.g., via GloVe/SGNS), and then a transformation to a space that somehow encodes probabilities over _word senses_ given the context. Hmmm...

<comment><USER3> There may be merit in tagging each of the words with their part of speech prior to fitting the model in a similar way to sense2vec. Using your example above you would then have 2 vectors, one for leaves|VERB and one for leaves|NOUN

</comment></comment></comment></comment></comment><comment><USER4> This is very cool! When I was a (philosophy) undergrad at UCLA, I took several graduate seminars (most of them in logic), one of which covered Rhetorical Structure Theory and Kehler's Theory of Grammar. In my term paper[1], §3.1, I posit that the "Parallel Relation" (analogies would be closely related, if not even categorically fall under PR) could possibly be modeled by Euclidean distance, such that dist(A, B) ≈ 0 when A and B retain "strong" linguistic coherence.

Anyway, this is really awesome stuff and I'm happy to see more rigorous work done w.r.t. linguistic motifs.

[1] [https://dvt.name/logic/prelation.pdf](https://dvt.name/logic/prelation.pdf)

</comment><comment><USER5> I'm having trouble following the proof of lemma 1, and I can't tell if it's the notation being different from what I'm used to.

Is the expression for gamma prime equal to negative the square of the distance between x and y, that is, -<x-y,x-y>? I'm curious, because I would have expected a stronger property to be necessary for the parallelogram structure.

</comment><comment><USER6> Neat to see this idea play out.

</comment><comment><USER7> Is anyone able to ELI5 this?</comment>