The Moral Character of Cryptographic Work - <AUTHOR> http://web.cs.ucdavis.edu/~rogaway/papers/moral.html <comment><USER2> For anyone here who doesn't know who the author is, Phil Rogaway is one of the most important academic cryptographers; he's responsible for OAEP, PSS, OCB, UMAC, FPE, and the constructions behind XTS, the universal standard for disk encryption.

The meat of the paper is in Sections 2 (where the unintended power dynamics of some modern academic crypto research projects is discussed) and 4 (where he provides suggestions for important practical projects academic cryptographers should tackle). Sections 1 and 3 are written for an audience of academics who might be less familiar with the political implications of crypto than the typical HN reader.

Essentially, Rogaway is trying to convince mathematicians to embrace the practical and political impact of their work.

Colin Percival gets a nice mention towards the end of the paper. I'd be over the moon if I were him. Congrats, Colin!

<comment><USER3> This is a very good paper and it's disappointing that it didn't get higher on HN. That being said I disagree with some of paper's points. I don't believe that cryptographers should take on moral responsibility for how they perceive their work may or may not be used. If a malware writer uses XTS to lock up a hard drive should Dr Rogeway be morally responsible for that since he helped create the constructions for XTS? I would argue "no" because there is a moral separation between idea and implementation. We should not burden cryptographers with moral baggage that should be placed on the people who implement or set policy to implement.

<comment><USER4> There is a clear distinction between a moral responsibility and a legal liability. The moral duties of scientists versus policy makers have little to do with the moral separation between idea and implementation.

</comment></comment></comment><comment><USER5> From the abstract:

 _Cryptography rearranges power: it configures who can do what, from what._

I'd argue that the reverse is really the issue that needs more attention. Online systems that do not provide strong cryptography rearrange power, as compared to their offline equivalents.

It was not feasible to scan all phone calls for keywords in 1970, since that required effort from humans to do the patching and listening. The power dynamic changed when our industry brought those calls into a centralized, trivially-storable clear-text format. Encrypting the conversations is simply a partial return to the status quo of a few decades ago.

<comment><USER6> Good point. And even longer ago, all conversations required meeting, and were private unless an eavesdropper was physically nearby.

Tech has created more extreme possibilities on both sides. On the privacy side, it's possible to exchange messages at a distance in an unreadable and nearly undetectable way. On the surveillance side, it's possible to eavesdrop on nearly everyone (except the very sophisticated).

We can't and (don't want to) go back in time. The real question is "which danger is greater: conspiracy or oppression?"

<comment><USER7> > private unless an eavesdropper was physically nearby.

I completely agree with your post. I have an idea for how to resolve this via networking topology. Right now, TCP/IP seems to me to be an engine for centralizing power: Limited hop count and hierarchical address assignment leads to star topologies, leading to economies of scale that again support centralization.

I propose a network protocol stack that encourages a mesh topology, where it actually makes economic sense to physically link my home to 2 or more of my immediate neighbors. I surmise that all my neighbors (or all the neighbors of the person I'm communicating with) would have to be my adversary in order to spy on my communications (See secret splitting on Wikipedia). I feel that mass surveillance doesn't scale with this topology.

I've been working for some time on designing such a networking protocol stack... What do folks here think? Is this worth my time?

<comment><USER8> I think the typical approach to the bottleneck issue with regard to traffic analysis attacks is that the machines on the edges can act as mixes. They can essentially launder traffic from within their respective meshes so that any intermediary between them can't do attribution. Of course, you have to trust the mix! So what then? Then communication to them has to be encrypted and onion routed, and moreover, continuously sent (even if what is encrypted is the message, "No data here dummy, this is just chaff") and then that has to be sent along, all so the mix doesn't know that you're actually communicating anything.

It's a whole category of research really. Papers like Herd at Sigcomm and Vuvuzela at SOSP are the two latest I've seen and following references there should be helpful. I think if you look at Herd there are a few tricks in there to lower the cost of all of the chaff with the superpeers (or whatever they call them, I read it a while ago). A hybrid system that mixes meshnet schemes for local peer to peer traffic with secret sharing schemes and mixnets for more disparate networks seems workable to me. The question is what benefits does the meshnet provide over the mixnet style schemes?

<comment><USER7> Thanks for the pointers, I'll look them up!

> The question is what benefits does the meshnet provide over the mixnet style > schemes?

My Isochronous grid/mesh protocol is designed to operate at the network layer. The TCP/IP Internet has: * High and Unbounded Latency * Wasteful, Underused Links * Low Redundancy * A Tendency to Centralize Power * Choke-point Surveillance and Censorship * Disaster Vulnerabilities * Tragedy of the Commons

I think a mesh network with non-centralized per-byte pricing can make a big dent in all of these.

A meshnet built on top of a starnet is like trying to build a road network on top of a train network: It's not economically feasible and ultimately pointless.

<comment><USER8> I see. I'm not sure if all of these things are fundamental to TCP itself, but instead are economic and regulatory results. Something to think about. It's not my area so I don't have specific cites, but data centers are effectively meshes. I know there has been work on different ways to transit data within them other than stock TCP/IP. Network coding, for instance, is a pretty cool way to splat data among a whole bunch of interconnected people and UDP to all your peers is a good medium to do it over. There's also work on multipath TCP (MCTCP, others) to help utilize other idle links.

I'd check the literature on that, typically under the data center track at networking conferences.

</comment></comment></comment></comment></comment></comment><comment><USER9> _They lead one to ask if our inability to effectively address mass surveillance constitutes a failure of our field. I believe that it does. I call for a community-wide effort to develop more effective means to resist mass surveillance._

What's funny is that you could talk to any number of law enforcement officials who believe that the moral failing is on the cryptography community for _not_ providing a "backdoor" into encrypted communications. Or to restate, "Please, Apple, think of the children!"

Morality is, unfortunately, subjective. Part of the argument is in convincing your opponent that your morality is superior to theirs. Or, perhaps, that their stance violates their own sense of morality.

<comment><USER10> > Morality is, unfortunately, subjective.

Genuine question: What do people who believe this use as their reason for refraining from harming others for personal gain? I understand that simple intuitive preferences against seeing others suffer will often work, but what do you do about instances where either the rewards of screwing someone over are very great or where your intuition tells you that you would get a lot of pleasure from seeing someone in pain?

I know that I don't really have anything to support my belief that there exists an objective morality which is hard-to-determine.

<comment><USER11> "Act only according to that maxim whereby you can, at the same time, will that it should become a universal law." The Categorical Imperative and its weaker brethren like the Golden Rule are remarkably widespread.

</comment></comment></comment><comment><USER12> > This makes cryptography an inherently political tool.

It always was.

Many developers like to stay out of politics. Concentrating on difficult technical problems is hard enough; adding in politics is therefor adding in unnecessary complexity. As the wonderful Tom Lehrer put it in his song "Wernher Von Braun"[1],

        Don't say that he's hypocritical,
        Say rather that he's apolitical.

        "once the rockets are up, who cares where they come down?
        That's not my department," says Wernher von Braun.

The problem with this is similar to the problem of abstaining from the vote: it's absolutely _not_ a neutral position. Choosing to abstain from politics in general, like those that choose to abstain from the vote, is _de facto_ a vote for the status quo and majority rule.

Not only is cryptography an inherently political tool, almost _all software_ is political.

Software does not exist in a vacuum; the entire point of most software is that it has an impact on business, society, and the world. With the discovery of the General Purpose Computer, this impact can be very large.

It's easy to see why cryptography disrupts existing power structures. It should be similarly easy to see how software _already_ overturned the traditional power structures in places like the stock market, manufacturing, and retail.

So please, consider what impact your software might have when you are writing it, or if someone _already_ has a goal in mind. Maybe, in some cases, it's better to walk away. It;'s a hard question, but the answer is not to say "I'm staying out of politics". To quote Quinn Norton and Eleanor Saitta from their talk[2] at 30c3, there is "no neutral ground in a burning world".

[1] [https://www.youtube.com/watch?v=QEJ9HrZq7Ro#t=16](https://www.youtube.com/watch?v=QEJ9HrZq7Ro#t=16)

[2] [https://www.youtube.com/watch?v=DWg2qEEa9CE](https://www.youtube.com/watch?v=DWg2qEEa9CE)

</comment><comment><USER13> Posted a few days ago at [https://news.ycombinator.com/item?id=10655418](https://news.ycombinator.com/item?id=10655418), but got so little discussion that we won't treat it as a dupe but have instead merged the threads.

<comment><AUTHOR> Huh, thank you. I missed it back then, and assumed that when the submission went through it meant that the dupe detector okayed it.

</comment></comment><comment><USER14> This is an important message to consider, and not just for cryptography. _Everyone_ can benefit from thinking about the moral and social consequences of what problems they choose to work on, who they do them for, and what values the institutions they contract with hold.

</comment><comment><USER15> The biggest thing I took away from this was reading the slides and seeing the FBI's suicide letter to Martin Luther King.

I didn't know about that, and reading that right after seeing the jury dury article on the front page today is chilling to say the least.

</comment><comment><USER7> I completely agree that Cryptography researchers should evaluate their work against their moral values. I feel the same thing about pretty much all engineering... I've been focusing on trying to design moral networking protocols.

</comment><comment><USER16> This was one of the factors (certainly not the only one) that made me move out of the field of cryptography - I was doing work related to attempting to break a major cryptosystem and I realised that I wasn't completely sure what the right course of action was ethically in the slim chance that I succeeded. My background was in pure mathematics and up until I moved into cryptography, it seemed obvious that openess of information was an obvious good. However, once in the crypto field, it became much a much more ambiguous issue.

</comment><comment><USER17> Cyber-security in general is political. This guy is a cryptographer - so it is natural that he formulated this for his own area - but it is too narrow.

Hackers are now routinely the foot soldiers of the cyber-war of everyone against everyone - we need to think more about our own rules instead of following orders.

</comment><comment><USER18> Here we have what I think is a display of an intelligent mind specialized in one area, funded by a state institution, and weak at resolving moral conflicts. Computer scientists (and any self-respecting scientists) HAVE to separate their ethics from the interests of state institutions. Phrases in the paper resembling something like "where the cryptographer has a duty to serve the public and keep their self-interest in check" indicate this. I've read a paper recently on designing systems to have security exceptions for law enforcement and calling them "exception requirements" or something to that effect. This is the sort of thing a good study of ethics can help to resolve.

<comment><USER19>
      Computer scientists (and any self-respecting scientists) HAVE to separate their ethics from the interests of state institutions.

Why? The paper argues exactly to the opposite in the first part, describing the atomic-bomb scientists, and the Russell-Einstein Manifesto.

In my opinion, cryptographers and computer scientists have ignored morally questioning their work for too long. Reality is now catching up on this, with techniques for surveillance. The paper argues this for cryptography, in my view this is even more generally applicable.

<comment><USER18> Why do scientists/cryptographers have to judge ethics for themselves? Not sure what you're asking. Bertrand Russell judged the bomb to be a danger for humanity and chose to express his own views on it.

<comment><USER19> Medical ethics committees have ethicists, but the main advice is from medical experts. I would not want anybody else judging the ethics of medical experiments, as no one else has the expert knowledge. I see absolutely no reason why this should different for computer scientists and cryptographers.

No one else understands the implications of an experiment or a new methodology. I was at a meeting recently discussing ethics committees for computer science. A medical expert gave his opinion and said (paraphrasing): I fail to see the problem with digitalisation, we have had medical records on paper for years, now they are on a computer, what is the difference?

I don't mean to say that every scientist should do this individually. They should discuss this with colleagues, and with an ethics committee, which should contain subject matter experts, but also ethicists.

</comment></comment></comment></comment><comment><USER20> It is the responsibility of the inventor to think ahead as far as possible about how an invention may do good and/or harm.

</comment><comment><USER21> everyone has those talks 30yrs ago when crypto was labeled munition by the usa.

if this article has any content that warrant discussion, is how out of touch with reality the social sciences are.

... and sadly, yet another proof of how necessary Snowden was.

</comment><comment><USER22> OBVIOUSLY CHAOTIC NEUTRAL

</comment><comment><USER23> So I guess we have a moral imperative to fork Chrome to actually enforce cert pinning even against locally-installed roots, then?

<comment><USER24> Enforce cert pinning? No. Notify when it is overridden by locally-installed roots? Yes.</comment></comment>


Show HN: Robin – OpenTable for your office - <AUTHOR> https://robinpowered.com/

<comment><USER2> Others in this thread are saying the pricing is too steep or that this seems silly.

After working for the past 6 months in an office with 4 shared conference rooms and around 20 people, I can say with 100% confidence this pricing would have been approved pretty much instantly.

The conference room shuffle was a headache every single day and caused constant distraction and productivity loss. I know plenty of other people at other companies who have reported the same issues with their conference rooms. Hell, even in the Facebook HQ when I've gone in for meetings has had this problem (though their system is already pretty decent from what I can tell).

If you've felt this pain (regardless of how first world it may seem), I think you'd agree.

Personally I'd rather just never have meetings, but that's not always an option =)

</comment><comment><USER3> Product is not for me (private Google calendar covers 7 people and one room well enough), but just wanted to say that your site and app design is really nice. Well done. One of the cleanest-looking I've seen on here in a long time.

<comment><USER4> Thanks! Our design and product development teams put a lot of time and effort into it. Its important to us.

</comment></comment><comment><USER5> I always have trouble with pricing models like this... how is it 2.5X as expensive to have 3x as many "bookable rooms"? Once you write the software, it's trivial to add more "bookable rooms". Why do you charge so much more for the difference, which really just amounts to a little extra disk space/CPU (not that this is an intensive application to run in either regard anyway).

I guess the reason our industry has gone this way is simply because we know we can get more money from larger companies. That's why you always see these arbitrary limits that correspond in no way whatsoever to the actual cost or value of the product being sold.

<comment><AUTHOR> As much as I love capitalism, there's a few differences as you go up in tiers beyond just room limits. Today the most notable is the ability to manage more than one office location. In time it will will expand since certain things (i.e. SAML, high resolution analytics, audit logs) aren't needed by the typical 5 conference room company. The more stuff you're managing, the more complex the relationships become -- not just an N + 1 operation.

</comment></comment><comment><USER6> This looks like something that would have been on Silicon Valley (TV Show)...

<comment><USER7> It's not a new concept, there are modern offices that use similar systems already. They're great, and just confirms the market for this product.

<comment><USER8> I've seen [https://eventboard.io/](https://eventboard.io/) in the past, which is basically the same exact kind of product. Similar pricing too.

<comment><USER4> Full disclosure: I work for Robin. :)

Eventboard is one of a bunch that do tablet and analytics. They take a different approach on a few things, we build heavily for mobile and employee- facing apps and not just facilities managers.

</comment></comment></comment></comment><comment><USER9> Seems expensive. Can do the same thing with a shared resource in google calendar.

[https://robinpowered.com/blog/how-to-set-up-room-resource- ca...](https://robinpowered.com/blog/how-to-set-up-room-resource-calendars-in- google-apps/)

<comment><USER10> I saw your comment and wondered "how expensive could it really be?" \- the pricing is just too much. I ran it by our IT team (we're a prime candidate for using a product like this) and they shot it down immediately on price. 15 rooms for $3k/year?

<comment><AUTHOR> Couple perspectives you might find interesting (I say this having to learn the lay of the land over the past year myself):

Most offices are designed with 1 conference room per 10-20 employees. If you have 15 conference rooms you probably have well over 100 employees and many millions in payroll. Those people presumably have many meetings, and the cost of not being able to get their job done is measurable.

Conference rooms can be between 200-300 sq feet, so if you have a 15 of them you're looking at several thousand sq ft on your lease. Depending on where you are in the world, that's probably around $10K/month or so in real estate.

The effective rate is about $17/month/room, which in most cases is tiny compared to the cost of mismanaging office space and productive time above.

<comment><USER10> 1 conference room per 20 employees? Really? That ratio is much higher than I've seen at any of the companies I've worked at. 10 seems nearer to the mark.

We have 300 employees in this particular location. We bought an alternative solution for $12k with a licence for up to 75 rooms, for a one-time fee.

</comment></comment></comment></comment><comment><USER11> Pricing seems really steep. The analytics seems cool, but nothing really actionable can be done about popular conference rooms once your office is already built out.

Can someone recommend a good tablet setup for this to maybe bring the price of your total conference room "system" down?

<comment><USER12> I'd hope that the analytics help pinpoint all those cases of people booking a room "just in case" and then not using it.

(In a perfect world, resulting in reduced priority for their requests)

</comment></comment><comment><USER13> Wouldn't it be better to use some sort of proprietary e-ink display for the meeting rooms? Would cut down on the constant tablet charging problem

</comment><comment><USER14> This looks amazing. Hopefully my boss bites because it looks like it will solve a lot of headaches.

</comment><comment><USER15> I spoke with one of the devs at a holiday party (Trevor?) and he mentioned there were a bunch of other things that weren't fleshed out yet that might justify the price here later. But yeah, seems expensive.

</comment><comment><USER16> Looks gorgeous but I wonder how big a deal power is? I suspect many rooms won't have power nearby and recharging every 1-3 days sounds dreary.

<comment><AUTHOR> It's generally not a dealbreaker for most offices. With external battery packs you can get extra days, or you could just get a free standing mount that moves closer to a nearby outlet. Most commercial buildings require power every 8 feet or so on walls, so you're rarely in a power desert.

<comment><USER17> If you can mount near a switch for a light, you can usually get access to unswitched mains right there (1 hot, 1 neutral wire).

</comment></comment></comment><comment><USER18> I think this is a great idea. Congrats guys!

<comment><USER18> Just thinking about it more more, there are so many places you could bolt a tablet onto a wall to improve an interface to something.

\- think doctor / dentist \- think directory to an office building \- a doorbell with video conferencing \- why not just put a menu on every table in every restaurant.

<comment><AUTHOR> If you've been to LaGuardia, it's basically a sea of iPads: [http://www.businessinsider.com/the-ipad-is-a-big-part-of- lag...](http://www.businessinsider.com/the-ipad-is-a-big-part-of-laguardia- airport-2013-2)</comment></comment></comment>


New book on deploying Common Lisp applications - <AUTHOR> https://gumroad.com/l/cl-in-the-wild/launch <comment><USER2> Pls read this before using GumRoad [https://news.ycombinator.com/item?id=13139000](https://news.ycombinator.com/item?id=13139000) and decide. All the best.</comment>


HIV 'made' new deadly Salmonella - study - <AUTHOR> http://www.bbc.co.uk/news/health-19727630

<comment><AUTHOR> In summary a strain of salmonella took advantage of the spread of HIV and the weakened hosts and with that followed the same growth patterns as HIV did from its initial tracking and spread.</comment>


How to brainstorm great business ideas - <AUTHOR> https://www.indiehackers.com/post/how-to-brainstorm-great-business-ideas-ab51c3d51c <comment><USER2> There is an interesting bias going on here. I'm wondering how many people upvoting this text has actually built a business, or just want to believe that what was written here is true?

Building a business is messy. Most ideas suck initially. Companies who got the problem right the first time are extremely rare. Just as rare as companies who succeeded with a crappy idea having great execution.

The hero ingredient is luck. Using all the tricks of the non scientific entrepreneurship self-help literature may grant you better odds at getting lucky, or may not.

You know if the problem/idea/execution was good/real after you have customers paying you. And even after that you don't really know was it execution or idea that won the game, only that they were enough good to succeed.

<comment><USER3> > The hero ingredient is luck.

This... 100% this!

I've mentored and worked with dozens of entrepreneurs and small businesses over the last few years and I mention this to all of them but it's not a case of "if I wait around I'll get lucky". You still need to be active and work hard and fix the right problem with the right solution and then, if you get lucky, you'll succeed.

I teach entrepreneurs to pitch and tell them to go to relevant events. Consistently. They may need to go to 200 events and pitch at them because you have no idea what one of those 200 events will give you the break you are looking for. And then at event 124 someone says "hey, I have that problem, let's talk"...

Now, it's not all about pitching at events but I'm trying to get across the story that you need to consistently do something for a while so that when luck strikes at that particular time you are there.

The chances of getting lucky right out the door are very slim.

Also, I make sure they understand this: Love the problem, not the solution!

<comment><USER4> But how would you define luck, anyway? I think it was Oprah who said something along the lines of "luck is when preparation meets opportunity".

<comment><USER5> I believe we make our own "luck", and I think the above quote is elegant!

WRT finding interesting ideas...

We used to talk about "increasing your surface area of luck" by meeting more people, getting exposed to more ideas/ opportunities etc.

If "Innovation happens at the intersection", then the more you come into contact with, the more your chances of finding an interesting (non-obvious) intersection between problem and solution, or two entirely different solution domains.

WRT executin: Gary player = "The more I practice the luckier I get"

</comment></comment></comment></comment><comment><USER6> Fantastic post. Lots of weight on the problem discovery area which is the right move and engineers turned entrepreneurs skip this step a lot. I know I did.

A book recommended by YC's Aaron Epstein is The Mom Test[0]. The first 50-60% of the book is dedicated to how to discover problems with end clients/users that are worth tackling.

I have used the techniques personally and it's great to see what users say is a huge problem vs a problem they're willing to pay for.

It is easy to get stuck in a self-fulfilling trap that a user complains is a big problem. I recently spoke with a customer:

\- "What's your biggest problem?" (book says this question is a no no)

\- He replies, "If I sell 3 cars at the same time, I'm out of available float (cash) while I wait for those deals to close. This is a HUGE problem for me!"

\- "How do you solve this today?" I ask.

\- "I have other, larger car sales company who will lend me money at XX rates."

Right there, it's a solved problem. The end user figured out their own way. Turns out other smaller dealers like him rely on large trade line companies.

The only way I could complete is either on lower cost of financing or speed. At which point, for me, it's not a problem worth solving. The problem isn't so big for him where he's willing to throw cash at me for it.

Talk to users.

[0] [https://www.amazon.com/Mom-Test-customers-business- everyone-...](https://www.amazon.com/Mom-Test-customers-business-everyone- ebook/dp/B01H4G2J1U)

<comment><USER7> This book is incredibly helpful - I just wish they'd do a follow up book around how you interview users on your product once it exists.

I guess the same principle applies "tell me about a new feature you want for our product... Did you actually try to find a workaround? No" *X probably isn't a feature we should prioritize top then

I'd love to see more examples of ways to get good existing product feedback.

<comment><USER8> I found out about the Kano method about a year ago and have been using it professionally since (when appropriate).

It's a great way of discovering customer attitudes towards product features.

Forgive the plug, but I liked Kano so much that I wrote a free tool to create, conduct and analyze Kano surveys at [https://kanochart.com](https://kanochart.com)

</comment></comment></comment><comment><USER9> I am a serial idea writer and I have to agree with the author.

Ideas are inherently valuable, maybe not financially, but they're valuable to have and valuable to society to share.

It makes me angry that people actually believe ideas are inherently worthless. Or that without any code or implementation they're worthless. It's a meme that needs to die. It's like having your cake and eating it too. Here's a free idea for you to think about and contribute to but it's not enough, you want the outcome without any effort too. So you say my idea is worthless.

Ideas are the precursors of RFCs and ISOs and any thing that humanity has ever accomplished. And ideas are meant to be shared.

People that think ideas are worthless are shutting down conversations about good ideas because of this obsession with the idea that execution is all that matters. And so many ideas die on the grape vine because of this poor attitude.

<comment><USER10> I think the ideas being worthless meme is an over-correction of the person that thinks the idea is all of the value and wants to hire an engineer to 'just do the implementation' for little reward.

Ideas have value, and someone who can unite people with a clear vision can do incredible things but the implementation is a big part of the actual difficulty and usually you have to update the idea as you learn more from the implementation.

In general I suspect the implementation is usually harder than coming up with the idea in most cases and fewer people can do it. (Exceptions might be things like General Relativity and initial Bitcoin paper).

Still, obvious value in trying to come up with things from first principles.

<comment><USER11> Yeah, this is the reason right here. There are thousands of people on internet forums, social media sites and subreddits who want to start projects with themselves as the 'idea man', assuming other people will join and do all the actual implementation work. You see it a lot in game design/development communities, where these people talk about how they'll make the next mega 3D MMORPG where you can go anywhere and do anything, and assume they can just come up with the ideas while their team does all the building work.

The idea might potentially be interesting in itself, but without the implementation it won't be all that useful.

<comment><USER10> Yep - people like this generally set off alarms for me because ideas are cheap and it's easy to sit around "thinking of things" and trick yourself into thinking you're making some sort of progress.

Mainly though it's through the act of attempting implementation and interacting with the world that you learn the most. Someone who refuses to try to do this to get better probably just isn't very capable and their ideas probably aren't very good.

Even if you do come up with an idea that is viable most of the time so have others and it's the successful execution that sets you apart.

I've met people that sit around patting themselves on the back for having the same idea that someone else used to actually build something.

While having the insight is critical, it's a lot smaller part (also usually their idea was a vague generalization of whatever ended up existing).

Kind of reminds me of how the Winklevoss twins were portrayed in the social network, no idea how true to life that is - but that sense of ownership they had when they didn't really do anything of value.

</comment></comment></comment></comment><comment><USER12> I very much agree with this post in that analysis of the problem has to be the first step. There needs to be both a contextual and a granular appreciation of the problem.

You get far too many founders looking for the most intense problem when that is just one facet of a problem. Christmas songs are a problem, painful, intense, etc. But it's only once a year, which would mean not very active users.

As well as the Mom Test, off-the-top of my head, check out

1\. Talking To Humans [https://www.talkingtohumans.com/](https://www.talkingtohumans.com/)

2\. Testing With Humans [https://testingwithhumans.com/](https://testingwithhumans.com/), both by Giff Constable.

There are some medical pain evaluation papers that I found highly informative, but I would need to go through my notes as I can't recollect them.

And if anybody is interested, I have a free tool you can download, that will aid you to assess your idea by breaking it apart into its elemental composition and looking deeper into the problem, the audience, and the market.

It's at MVP v2, so long way to go yet, and it is only for MS Access, so PC only: [https://startizer.com/](https://startizer.com/)

<comment><USER13> Smoothly done! I'm going to try your tool out. And thanks!

<comment><USER12> Hello QuickThrower2. Thank you for your reply. As for downloading it, brilliant, I hope it helps you. If you have any questions, comments, feedback, etc. Please do let me know. Cheers, Ace.

</comment></comment></comment><comment><USER14> It's a nice framework for many ideas I suppose, but there too many examples of "non-obvious" "stupid ideas" with no market or problem to solve that eventually succeed. And plenty of successes that were not innovative but had great execution.

Like most things in life timing is everything and we only know the right timing and "ideas" in hindsight.

<comment><USER15> Can you give some examples of said stupid ideas?

<comment><USER16> Letting strangers sleep in your empty rooms?

I grew up in a high-crime city in the US which shaped my perception of the world, thus AirBnB sounded like madness to me when I first heard of it.

</comment></comment></comment><comment><USER17> I would also add learning to evaluate your idea(s) objectively.

When you think you've thought of a great idea, by definition, you're biased toward it.

If you then start building it, the sunk cost makes you even more resistant to abandoning it.

In my experience, just "building the product" can take a lot longer than you expect. I've spent several months building out what were mostly CRUD apps.

Why? I didn't realize it at the time, but I was working part time, I had to figure out how to do many things for the first time, I had to keep myself motivated, and I had to do development but also design and PM work.

If I was working on something new, I probably would:

1\. think of a problem to work on

2\. talk to a lot of users following the Mom Test (keeping in mind your product has many personas of users) to validate the problem

3\. think of a lot of ideas to solve the problem

4\. somehow identify what idea to prototype first and what the feature set should be

5\. prototype it in Figma, show it to users, improve the prototype until customers are asking "when can I buy this?"

I haven't done this yet. If anyone has any suggestions for getting from set of ideas -> a prototype users want, I would love to hear them!

</comment><comment><USER18> It's a good article I guess, but a bit over-optimistic about execution.

> You can build anything.

Not really, though. The article suggests that there are no constraints to what can be built, but there on constraints to what people want / need, how you'll make money, etc.

There are significant constraints around what can be built. They change over time, and in fact, finding ideas that were rejected for being too hard in the past can be a good indicator of something that could be built now.

And many great business ideas that solve huge problems with clear distribution channels can fail, because the solution that works isn't possible or feasible to build yet.

</comment><comment><USER19> Points 2 and 3 are almost identical for every single business on Indie Hackers.

Subscription model. Internet delivery, with email and social media marketing.

After that, you're back to the square 1 of "now I need an idea". The post had some good points, but for the IH audience I'm not sure it would change much about how they analyse business ideas.

<comment><USER13> An Indie Hacker isn't going to buy a pub, or start a VC fueled startup for that matter. OTOH under the umbrella of internet delivered ideas there is a lot of choice as what to work on! And the internet bit could be trivial with most of the legwork going on in real life, or it could be a pure internet play all online with a rich app.

</comment></comment><comment><USER20> I don't agree with the author. Sometimes good ideas solve problems people didn't know they had.

<comment><USER13> I posit a problem you didn't know you had is a problem the founder knew you had through some wisdom of the crowd or even just luck that their own itch is yours too.

</comment></comment><comment><USER21> In a roundabout kind of way, if you find the solution first, its called learning and if your mindset is aligned to this article, its defined as research.

Though in a monkey see, monkey do world, there is no shortage of mimicked expertise and flattery, so plan accordingly.

</comment><comment><USER22> egghead founder downloaded a bunch of youtube vids and zipped them up and sold them to a mailing list? Weren't there copyright issues? I'm not sure if that sort of advice is sound, but the rest of the article resonated nicely.

<comment><USER23> from what i know of the story he had the creators permission and later they worked together as cofounders

</comment></comment><comment><USER24> Starting small isn't universally applicable advice. It depends on competition and availability of substitutes. It's also an approach that will yield no more than small gains at a time.

</comment><comment><USER25> This is good advice, but I think the fundamental issue for many people is that they are looking for a formula to supplement their own brain.

In reality there are many classes of successful businesses. It's hard to explain the success of a restaurant franchise and of flappy bird in the same formula except to over generalize it as, "decent idea with decent execution and decent timing in front of a decent audience."

I do think posts like this are very helpful at eliminating dead end habits. I know I'm guilty of searching for a lock.

</comment><comment><USER26> From the article : "It's been said that ideas don't matter, execution does. I wholeheartedly disagree. You need both to succeed, but you can only get so good at execution. A great idea gives you much more leverage."

I think it underestimates execution. A great execution makes the dumbest ideas succeed. Reminds me of 'potatoparcel.com'. The business is solely focused on mailing potatoes, which sounds ridiculous, but it found its place.

</comment><comment><USER27> How do we ensure the upvotes on HN ? I posted this 3 days ago

<comment><USER13> You don't ensure upvotes. Just luck. Getting your mates to upvote is against the rules, so best to just see what happens.

</comment></comment><comment><USER28> The big nugget to me from my own experience is pricing. Early or inexperienced business founders charge too little. They charge just enough to make some money but not offend the wallet of the customer. This is all wrong - if your solution provides a real ROI then companies will pay a lot for it. Of your solution costs $1000 to solve a $1000000 problem then you are an idiot and priced too low by an order of magnitude.

</comment><comment><USER29> Good article but execution matters. Execution is like sperm. There are plenty of eggs (i.e., ideas), never a shortage. But unless an egg is properly fertilized it's going no where.

Futhermore, Team A can faulter at the execution of Idea X, but later Team B can pick up Idea X and do it right. For example, the ipod. The idea of an mp3 player wasn't new.

</comment><comment><USER30> > iOS users who need to get tasks done but prefer modern, clean UIs", that's > not an actual group of people. You're just describing the features of a > product you're already biased toward building.

</comment><comment><USER31> I think what all these kinds of articles are forgetting is luck.

It's a lottery.

</comment><comment><USER32> great post</comment>


Nokia denies giving deep packet inspection technology to Iran - <AUTHOR> http://www.nokiasiemensnetworks.com/global/Press/Press+releases/news-archive/Provision+of+Lawful+Intercept+capability+in+Iran.htm

<comment><USER2> There's a deeper point here beyond the Nokia/Iran drama.

We've built an entire cottage industry of "network security tools", many of dubious operational value, that all depend on being able to indiscriminately peek inside of TCP streams. It's easy to justify deployment of wiretap appliances inside of enterprises, who after all own the network connections they're snooping on, and have legitimate reasons to want to inspect what comes in and out.

But note well: when we started designing these tools, the Internet was much less important than it is now. Almost all digital communications happens over IP nowadays. We weren't anticipating a world in which things like Twitter and Facebook would be the key lifelines political movements in repressive countries.

So I have to wonder whether:

* The engineering teams that continue developing wiretap appliances (like SourceFire/Snort, or Arbor's DPI product line) have dedicated real dev cycles to building controls into their products to ensure they aren't abused, the same way "Lawful Intercept" engineers for Motorola and Nokia have to for their products.

* The sales teams for these products have official company guidance on what applications they'll sell their products for; will the EMEA regional sales director for a deep packet company sell wiretap appliances to resellers who aren't contractually prohibited to sell to Iran?

</comment><comment><USER3> There is a lot of hype and falshoods about this on Twiter at the moment. For example someone earlier was warning everyone to remove batteries and sims from cellphones because "residual charge" can be used to track you. And that the authorities could turn on phones remotely and listen to what you say.....

Twitter has been great in getting news out but just as bad at propagating over the top panic myths :(

</comment><comment><USER4> The thing that interested me was that on the BBC the Nokia spokesperson was saying that inspection technology (phones) is asked for by most governments in the world. The spokesperson tried to step around the issue but wanted to make it clear that this technology was nothing special to Iran.

<comment><USER5> Here's the quote from BBC He added: "Western governments, including the UK, don't allow you to build networks without having this functionality." <http://news.bbc.co.uk/2/hi/technology/8112550.stm>

<comment><USER4> Thanks for amending my laziness :-)</comment></comment></comment>


Remote wipe attack not limited to Samsung phones, Android dialer may be to blame - <AUTHOR> http://www.theverge.com/2012/9/26/3412432/samsung-touchwiz-remote-wipe-vulnerability-android-dialer <comment><USER2> The biggest part of this story is that the exploit HAS ALREADY BEEN PATCHED IN JUNE.

Maybe we'll see some backlash against carriers who won't release the patches they said they would.</comment>


Ice cold decks (dealer wins no matter how the deck is cut) - <AUTHOR> http://www.benjoffe.com/holdem <comment><USER3> The computer part is interesting, but it wouldn't actually fly. Take a look at the first heads up hand:

Small blind (opponent) gets dealt Ace-Four, a very strong heads up hand, because ace-high will be good lots of time heads up. Dealer gets Ten-two, which is a very bad hand that makes bottom pair, or a pair with a bad "kicker" (if two hands match, you go to the high card - a 2 can never be high enough to play). Ten-two is junk. Anyway, a good heads-up player will probably raise Ace-four 3-5 times the value of the pot.

Okay, so then the board comes down 989 on the flop. At this point, opponent has ace high on a pair of nines. He's feeling quite good. He probably bets out, maybe half the pot. At this point, any sane player folds the ten-two if they called to begin with.

If you call, and the catch the pair of tens on the turn, the person will probably think you're an idiot. If this happens 2-3 times in a game, and you're winning more than probability suggests, they'll probably nab you for cheating. Which, depending on where you're at, winds up in you getting thrown out of the game politely, thrown out of the game impolitely, or treated... well, really impolitely.

Long story short - interesting computer usage, real life application low-ish even if you wanted to try something like this, which I wouldn't recommend anyways.

<comment><USER4> Yeah, I wouldn't recommend it either, but in the situation you describe couldn't the cheater just raise on the flop? If they get looked up by their opponent, when they catch a lucky Ten on the turn they can just say they were bluffing with air.

I'm not a heads-up player so I'm not sure how often you could get away with such gambits. Also, in this situation the opponent might suspect the cheater holds JT, T9, 98, 87, 76, A9, A8 or any number of other hands that could have hit the flop. Wouldn't a solid heads-up player fold A4 frequently enough in that situation that they never realize they're playing against a stacked deck?

<comment><USER3> Maybe, but I think first action heads up is on the small blind (opponent). He'll be raising that hand. You play most hands heads up, but you toss 10-2 offsuit normally to a raise. After the flop comes down, then I think first action is the dealer. If he bluffs 10-2 there, that's a _complete_ bluff - <USER2> the paired board makes it less likely he hit something, though JT would be an option for someone who calls. If he bets the flop, and the turn, maybe the Ace-Four folds at some point. But if he shows it down (and some people will), it'll look like a completely unnatural sequence of events. You usually don't call significant raises with 10-2 offsuit, and then you're pure bluffing when the flop hits - you have almost no chance of making a hand, except the very small chance you hit a ten and they don't have an overpair or hit an overcard or have a straight themselves.

<comment><USER5> The dealer always has position by definition (we deal to our left and finish with ourselves, and action starts to the left and finishes with us).

The page is actually mistaken in this aspect; it has out opponent labelled as "SB" whereas in fact hero, the dealer, will be SB and out opponent is BB.

</comment></comment></comment></comment><comment><USER6> What follows is a constructed solution for the six-player problem, wherein the small blind always wins.

With six players, the small blind will receive the first and seventh cards of the deck, which I will denote (1,7). The remaining hands will be (2,8), (3,9), (4,10), (5,11), and (6,12). The burn cards are 13, 17, and 19. The board is cards 14, 15, 16, 18, and 20. The first and last board cards are exactly 13 cards after the small blind's two cards, so by simply permuting the 13 possible ranks and then repeating the permutation, one can guarantee the small blind will hit two pair via the first flop card and the river card. What remains is to guarantee that two pair will be the winning hand.

Because cards of the same rank will be exactly 13 spaces apart, no player will be dealt a pocket pair, and the board will never pair. Therefore, larger multiples (trips, quads, boats) will never come up. Furthermore, no other player will hit two pair.

We can eliminate the possibility of a flush (including a straight flush) by guaranteeing that, of the seven cards from 14 and 20, no three are of the same suit. This is simple -- cycle the cards in arbitrary suit order, say, spades - diamonds - clubs - hearts.

Now we simply need to eliminate the possibility of a straight. The permutation A Q T 8 6 4 2 K J 9 7 5 3 does this. Each player gets connected cards like A-2, 5-6, or J-Q, but the board hits the first, third, and fifth cards of a straight (or doesn't put one out at all), meaning one or two players have a gutshot draw but nobody ever hits.

It even appears realistic for a player in the small blind to play this hand regardless of which of the possibilities they're dealt, unless two other players both put out big raises. With a strong hand (say, pairing an ace or king on the flop) they can simply act as though they knew they were in the lead the whole time. With a weak hand (say, 3-4 offsuit) they can act like they were playing position with a Gus Hansen hand, semi-bluffed with bottom pair, and sucked out on the river.

</comment><comment><USER7> Scam School shows you how to pull it off! <http://revision3.com/scamschool/texascheat>

<comment><USER8> I saw it there too. One thing to note though is that you can only play one game at a time since the desk is stacked.

In the video, Brian Brushwood plays two games but there's a cut (no pun intended) in the video in between the two.

</comment></comment><comment><USER9> Didn't see it in the article but it might be nice to see the total number of solutions as n increases. This might be a good application for genetic algorithms to search this large space.

<comment><USER10> I'm interested in this function as well. I'd like to try to analyze his script to see if there is such a bound, or at least some theoretical results to be pulled out of it, but I didn't see the guy's script on the page; has anyone found it?

<comment><AUTHOR> The page <http://www.benjoffe.com/holdem_files/heuristic.html> is running the two-player case. It seems to be using a Javascript hill-climbing algorithm: pick a scoring function which measures how good the solution is, then start from a random deck and try small changes, keeping them only if the score improves.

</comment></comment></comment><comment><USER11> How many such decks can be expected to exist?

Well, there are 52 possble cuts, including "no cut", giving us 52 possible scenarios the dealer must win. Assuming naively that winning one scenario does not affect the odds of winning another scenario, the probability of the dealer winning all scenarios is (1/n)^52, where n is the number of players. There are 51! possible decks (given that the deck is cyclic under cutting and we may hence assume the first card).

Thus a naive expectation for the number of ice cold decks that exist for any n is 51!/n^52. This has the following values:

2 3.44e50

3 2.40e41

4 7.64e34

5 6.98e29

6 5.33e25

7 1.76e22

8 1.69e19

9 3.71e16

...

10 1.55e14

11 1.09e12

12 1.18e10

13 1.84e8

14 3.90e6

15 1.08e5

16 3.77e4

17 1.61e2

18 8.25

19 0.49

20 3.44e-2

21 2.72e-3

22 2.42e-4

So the odds of such a deck existing are very strongly in our favor in all of the non-silly cases. Indeed, it appears likely that we can get almost all of the silly cases, too, especially if that assumption about the scenarios being independent was wrong.

 _Finding_ them, now . . . that might be more work.

</comment><comment><USER12> How does one stack a deck? Having a second deck prepared and somehow exchanging it after shuffling the cards of the original deck?

<comment><USER13> I can't imagine how someone would stack all 52 cards in a deck without passing it to another person. A few years ago I taught myself to stack maybe the top 5 cards and the bottom 5 cards and deal either the top or bottom card very quickly depending on what I wanted someone to have. That was mostly a matter of memorizing which card was which and practicing shuffling enough so that I could move a card to the top and then keep it there.

</comment></comment><comment><USER14> His script is wrong, he didn't burn a card before each of the flop, turn and river.

<comment><USER15> I think you're mistaken, because he said that he did take that into account, and the few random checks I did confirmed it.

For example, starting with the first card in the first example he has

A 10 4 2 K 9 8 9 8 10 8 9

A 4 is one hand, 10 2 is the second, K is burned

989 is the flop, 8 gets burned

10 is the turn, 8 gets burned,

9 is the river.

<comment><USER14> You are completely right. My bad!</comment></comment></comment>


How to Keep Your Siri, Alexa, and Google Assistant Voice Recordings Private - <AUTHOR> https://www.wired.com/story/keep-siri-alexa-google-assistant-recordings-private/ <comment><USER2> It can't be truly private as long as the data is still on their servers.</comment>


Here's How Yahoo CEO Scott Thompson Is Explaining His Bio Scandal - <AUTHOR> http://www.businessinsider.com/exlusive-heres-how-yahoo-ceo-scott-thompson-is-explaining-his-bio-scandal-2012-5

<comment><USER2> So I suppose claiming negligence is better than lying.

A question that should be asked is if Yahoo hired him opposed to another person based off his supposed CS degree. If so, negligence or not, someone else should be chosen as CEO. (and maybe someone can properly vet them before hiring.) If it was negligence he shouldn't get ostracized but he shouldn't keep a job he's not suited for.</comment>


How Shopify Manages API Versioning and Breaking Changes - <AUTHOR> https://engineering.shopify.com/blogs/engineering/shopify-manages-api-versioning-breaking-changes <comment><USER2> It's interesting to compare and contrast this method of API management with Stripe.

As far as I understand, the Stripe api would continue to work indefinitely so long as you lock your api version, whereas Shopify would eventually break the app as they essentially backport breaking changes to older api versions.

Initially, I thought Stripe's method was superior, and would provide the best API experience, but realized that Stripe and Shopify have different incentives w/r/t their api.

For Stripe, breaking a functioning site harms revenue, and generally the developer is the Stripe customer.

For Shopify, their customer is the store owner, and for the most part, the store will continue to function because that is mostly controlled by shopify. The developer api is for added functionality, and it is in the interest of Shopify and the merchant that those apps continue to be updated and utilizing the latest features.

So, two different ways of managing breaking changes, but both are ultimately centered around providing the best customer experience.

<comment><USER3> >those apps continue to be updated and utilizing the latest features.

while this is orthogonal to Shopify API or your post at all, since you mentioned the need of updates, I just wanted to use that opportunity to vent my frustration with the constant push to update everything all the time and judging any piece of software by using "when was the last update" as a metric.

The problem I see is that not all apps or libs need (frequent) updates, many (maybe most) do need them, but some don't. They provide some functionality, they do that well and you could call them "complete". Maybe some security fix could be needed from time to time, but with a mature code being in use for many years event those are not frequent.

For example, consider something like ping utility. It does what it does for many decades. There was a need to add IPv6 support, but that was almost two decades ago. Why would anyone need to update it? I do not want any additional functionality, I don't want it to send emails or have social media share button. I want it to send ICMP echo requests and receive ICMP echo replies and nothing more. Aside from some security fixes no updates should be needed for 10+ years. This utility is done. It should not be thrown upon just because there were no updates for many years.

While of course neither ecommerce or Shopify platform are "done" and they get many updates now and will get updates in future it does not mean that some functionalities could have reached "done" stage.

For a "complete and done" addon, there could be a need for a security fix from time to time. There could be a need for some adjustments if a major browser introduces a new deviation from JS/CSS/HTML standards and forces everyone to update their code. But those events happen from time to time, possibly not that frequently. This means that some addon/plugin would not require any updates during the periods between those events and those periods could be many months/years long. But hey: "this addon did not receive any updates for 13 months, it must be really bad and should be avoided". This leads to a situation where a competing solution with tons of bugs will look better just because it receives two updates a week.

<comment><USER4> Well first of all I think it's a straw man to imply that anyone would want to send emails or share to Facebook out a ping utility. That's sort of a big thing that makes _utilities_ different than _applications_.

Edit: I deleted a couple sentences and realize now this might not convey exactly what I meant. Utilities are easy to call "done," applications are not. Applications interact with external forces who _do_ change constantly (other software, business processes, law and regulation, etc). I think in general, updating applications is a necessary thing, bordering on good, regardless of circumstances.

<comment><USER5> I think the parent is saying that API's should be utilities and not applications.

</comment></comment></comment></comment><comment><USER6> Glad to see that Shopify has better API versioning on their mind. When I used there API a few years ago, it was one of the worst APIs to depend on. To the point, we had to architect our system to alert us for unannounced breaking API changes so we could fix and replay the JSON back.

\- Moving JSON fields in and out of nestings didn't seem to be counted as a breaking change.

\- Changes were rarely announced, and there was never a changelog as to what had changed (they look to have started one starting 2018 [1])

\- When we contacted support about a brake, they would often be surprised.

\- Often the only sign there would be a change would be that new fields would start to show up before a larger change.

All this would happen every few months. Reading this article I can start to see the reasons why this was happening.

[1] [https://developers.shopify.com/changelog?filter=all](https://developers.shopify.com/changelog?filter=all)

<comment><USER7> I maintain a Shopify API package for .NET [0] and this has largely been my experience as well. Their attitude toward breaking API changes has caused me a good deal of frustration in the past. To make matters worse, their docs weren't (and still aren't, in my opinion) that great; my biggest complaint being they typically don't document when values can be null or even have a different type (e.g. property X could be a string or a decimal, but you'll never know looking at their docs).

This has led me to taking the drastic step of making _every_ property nullable. It's gross and feels bad to use, but at least it prevents JSON parse operations from crashing applications when a value is unexpectedly null.

[0]: [https://github.com/nozzlegear/shopifysharp](https://github.com/nozzlegear/shopifysharp)

</comment></comment><comment><USER8> The Shopify developer experience is terrible. No fluffy blog can change that fact.

Shopify says the main product is the store owner. But the developers pick up all of the slack of Shopify.

Recurring payments. App. Store backups. App. Theme backups. App. Order editing. Came late 2019. Checkout. So locked down. Where's the API?! Slate tooling. Abandoned. Starter themes. Abandoned. Storefront SDK. Terrible documentation. More than 1 variant image? App. Metafields. App. Wholesale. App. Mailchimp. Removed.

People talk about google abandoning products. Shopify abandons nearly all developer tooling and is so locked down that it's a constant "app for that" for the basics.

The interesting thing is theres been more than a few store owners I know that use Shopify. They've asked how to move off of Shopify.

I guess fulfilment is more important though. Right?!

<comment><USER9> Shopify's business plan is offer minimum functionality for a low monthly fee and then users use the marketplace to add additional functionality which Shopify takes a 20% cut.

I'm actually working on an open-source fulfillment and operations app for Shopify:

[https://github.com/openshiporg/openship](https://github.com/openshiporg/openship)

I use it to build small apps that interact with the API directly instead of paying and relying on any apps.

<comment><USER8> But Shopify hold the transaction fee and charge 2% on top. So really in the end. Shopify is not that much cheaper. Considering bigcommerce doesnt charge this. I am bullish on the long term of bigcommerce. Or anything that goes after the small medium business.

I don't think Shopify could sustain a real entrance by Adobe with Magento, or a product in the same space from someone like Microsoft. As these companies know developer tooling and in the end. Shopify needs developers. Developers don't need Shopify.

<comment><USER10> _Adobe with Magento_

Eh?? Maybe if they rewrite it from scratch and just recycle the brand...

<comment><USER8> They're already heading towards Shopify's lunch with commerce cloud. That's quite obviously the outcome Adobe is after. It's a subscription business after all.

</comment></comment></comment></comment></comment><comment><USER11> Shopify made a change to their API that was easily measurable on who it would affect, but didn't email us. Refused to grant us a temporary exemption (they would do it for $2000/m they said). The end result? They've sunk my business. I've replaced shopify now by writing my own but it's too late. My customers have all gone to my competitors and we're looking at pivoting.

<comment><USER12> Can you share more details? I run Shopify and that's not something we would do.

<comment><USER11> Hi Tobi,

It was the change on limitations for variants. We woke up one day to product additions failing. Took about a week for the tech team to figure out that we were being throttled because we were exceeding 50k variants. Totally understandable in the bigger picture of things, but I didn't feel we received adequate warning. Developer support had told us that sometimes they grant temporary exemptions but in our case they refused. They advised we upgrade to shopify plus (they quoted us over $2000) to remove the throttling/limitation. Financially it was out of scope for us, so we had to throttle our own customers, which led to a massive disadvantage.

I ended up writing our own cart software, which was always part of the plan, but in the meantime our business suffered.

I don't hold any grudge about it since we were getting incredible value out of the previous arrangement, and I do think Shopify is amazing software. I've been a paying customer in multiple capacities since at least 2008 and recommend it to people all the time. What happened was just unfortunate timing for us.

Thanks for taking a minute to listen, though. Much appreciated.

<comment><USER13> You couldn't pay the 6,000-8,000 for like 3-4 months and keep your business afloat until you rewrote it? Kind of sounds like your business was really really in the red already, or more information is missing?

<comment><USER14> Not everyone is in the "money is no object" startup economy. Outside of tech small businesses are actually small.

<comment><USER13> OP wrote that they have employees. if 6k-8k is too much for a company with employees to literally keep it running, that means it was months away from going completely bust anyway

</comment></comment></comment></comment></comment></comment><comment><USER15> Hi everyone. As the founder of an API company, this article has me wondering about the semantics of versioning — so I thought I'd ask the community a question. I hope the Shopify API team doesn't mind!

When you all think about API versioning, what makes the most sense to you — a semver approach (major.minor.patch) a la NPM, or a date-based approach (2020-01-07) a la AWS? Or is some combination of the two desirable?

At Standard Library [0] we both allow people to publish APIs but also publish API proxies on behalf of partners (Stripe, Slack + others) using a semver approach. It's not perfect but theoretically enforceable (schema parameter additions can be forced to require a minor update, schema parameter removals can be forced to require a major update). We've just stuck to this semver approach based on intuition and haven't had negative feedback about it, but I do like the idea of time-based versioning.

Would love thoughts! If you want to play around you can build your own APIs using [https://code.stdlib.com/](https://code.stdlib.com/), which uses the FunctionScript specification [1] to enforce HTTP request schemas.

[0] [https://stdlib.com/](https://stdlib.com/)

[1] [https://github.com/FunctionScript/FunctionScript](https://github.com/FunctionScript/FunctionScript)

<comment><USER16> Both don't say much without good changelog.

But with semver you can say: ok, I want every new version up to a new minor version (all fixes). While with a date based version you don't know how 'breaking' the changes will be.

<comment><USER15> How often do you feel like you find / consume changelogs when you're looking at APIs? I feel like they're either non-existent or non-obvious for most SaaS companies.

Do you feel like you'd trust a company's API more if you could peruse the API changelog more easily?

<comment><USER16> It's not about trusting a company. It's about wanting to know what will break if you start using a newer version of an API.

And sometimes you also discover new features that can be really useful.

<comment><USER15> That's fair! From my perspective that's something that's building trust with the SaaS provider. We've all heard, "ugh! This API is so shitty!" before — I'm fascinated by what tools and products can be built to prevent developers from feeling these pains.

Thanks for the feedback. Can definitely see that changelogs are really underinvested in across the industry, and it's useful to have people mention how valuable they are.

</comment></comment></comment></comment></comment><comment><USER17> I want to love Shopify but Shopify doesn't want to love developers. For example when their multi-location offering [0] _in beta_ they also announced that the Inventory API is going to breakingly change in 2 months and _none_ of their own SDKs supported locations at that point. This has happened with Shopify time and time again. Shopify doesn't manage API versioning or breaking changes: it just forces developers to update or endure with their broken applications and interfaces.

Sure, it's Shopify's choice. But considering how long their own changes take (for example multi-language is still in some sort of beta and it's been up and coming for like 5 years?) the API cycles are just brutal. And the saddest thing is that Shopify is still the best managed e-commerce platform for most usecases.

[0]: [https://help.shopify.com/en/api/reference/inventory](https://help.shopify.com/en/api/reference/inventory)

<comment><USER18> Where I work, we have found 3rd Party SDKs to be an anti-pattern for this and other reasons.

</comment></comment><comment><USER19> How do they handle security fixes in old releases? If releasing a security patch requires backporting it to 5 different active releases then I'm unconvinced that this is a useful strategy.

<comment><USER20> Great question! As mentioned in the article, when making a change you would typically add an `ApiChange.in_effect?` check to see if your new functionality should execute. When we implement security fixes, we do not include this check and the fix retroactively applies to all API versions.

</comment></comment><comment><USER21> Aside, the article mentions frozen_record and it makes me wish that DataMapper had been a more successful project. I really enjoyed working with it.

</comment><comment><USER22> Just don't make breaking changes. It's really not that hard.

</comment><comment><USER23> Very nice story, this is why I decided to use Shopify API as less as possible, so I won't need to care about the version.

</comment><comment><USER24> shopify is slow it doesnt matter how they manage their api...

</comment><comment><USER24> i know, i know, be constructive... but hey, shopify with +10k products is so slow they can version whatever they want...

<comment><USER9> At that point, I would use something like Gatsby which would build static pages for each of your product pages. You could host that on S3 with a CDN for cheap. You could downgrade the Shopify plan to $9/month since you're not going to be using their storefront.

<comment><USER24> thank you, but this doesnt solve the speed issues in my case. i could use sylius or any other ecom that i could host myself and use custom speedup on code instead of just on cdn:) shop i mean is in uk and has only uk customers, no need for cdn as customers arent spread globally or even on the continent.. as for static wouldnt that work for every solution? in that case theres no need for shopify at all... but as you say i could even keep static code generated and served from redis instead of s/hdd, that would be even faster

<comment><USER9> The main power of Shopify is the dashboard and the APIs. By having a custom storefront, Shopify just provides the APIs and a nice dashboard for non- programmers to use. You can also ditch Shopify later on since the storefront just builds off their API. Just my 2 cents. For $9/month, hosting something like Magento or even Woocommerce would be difficult.</comment></comment></comment></comment>


View Sketch files in the browser - <AUTHOR> https://sketchviewer.com <comment><USER2> Very nice ;)</comment>


Ask HN: How do you provide support to your SaaS application - <AUTHOR> I have a small SaaS app running but I am struggling to support my users vs spend time in building/maintaining app. I am unable to respond to some of my user reported issues quickly and it is hurting the credibility of my application. How do you guys handle this? Do you hire someone for support? <comment><USER2> How many support requests do you get per day and are you getting the same questions again and again? One idea would be to make your support page show an FAQ and include a "contact support via email" link at the bottom. I only get 3 or 4 a day so don't have a problem answering them right away. It can be a distraction when I'm deep in work mode, but I also often learn something important talking to users, so worth it for now.</comment>


Newegg on trial: Mystery company TQP rewrites the history of encryption - <AUTHOR> http://arstechnica.com/tech-policy/2013/11/newegg-on-trial-mystery-company-tqp-re-writes-the-history-of-encryption/2/ <comment><USER2> A guy admits he invents nothing, brazenly sues people before even attempting to sell a license, is challenged by the inventors of the cryptosystems in question, is shown evidence of prior art by the inventor of RC4, and wins the case.

Can it get any more disgusting? I don't want to blame all lawyers, since I may one day need one fighting for me, but this guy is a real douchebag. Sugar coat it all you want "playing the game within the rules of the system". One can play honorably, or one can play dirty, and this guy is a dirt bag.

<comment><USER3> The more I read about patents, the more I think we should have "I thought of that first" rights, whereby people who thought about patenting something before the person who patented it could get their fair share of any licensing revenue derived from the patent. This would protect the small inventors from the big lawyers who dominate the patent scene

I know some might deride that idea as rewarding people who contributed very little, but let's not forget: thinking it up is the _hard_ part. After all someone who doesn't know as much about gaming theory as this guy wouldn't know what to do with a pseudo-random if they had one. And actually making things is mere grunt work, hardly befitting someone as important as an inventor. ~

<comment><USER4> "I thought of that first" in XKCD: [http://xkcd.com/827/](http://xkcd.com/827/)

</comment></comment></comment><comment><USER5> This article was written a week and a half ago, before last week's decision. Here's the latest:

[http://arstechnica.com/tech-policy/2013/11/jury-newegg- infri...](http://arstechnica.com/tech-policy/2013/11/jury-newegg-infringes- spangenberg-patent-must-pay-2-3-million/)

edit: Link to discussion: [https://news.ycombinator.com/item?id=6799381](https://news.ycombinator.com/item?id=6799381)

</comment><comment><USER6> The part below is pretty terrible. So all these big guys with the resources to fight back like Newegg did instead keeled over and paid up...

"Target had a website; Target got sued by TQP. It got out of the case by paying $40,000.

Some paid less than that—but most paid more.

Dodge & Cox, a mutual fund, paid a bit more than $25,000. Pentagon Credit Union paid $65,000. QVC paid $75,000. MLB Advanced Media paid $85,000. PetSmart paid $150,000. PMC paid $400,000. Cigna paid $425,000. Bank of America paid $450,000. First National paid $450,000. Visa paid $500,000. Amazon, Newegg's much larger competitor, paid $500,000. UPS paid $525,000.

IBM paid $750,000. Allianz Insurance paid $950,000. Microsoft paid $1,000,000."

<comment><USER7> To be clear, the payoffs from those companies financed the battle against newegg.

</comment></comment><comment><USER8> We need all to stand behind Newegg here, if we let these people entangle us in their schemes, we will never be free.

Newegg is fighting a good fight here and we need to make this more public.

</comment><comment><USER9> FYI this links to page 2

<comment><USER10> Ain't nobody got time for page 1.

<comment><USER11> Wadsworth constant in print form.</comment></comment></comment>


Google's silent experiment for readers to access publisher's content - <AUTHOR> http://www.niemanlab.org/2011/10/how-google-is-quietly-experimenting-in-new-ways-for-readers-to-access-publishers-content/

<comment><AUTHOR> I guess they start competing with DoubleRecall, the smart YC funded startup[1]. Nice competition!

[1] <http://doublerecall.com/></comment>