Show HN: Scannable Chess Scoresheets - <AUTHOR> https://www.reinechess.com/ <comment><USER2> This is definitely a real problem for some people - a chess organizer friend of mine recently spent 4-5 hours entering games from a scoresheet into the computer every night. This solution is pretty nice - but it is possible to imagine that such a solution might work directly on horribly written scoresheets, using handwriting recognition + the kind of constraints mentioned by indy7500 - that would be pretty amazing from both a technical, and usefulness, standpoint.

<comment><AUTHOR> (I am OP) I thought about doing it that way but found that handwriting recognition was pretty weak as of now and wanted to try something solid. The reason is, usually, handwriting recognition would take into account the following characters (it doesn't recognize individual characters at a time, it looks at a database of handwritten whole words). That would be the ideal if done well, of course.

<comment><USER3> I have no experience with handwriting recognition, but intuitively it seems like the facts that:

a) the grammar for chess move notation is fairly limited; and

b) each move must be valid relative to the current game state

can be used as contextual clues to resolve ambiguous characters. Of course, this means you can't use an off-the-shelf handwriting recognition package that recognizes whole words like you describe, but requires a custom per-character recognizer. (But then, isn't that what you're doing already?)

<comment><AUTHOR> Now that I think about it, you're right. I don't know what the accuracy would be like, but it's certainly possible and worth a try.

</comment></comment></comment></comment><comment><USER4> > _No recording errors: if it 's "Bg4" and you write "Bg5", we can't help :(_

You can help by checking the legality of the current move (which you seem to already do) and also the rest of the game?

<comment><AUTHOR> The way we check legality and adjust is with the character recognition. We use the second highest and third highest confidence characters. So, if you write a 5 and the model recognizes it as a 5 and then a 6 and 7, but really it's a 4, we can't help. This is because we'd add moves exponentially every time we add that many combinations

<comment><USER5> I don't get it. If Bg5 is an illegal move then the recognition is obviously wrong and you can prune it (I would think?).

Who am I to talk though, I'm not the one programming this thing. That's just what my gut tells me. :)

<comment><AUTHOR> Don't say that, you're definitely more experienced than me :) I'll try to clarify, but I could be wrong. This is from the chess.com article on it here: [https://www.chess.com/blog/ReineChess/scannable- scoresheets-...](https://www.chess.com/blog/ReineChess/scannable-scoresheets- free)

The model actually gives us a confidence for each possibility. It might say, N-90%, K-10%, B/R/Q-0% for one of the boxes. Here, we look at how confident our character recognizer is on each character. If the PGN is invalid, then we know some character was recognized incorrectly. We look at the low-confidence characters and change them to the next highest confidence prediction, checking to see which combination of changes delivers a valid PGN. For example, consider the string of moves 1. d4 d2. Black can't play d2 on move 1! But we look at the next most likely predictions, perhaps d8 for white and d5 for black. These are the combinations:

d4 d2

d4 d5

d8 d2

d8 d5

Only the second one is valid, so we choose it and continue ahead.

If you literally wrote "d4 d2," then it's a lot less likely that the correct digit instead of 2 will be in the top 3 predictions.

<comment><USER5> This all makes really good sense. For now I think this is a workable strategy, but I bet you can do better (take that as a challenge ;) ).

Anyways, this is really cool, and smart idea. I'll be printing these out and bringing them to my next tourney. Excited to see how it goes! How do I send you direct feedback?

<comment><AUTHOR> We currently don't store scoresheets when uploaded to our website. Would you be able to send the pictures to us at email@example.com? You could add comments about how it went (or not, since we can just run it and see for ourselves). If you think that might be a hassle I could quickly add a feedback form on the website. Also, I'd encourage that you try it once before the tourney with the restrictions—we haven't tested on very varied handwriting. Oh, and thanks so much for offering feedback!

P.S. Did you have something in mind for improving the postprocessing / trying out different iterations? Or was it just a challenge :D

<comment><USER6> Is there a reason you don't store the images of submitted games? Acquiring real-world training data to test changes with would be very useful. Perhaps make it an opt-in feature people can select when uploading a game so people are "offering" you this information to you rather than you just "taking" it.

One way to choose between two legal candidate moves would be to look forward for the next move by the candidate pieces and see which ones make sense given. If you are trying to choose between e6 and e5, for instance, look forward and see what the next e pawn move is. Plenty of other ways to go about this, of course.

<comment><AUTHOR> No, not a clear reason other than wanted to get the product out earlier. We'll work on an opt-in, that does sound the best.

Wouldn't other pieces affect this though? For example, what if the move was e6 and the next e-pawn move was e7. What if a piece was already there, Ne7 (wrongly recognized)? I thought about slowly running through it like this, but it felt like I kept running into problems which are obvious for us to recognize but I wasn't sure how to implement it computationally

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> This is neat. For anyone wondering why not just record the moves on your phone: Digital devices are not allowed at over-the-board tournament games.

<comment><USER8> As others have pointed out, there are digital scoresheets. But further, digital devices are not banned at OTB tournaments, most players will have a cell phone, and might even text or take calls. It's only in high stakes tournaments that you'll see cell phones banned, but even then it's only for the players. It's still perfectly legal, and extremely common for the game to be video recorded.

<comment><USER9> I am not aware of what you mean by "high stakes tournaments". All official tournaments, even when only amateurs play, actually ban cell phones since about 15 years ago.

[https://www.fide.com/FIDE/handbook/Anti%20Cheating%20Guideli...](https://www.fide.com/FIDE/handbook/Anti%20Cheating%20Guidelines.pdf)

11.3.b. During play, a player is forbidden to have a mobile phone and/or other device capable of processing or transmitting chess analysis in the playing venue. If it is evident that a player brought such a device into the playing venue, he shall lose the game. The opponent shall win. The rules of a competition may specify a different, less severe, penalty.

<comment> munk-a That rule only seems to apply to devices the player controls themselves, so if the tournament had a recording device or if both players jointly sponsored a recording device it doesn't appear it would trigger that rule.

I'd also imagine that this rule's enforcement would be relaxed when, for instance, a player sets up a phone to record the game and has no access to that phone during the game, since any information the phone is recording (and any resulting processing for cheating) would be inaccessible to the user during the game.

</comment></comment></comment></comment><comment><USER10> This is cool. One thing I keep hoping either exists now or will soon is the ability to take a photo of an actual board position and get a FEN string out (or just directly send it to Stockfish and get an evaluation). It'd be really helpful to quickly analyze positions when I'm trying to help my kids out, cos we don't generally keep notation and I'm not always confident that my advice on a position is blunder-free.

<comment><AUTHOR> I think you'll be pleasantly surprised, this is a thing!! I thought about making it but quickly decided computer vision wasn't up to the task yet. It seems I was horribly wrong: [https://github.com/maciejczyzewski/neural- chessboard](https://github.com/maciejczyzewski/neural-chessboard) Haven't tried it myself but it looks amazing

<comment><USER10> Oh man, I had just blithely assumed nobody had done it and never googled, thanks for this!

</comment></comment></comment><comment><USER11> This is great! Sadly it does not seem to be open-source.

I have wanted something like this for other data entry tasks like: tracking expenses or tracking body weight. I enjoy working with pen and paper much more than typing on a Phone or PC. Just give me a template I can print, let me write the data to it, and have it scanned.

Is anyone aware of a product (perferably open-source) that lets me do that?

<comment><AUTHOR> I think I'd be willing to make it open source? I'll talk to a person that worked with me on it.

<comment><USER12> I'm not sure if you posted it anywhere, but would you mind sharing what technology you used for this? I would be very interested in contributing if it became open source.

<comment><AUTHOR> [https://github.com/Messier-16/Reine](https://github.com/Messier-16/Reine)

</comment></comment></comment></comment><comment><USER13> > Do not indicate checks, mates or promotions at all, i.e. leave out the "+," > "#," or "=Q".

Some of your screenshots include the +, is this accurate?

If you don't include the =Q you can't encode all games?

<comment><AUTHOR> I took the screenshot with the "+" before I realized it'd be easier for now to ignore the "+". This is my fault for being lazy, I'll change it. I looked at a database of lichess games (40,000) to convince myself that non-Queen promotions were worth ignoring for the beta. If promoting to a different piece is clearly the better move, I could run a Stockfish check anytime a promotion move is made to assume the player chose the best non-Queen promotion (since otherwise you'd just promote to a Queen in a serious game)

<comment><USER13> Makes sense, congrats on shipping!

I suppose it's unlikely to happen in a game serious/slow enough that people are bothering to record it on paper and upload it, but I've tricked someone into stalemating me by promoting to a queen before. Long term I don't think assuming people made the best move is the right decision.

<comment><AUTHOR> Thanks! Definitely, the check and mate things should also be fixed long term. The nice thing is, I was able to put in tons of constraints to improve processing (for example the last two boxes must be a square like e4) if I ignore checks.

</comment></comment></comment></comment><comment><AUTHOR> We have decided to make it open source! Will publish in another article perhaps, when it has enough comments added in the next two days!

<comment><USER14> That's great! Maybe try to integrate it with a popular library like python- chess ([https://github.com/niklasf/python- chess](https://github.com/niklasf/python-chess))?

<comment><AUTHOR> We did use that for the postprocessing actually, the part where moves are cross-checked for lower probability predictions.

</comment></comment></comment><comment><USER15> Awesome job! If anyone else is working on a project like this or is interested in learning more about applied machine learning we've got a helpful Slack community over at Heartbeat ([https://bit.ly/heartbeatslack](https://bit.ly/heartbeatslack))

<comment><AUTHOR> I just posted this project on #share over on that Slack. Their #help channel helped me a ton (especially Jameson and hart!) Fully endorse this

</comment></comment><comment><USER16> Another way to make them to scan would be that there is one space you can just write free text and then next to them you can fill in the circles to indicate rank moved from, file moved from, rank moved to, file moved to, and promotion (if applicable). You can indicate castling by the king's move.

<comment><AUTHOR> That would be an awful lot of bubbles per move, no?

<comment><USER16> Yes, although there are ways to reduce it (perhaps in a way similar to POSTNET; this would reduce the space taken up but require more fill in at once). But you do not have to fill it in right away you can do so after the game is finish

<comment><AUTHOR> Would you mind quickly explaining what you guys mean? Sorry, I'd love to improve it but I'm not sure I get it. If you had a bunch of bubbles for each square and piece etc. wouldn't you be taking up much more space than 5 boxes? And it's also a huge notation change for everyone

</comment></comment></comment></comment><comment><AUTHOR> P.S. Here's a chess.com article with a video demo (if you don't want to try yourself) and tons of info about the story / how it works. Anyone that has advice on the website design or the software, please help! I'm new.

<comment><USER17> Looks like you forgot your link?

<comment><AUTHOR> [https://www.chess.com/blog/ReineChess/scannable- scoresheets-...](https://www.chess.com/blog/ReineChess/scannable-scoresheets- free)

</comment></comment></comment><comment> V-2 Nice idea, but doesn't the fact that each letter / digit has to be in a separate box (if I understand this right) defeat the purpose?

Normally at tournaments they would hand you a score sheet that doesn't have this crossword-like layout.

<comment><AUTHOR> Hmm... I see why it's a hassle. How does it defeat he purpose though?

<comment><USER8> The USCF rules state that the TD can require players to use a specific scoresheet. It's not generally used in most casual tournaments, but almost mandatory for tournaments that matter.

<comment> V-2 I don't know about the US, but eg. scoresheets with carbon coy were handed out in the last tournament I played (Italy).

</comment></comment></comment></comment><comment><USER18> I'm surprised that handwriting recognition is such a problem for you. Wonder if you can improve accuracy by customizing the training for each user as you grow a larger corpus of examples in each users' hand?

<comment><AUTHOR> Yes, that is the plan. That should heavily increase accuracy. Do you mean handwriting recognition as opposed to character recognition? It wasn't that we tried it and decided it wouldn't work, I just couldn't find previous instances of accurate enough recognition with handwriting. Accuracy was my priority. My sense was also that people would be turned off if they had to still manually input some games, and I had no idea how many manually inputted games it would take to reach good enough accuracy. This was when I hadn't come up with constraining characters and such, but now I can see that (with some attempts at handwriting recognition) that may be possible / is the next step after an app.

It is open sourced now if you or anyone would like to contribute. [https://github.com/Messier-16/Reine/](https://github.com/Messier-16/Reine/)

</comment></comment><comment><AUTHOR> Now open sourced. [https://github.com/Messier-16/Reine/](https://github.com/Messier-16/Reine/)

</comment><comment><USER19> Pretty cool, will definitely save me some time, though I guess I used the time converting it by hand to think through some of the moves.

</comment><comment><USER20> Or you could use ChessNoteR

[https://www.chessnoter.com/](https://www.chessnoter.com/)

</comment><comment><USER21> This is very cool. Analyzing your own games is the single best way to improve your play.

</comment><comment><USER22> are chess players required to write down their moves?

or could the event organizers set up some overhead cameras

or make a smart board

and automate the entire thing that way?

<comment><USER23> The answer is yes to all 3! There are cameras and smart boards at the highest level, but chess players are still required to write down their moves. Archaic for sure, but tradition is strong with these old games.

</comment></comment><comment><USER24> That's really cool. Thanks for sharing.

</comment><comment><USER25> Oooh! Finally!!</comment>


A standard for building APIs in JSON - <AUTHOR> http://jsonapi.org/ <comment><USER4> For people who have been dealing with the churn of JSON API, represented throughout this thread, I'm genuinely sorry.

Let me try to give some perspective on the history. For a long time, JSON API was more of a set of guidelines than a strict specification. A lot of our early adopters hated all of the _MAY_ s in the spec (you can see examples of that throughout this thread), so we decided to tighten things up considerably towards the end of last year.

That meant trying to eliminate the vast majority of options in the primary spec, and moving all optional features to named extensions that clients could programmatically detect.

Of course, significantly tightening up the semantics forced us to grapple with harder problems and pushed some ambiguities into the light of day. RC2 in particular was an attempt to seriously pare down the scope of the main spec, while making the semantics of what was left stricter. Dan (the primary editor) and I spent countless hours discussing various details, and people contributed hundreds and hundreds of (very useful!) comments during this period about various details.

RC3 was a smaller delta, but I could easily imagine that one of the changes had a large impact on existing APIs.

My overall goal for the project from the beginning was to nail down a full protocol (both the format and the wire protocol) that could be implemented by multiple languages on both sides. Originally, it was created because I was frustrated by the ambiguity of "REST-style API" was during the development of Ember Data.

The earliest versions of JSON API didn't really nail things down well enough to deliver on that promise, but I hope that the latest versions will be able to. Time will tell.

<comment><USER5> I appreciate the massive amount of work and the recent updates to tighten the spec.

One challenge with the churn is a lack of any high-level changelog (git commit history doesn't count). I have a team working off an earlier version of the spec, and I check back semi-frequently. But I haven't been able to find a document outlining "here are the major changes since the previous versions." I understand that would represent more work on top of work, but for such a large spec, the changes _have_ been disorienting.

</comment></comment><comment><USER6> In case you're thinking, "Wow, I bet in the real world this would be a misery to impose on a team - I'm sure no one would really want to do this!", well, I worked briefly with a team where they imposed this. It was part of the reason why I say "briefly".

<comment><USER7> I've been starting using it on a personal project and it doesn't seem so bad. What issues did you have? (so I can be forwarned)

<comment><USER6> Well, obviously it's very prescriptive. In theory that should mean it requires less mental effort because it tells you what you should be doing - <USER2> practice, I found it required more effort to do things the precise way it wanted. I was far from alone in this belief.

My main issue was with the "related/linkage" stuff (which may or may not have changed somewhat since I was exposed to it), which is unpleasant, to my eyes, in the way it is expressed, and also verbose and often duplicative in what it produces.

A related problem was the Node.js implementation we were using, which generally felt like more of a hindrance than a help (and which we ended up extending beyond all recognition, making matters dramatically worse - <USER3> that was no fault of JSON API itself directly, other than by association).

Best of luck!

</comment></comment></comment><comment><USER8> We're starting to build API endpoints with this where I work. We didn't have compound documents in an earlier version of our API, and we ended up having to make a lot of roundtrips for some things. So I had been thinking about something like the jsonapi "include" mechanism, and when I saw how jsonapi was doing it, it was pretty close to what I would have done. That made me feel better about going along with their decisions in areas I haven't thought about.

They keep saying that they're closing in on 1.0, but there's a few issues left:

[https://github.com/json-api/json- api/issues?q=is%3Aopen+is%3...](https://github.com/json-api/json- api/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0)

They've been making a lot of changes lately:

[https://github.com/json-api/json- api/graphs/contributors](https://github.com/json-api/json- api/graphs/contributors)

It's good that they want to get all of the breaking changes done so that they can declare a stable 1.0. But it also seems like they're going to try and call it stable right after making a bunch of changes, which seems risky.

I also pitched JSON-LD/Hydra at work, because they're w3c-backed and JSON-LD has some uptake. But the other people who looked at those specs found them hard to digest. And I agree; as an implementer, I can read the jsonapi docs quickly and have a pretty clear idea of what to do. But with JSON-LD/Hydra, not so much.

I get the sense that JSON-LD/Hydra is more flexible than jsonapi, but I think jsonapi does what we need. And if it does what we need, then additional flexibility might actually be a drawback. I guess we'll see how it goes.

<comment><USER4> Thanks for the feedback. Personally, I feel like we nailed down the important changes earlier this month, and I agree that further churn at this point is likely to cause more harm than good.

For what it's worth, the issues you linked to are mostly about adding more rigor to possibly underspecified areas, not changing things that are already specified, but those things could easily be done after 1.0.

</comment></comment><comment><USER9> Oh boy, cue the haters. I'd like to address a few things that JSON API gets right, and where it fails horrendously (just in time for 1.0!)

The good:

\- It opens a path for standardized tooling among API clients. Rather than having a whole mess of JSON-over-HTTP clients with a hard-coded understanding of the particular API, one could theoretically use a hypertext client to interact with any API using this standard.

\- It establishes a baseline of what an API server must implement.

The bad:

\- It tries to control not just the media type, but the protocol (HTTP) and server implementation. This is problematic because it dictates how your server must implement its routes, and is tightly coupled with HTTP.

\- It tries to be very prescriptive, but it cannot cover all edge cases without being exhaustive. This comes at a heavy burden for implementers to get every part of the specification correct. Despite this, some extremely basic features are missing, such as providing an index document so that a client can enter the API knowing only a single entry point (as it stands now, clients must have a priori knowledge of what resources exist on the server).

The ugly:

\- Since so many parts of the base specification are optional MAYs, and there is no prescribed mechanism for feature detection, there is no way to figure out if a server supports a particular feature of this spec without trying to do something and failing.

\- The spec has made many breaking changes on the road to 1.0 (as other commenters have mentioned, and there is still room for breaking changes).

At this point, I think that this project gained traction due to the clout of the original authors (Yehuda Katz and Steve Klabnik) and the promise of no- more-bikeshedding, though I would argue that the bikeshedding has just shifted from particular APIs to the spec. Disclosure: I authored and maintained some libraries that implement this spec, and authored another media type for hypertext APIs.

<comment><USER10> have you been doing REST over something other than HTTP?

<comment><USER9> Now that you bring it up, the JSON API specification does not even mention REST or hypermedia actually. What I was trying to get at is that media types don't have to be coupled to the protocol. One can exchange an HTML document over HTTP just as easily as one could transmit that document over another protocol.

Some media types do consider their applicability over multiple protocols, for example: [http://amundsen.com/blog/archives/1151](http://amundsen.com/blog/archives/1151)

</comment></comment></comment><comment><USER11> I used to rave about how RESTful APIs with JSON were so much better than SOAP and other RPC style interfaces, because the responses were so simple and easy to parse.

This holds true for small projects, but as soon as you are working within a large, complex system that involves multiple teams, the benefits of using standards pays off.

I struggled in the past working on projects with companies that had built dozens of loosely-defined APIs, built with the good design intentions in mind, but suffered later from incomplete or inconsistent implementations. The app codebase became much fatter, in an attempt to abstract away those differences into a consistent mental model.

When complexity and communication reaches a certain threshold, it makes sense to invest in standardizing the APIs and responses. I've seen the payoff and am convinced: client libraries and frontend implementations get much simpler, documentation becomes easier, and discussions about how to make changes or design new APIs all but go away.

On the other hand, for small teams and simple services, using a standard like this is probably overkill, unless everyone involved is used to doing APIs this way.

<comment><USER12> _> but as soon as you are working within a large, complex system that involves multiple teams, the benefits of using standards pays off._

That depends _a lot_ on the nature of the project and the standards involved. In my experience, introducing complexity early on in the hope that it will pay off when the project itself becomes complex, leads to _exactly_ what you would intuitively expect: a huge combinatorial code nightmare where productive work asymptotically approaches zero as time progresses.

There is a failure mode in the development of enterprise projects where actual work is being done only at the fringes where the tight external standards have loopholes allowing for the introduction of actual functionality through the backdoor. The resulting systems are of course extremely brittle.

 _> for small teams and simple services, using a standard like this is probably overkill_

There are also _simple_ standards deserving of the name. Small teams and simple services use them quite adamantly.

The "problem" I see with JSON API is not one of complexity (it really isn't, very), it's specificity. It's designed to cover a good range of common web- centric data interchange problems, but like any higher-order standard it carries the weight of certain abstractions and concepts. The pain comes, in my opinion, not from a project/team size mismatch but in cases where these abstractions are ill-suited for the problem at hand.

One of the key factors why plain JSON has become so popular: it's completely malleable. As a result, the actual JSON data on the wire can closely reflect the internal data structures (or at least a logical representation of them) of producers and consumers. The price for this is a relatively tight coupling, but the pain of it is lessened somewhat by the simplicity of the format.

In the end, the old adage of the structure of the project mirroring the structure of the organization probably holds true. When selecting a standard to work with, people choose one that innately reflects how their company works, and they do it for good reason: to reduce friction.

</comment></comment><comment><USER13> So much fear and loathing in this thread, which puzzles me. Anyone who sets out to write a hypermedia API in JSON is going to end up with a structure not dissimilar to this one. If this fits your needs, then use it, by all means and let your clients use an off-the-shelf lib for using your service.

I'm not a fan of the spec, but overall it seems to strike a good balance between what is specified and what is left out. To compare this to SOAP is missing the point.

What killed SOAP was an insistence on treating HTTP as a dumb transport - thereby breaking the constraints of the interwebs, the inherent brittleness of RPC, and the lunacy of the WS-* stack.

None of that applies here, it's closer in spirit to AtomPub, which is still a pretty decent standard, but just happens to be in XML which everybody hates nowadays.

I think a lot of the commentators in this thread seriously believe that having a different data format and interaction style for every API on the internet is somehow "simpler" than adopting a loosely defined set of conventions and writing them down somewhere as a standard.

<comment><USER14> It seems to me this standard is only really useful for APIs to be consumed by a specific GUI or GUI framework, as opposed to "data-centered" APIs that exist to provide access to a particular dataset for myriad purposes. Having a "links" section makes no sense in the latter case -- that's what docs/Swagger/RAML are for.

My stab at imposing some consistency on data APIs boils down to a header and a data section. The header's utility is in describing the data, most obvious utility comes from including a "count: 235" or paging data.

Less-obvious is having self-describing data, namely including the path and query parameters in the header, so you could ingest the data sans request and still know what it represents.

But it's a little bikesheddy, and that might be that data-only APIs are so freaking simple that no standard is really necessary. If so, I must question writing a standard around how we happen to build GUIs today as it seems doomed to SOAPy failure. But hey I'm not "full-stack" ...

</comment></comment><comment><USER15> One of my clients built their API to the jsonapi standard. Then, the standard changed, and it's no longer compliant. Oops.

<comment><USER7> It's only at RC3 right now. Why would you expect an unstable spec to be static?

<comment><USER10> There was an unversioned spec posted for months that looked usable, then suddenly they announced a complete rewrite as "RC2". Calling it a relase candidate was misleading, though - almost everything got changed again for "RC3".

<comment><USER4> I definitely can see why you'd see RC3 as a complete rewrite, but I don't understand why you'd feel that way about RC3. There were definitely changes, but they were much smaller and motivated by significant feedback by users who opened issues in response to RC2.

For example, RC2 mandated that all fields were dasherized. We made field names opaque in RC3.

At this point, we're pretty much nailing down tiny details and included this language with RC3:

        JSON API is at a third release candidate state. This means
        that it is not yet stable, however, libraries intended to
        work with 1.0 should implement this version of the
        specification. We may make very small tweaks, but
        everything is basically in place.

</comment></comment></comment></comment><comment><USER16> It's a valiant effort but as someone who has dealt with unraveling a strict API built with SOAP I am going to pass. If I want something standardized I will use a schema based solution such as protobuf. It's already a quasi standard, has clients in many languages and is a binary protocol.

We also should not confuse an API with a transport protocol. I will tilt my hat to this not being as verbose as past attempts, but why reinvent the wheel yet again? It's not like prior attempts didn't function as expected - they did - but we in the industry chastised them for being too strict.

Let's work on improving the semantics and documentation around what constitutes an API. Swagger is an excellent example of this.

<comment><USER17> IMO, Protobuf is at same layer as JSON, not JSON API. It's a serialization format.

<comment><USER18> It can describe RPC services as well.

[https://developers.google.com/protocol- buffers/docs/proto#se...](https://developers.google.com/protocol- buffers/docs/proto#services)

</comment></comment></comment><comment><USER19> I was recently exposed to this standard on a green field sinatra project. It quickly became burdensome to maintain all of the linkages. It really deteriorates your ability to keep things DRY on the JSON generation (we were using RABL). Of course, these problems were exacerbated by the fact that there were other issues with how the data was structured and how the client wanted to access resources.

<comment><USER20> Roar[0] works great for this, we use it for our HAL APIs and I'm very happy with it.

[0] [https://github.com/apotonick/roar](https://github.com/apotonick/roar)

</comment></comment><comment><USER21> Yeah...no. Standardizing something like this is useless and only full of edge cases. Keep API's free form and flexible without imposing some sort of restriction. That's how you end up with bigger messes than what you started with. API's are not a mess currently anyway. The point of building a unique application isn't to create uniform systems across the map.

</comment><comment><USER22> How is this any different than the HAL Specification? It seems like an exact copy except the word "includes" replaces "embedded"

<comment><USER4> One of my primary motivations when I started this (a few years ago now) was a straight forward representation of graphs of data (including bits of data without dedicated URLs), rather than trees of data.

Consider the case of a blog. Each blog post has many comments. Each post has an author, and each comment has an author. Some of those entities may have dedicated URLs, and others may not. Additionally, the authors are highly repetitive; you want to refer to them by identifier, not by embedding them.

Because a tree of data can be represented easily as a graph, but not vice versa, JSON API provides a straight-forward way to provide a list of records that are linked to each other. The goal is simple, straight-forward processing regardless of the shape of the graph.

<comment><USER5> On graphs, I was really hoping to see provisions in the spec to support the property graph model, specifically for properties on relationships. We are building APIs that access data in a graph DB, and all the data in the graph has had an obvious representation in the JSON API model except for attributes on edges.

As an example, let's say that my graph DB has People nodes and a MARRIED_TO relationship between two people to indicate they are married. A MARRIED_TO edge could have a "married_on" property containing the date of the marriage.

Where would the "married_on" attribute be represented in JSON API? I could stuff it in the "meta" member of the link object, but that feels loose and hacky. Maybe it could live in the "linkage object" along with the "type" and "id" members. But the linkage object appears to currently be a closed set of only those two members.

Is this requirement to present a full property graph model not as common as I would imagine? I'm a bit behind on my sync with the current state of the spec. This is the first time I've tried to elaborate this need.

</comment></comment></comment><comment><USER23> FYI: JSON-LD is already W3C standardized and may be interesting regarding APIs, especially in the area m2m:

See [http://de.slideshare.net/lanthaler/building-next- generation-...](http://de.slideshare.net/lanthaler/building-next-generation- web-ap-is-with-jsonld-and-hydra)

But my "fear" is that it will all get to complicated, too. Currently I really like to work with JSON Schema ([http://json-schema.org/](http://json- schema.org/)), because it's simple and extensible.

</comment><comment><USER24> Wow. No one needs this. API means application programming interface. It starts and ends its standardization at the application level.

Make your API consistent and write decent documentation for it. That's all _anybody_ needs and will be simpler then trying to conform to some insane metastandard.

</comment><comment><USER25> This reminds me of hypermedia API. Generally speaking, you're provided with an index of resources via xml/json, you then fetch those resources which provide a single or many levels of additional results which are fetch-able. In essence, your api data is almost browse-able. Objective is Idempotent response, fetch as little as possible, provide new functionality via new resources, and resources with discover-ability for auto RPC. [https://github.com/swagger-api/swagger-spec/](https://github.com/swagger- api/swagger-spec/)

<comment><USER26> We do have (optional) hypermedia in the spec itself.

</comment></comment><comment><USER27> Please don't make JSON into JXML.

</comment><comment><USER28> Hydra and json-ld are already available : [http://www.hydra- cg.com](http://www.hydra-cg.com) even if it's a little bit too verbose.

You can have a look of a simple way to do it in php with symfony : [https://github.com/dunglas/DunglasJsonLdApiBundle](https://github.com/dunglas/DunglasJsonLdApiBundle)

</comment><comment><USER29> I had to write an API with lots of one-to-many and many-to-many relationships, with iOS, Android and JS apps accessing the APIs so it needed a mean to sideload data. I found JSONApi to be a good guide to building the API. Of course, I was a bit sad when the spec changed quite radically in its last iteration, but, hey, my API still works, that's not so bad.

</comment><comment><USER30> Does anyone know when we could expect Ember Data to be fully compatible to JSON API? In a stable manner. Our architecture has Sinatra for the backend and Ember.js for the frontend. We're always in a struggle to support JSON API for our third party clients but maintain compatibility with Ember Data.

<comment><USER26> At EmberConf, it was announced that Ember Data 1.0 would ship with JSON API compliance out of the box, in June.

</comment></comment><comment><USER31> By what virtue is this a standard? The very generic name? For HAL, there is at least an internet draft: [https://tools.ietf.org/html/draft-kelly-json- hal-06](https://tools.ietf.org/html/draft-kelly-json-hal-06)

<comment><USER26> The first step in the standardization process is to register with IANA. We've done that. Then, you get a bunch of implementations. Then, you go to the IETF.

</comment></comment><comment><USER32> Any idea if this overlaps even more with RAML? I've seen some projects based around RAML but none so far with JSONApi and I'm trying to understand what advantage there is either way when I don't see JSON being more expressive in this goal.

<comment><USER26> They're fundamentally different. RAML is about describing an existing API. JSON API is a way to build your API in the first place.

</comment></comment><comment><USER33> Here are my personal standard for a JSON api:

1\. The format should pass a basic JSON linter.

2\. (where applicable) The document should represent the logical object type that you'd expect from the endpoint.

Anything beyond this is getting too close to XML for my tastes.

</comment><comment><USER34> As a co-author of JSON API, I'd like to address the value proposition of the specification.

First of all, JSON API provides guidance for a lot of API design decisions that are usually contentious because, although they may _seem_ trivial, they must be made with care in order to be consistent and viable. For instance, JSON API provides guidance for:

* fetching related resources together with primary resources in order to minimize requests

* limiting the fields included in a response document in order to minimize payload size

* paginating data with links that work well with any pagination strategy (page-based, offset-based, and cursor-based)

* sorting results, even potentially based on related resource fields

* representing heterogeneous collections and polymorphic relationships

* representing errors

In my opinion, some of the most useful guidance is related to the representation of relationships, which can include:

* embedded linkage data which "links" primary resources with related resources in a compound document.

* relationship URLs which can retrieve linkage data and directly manipulate the relationship without affecting the underlying resources.

* related resource URLs which can retrieve related resources themselves.

In addition, JSON API supports extensions and has official extensions for performing bulk updates and JSON Patch operations. These particular extensions provide extremely useful mechanisms for transactionally working with multiple resources.

All of this guidance has been forged over the course of two years based on the feedback and contributions of hundreds of developers. Even if you were to incorporate some of this guidance in your APIs piecemeal, it would probably save your team many hours of design discussions.

However, the bigger value proposition of JSON API is just now beginning to be realized. Since we've tightened the "spec" into a proper _spec_ by eliminating many MAYs and SHOULDs, it is now possible to reliably build implementations with a guarantee of compatibility. It's regrettable that it took us so long to move from providing loose guidelines to a more rigid spec, but I truly believe that the awkward intermediate phase provided invaluable feedback that ultimately informed the design of the spec and will improve adoption of 1.0.

We are seeing client libraries being built in JavaScript, iOS, and Ruby, and server libraries in PHP, Node.js, Ruby, Python, Go, and .NET. Although not all are (yet) compliant with the latest changes to the spec, we are tracking progress carefully as the spec nears 1.0 to ensure that we smooth over any rough spots encountered by implementors. I'm personally involved in developing Orbit.js and JSONAPI::Resources, both of which are nearing JSON API compliance.

I can say that it's incredibly satisfying to build applications with compatible client and server libraries. It lets me focus on the design of my application's domain instead of myriad details related to transforming data representations and protocol usage. Even better is the knowledge that other clients can easily use my API and all of its advanced features, regardless of their language and framework. This is ultimately the promise of JSON API, and it won't be long before it's realized.

<comment><USER35> Five years ago, much of my team's time was being consumed fighting with the WSDL and SOAP specs, and their various subtly incompatible or outright broken implementations on our target platforms.

A switch to JSON-RPC 2.0 meant everyone now understood the entirety of the specifications our APIs relied on, and if we couldn't find a good implementation for our target, we could either fix one, or write one ourselves in just a few hours.

The productivity gain was effectively infinite.

I look at the JSON API specification in all its architecture astronaut glory, and weep.

</comment></comment><comment><USER36> I love that the logo is invalid JSON. (see: [http://www.json.org/](http://www.json.org/))

</comment><comment><USER37> ugh..please no.

</comment><comment><USER38> When you're working in a small/medium sized team, everyone seems to have an opinion about format of an API. I'm thankful that a resource like this exists because it's easy to read and seems very well thought out.

</comment><comment><USER39> Treating integer values as strings, really rubs me up the wrong way. They might as well wrap boolean and null values in quotes too!

Its hard to take the API seriously when they f __k up some of the best parts of the json spec.

<comment><USER26> IDs are defined as strings, not integer values. These examples happen to use ones that have integers in them, but you can use things like UUIDs easily as well.

</comment></comment><comment><USER40> > first-name

No, thanks.

<comment><USER41> Also 'linkage'. And 'data' the name you give things when you're not naming them.

</comment></comment><comment><USER42> Seems to be treading a lot of the same ground as OData.

</comment><comment><USER43> [https://xkcd.com/927/](https://xkcd.com/927/)

<comment><USER44> Let's see... JSON-RPC, JSON API, HAL, Swagger, OData, Jsend, Google's JSON style guide, more?

<comment><USER45> You might want to add [http://loopback.io/](http://loopback.io/) which is a node.js module to implement JSON APIs. It has its own way to do it so we could say it's a standard from the industry. Maybe it's too early to call is "standard" but it's getting traction. They're sending people around to give talks and 1 hour training events. I'm coordinating a team of developers using it. So far it's OK.

</comment></comment></comment><comment><USER46> Standard? Who proposed? Who accepted? Any names, documents? Standard is a serious word.

<comment><USER26> Currently: registered media type with IANA. Eventually we'll pursue an IETF RFC.

<comment><USER46> But where are discussions? Can't find any link to discussions with developers on your site.

<comment><USER26> Currently, discussion happens on the GitHub repo, though we've thought about putting up a Discourse [https://github.com/json-api/json- api/issues/295](https://github.com/json-api/json-api/issues/295)

</comment></comment></comment></comment><comment><USER47> From the example on the first page, it just looks like what is needed is a JavaScript object graph tool like JSOG [1], which will allow a large cyclic object graph to be serialized and deserialized to / from json.

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

</comment><comment><USER48> Looks like XML implemented as JSON. If you want that much structure, use XML.

</comment><comment><USER49> What about RAML ? You can hook it up to json schema validation

</comment><comment><USER50> When this is done, they will have re-invented SOAP.

<comment><USER4> I hope not!

<comment><USER51> You are mostly there. Granted even your json is nicer than soap, but it is very, very far from json.

About the only thing useful in the spec is a separate errors list so that I can easily check if it worked as it should.

Also there is apparently no way to authenticate so you either have to allow everybody to create/alter whatever on your server or nobody. Yikes.

<comment><USER52> jsonapi bears absolutely no resemblance to SOAP. I do not understand this comment at all.

<comment><USER50> Our cool new thing is _not_ like that old obsolete thing everybody hates. Not! Not! Not!

<comment><USER53> Please keep HN comments substantive.

</comment></comment></comment></comment></comment></comment><comment><USER54> Does it support streaming?

</comment><comment><USER55> What!? No JSON-LD?

</comment><comment><USER56> Does anyone else find it funny that it's a .org domain?

</comment><comment><USER51> Oh great. We killed xml because the astro-architects had turned it into a bunch of crap and now they are doing the same thing to json.

If I get my way, whatever I work on will be tailored to break if the client assumes this "standard".

<comment><USER57> While I wouldn't have anything break itself to make a point I'd much rather have documentation than a standard API format. Lets form a new JSON API standard

The result MUST be in JSON format.

Documentation of the API MUST exist.

Errors SHOULD change the HTTP code as appropriate

That is all.

</comment></comment><comment><USER58> I would say there is no need for this.

JSON/REST are beloved because it's simple and just works. Originally XML itself was simple too with just DTD as "Schema".

BUT then all the additional standards like XMLSchema, XSLT, XML-RPC/SOAP turned it in an ugly duck.

      JSON API is extracted from the JSON transport implicitly
      defined by Ember Data's REST adapter.
      http://jsonapi.org/about/

As JSON-API comes from the Ember.js camp, I remember the Ember vs. Angular discussions on HN 1-2 years ago. Google Trends shows Ember.js has gone nowhere. [https://www.google.com/trends/explore#q=AngularJS%2C%20Ember...](https://www.google.com/trends/explore#q=AngularJS%2C%20Ember.js&cmpt=q&tz=) (and now there is also React). So I guess the "Ember.js way" to do things failed. At some point we should learn from history, and not turn JSON into SOAP/WSDL - [https://xkcd.com/927/](https://xkcd.com/927/) .

XML-RPC/SOAP and/or many other remote procedure call transport techniques failed in in the long term and are a big pile of legacy mess (CORBA, DCOM, RMI, SAP RFC, .NET Remoting, XML-RPC, etc.): [http://en.wikipedia.org/wiki/Remote_procedure_call](http://en.wikipedia.org/wiki/Remote_procedure_call)

<comment><USER34> > JSON/REST are beloved because it's simple and just works.

There is no consensus on the details of "REST". Every implementation has its subtle quirks and solutions to the same basic problems. Every client library must be customized to adapt to these differences. Since the fundamental aspects aren't agreed upon, there is little chance of defining compatible features at a higher level.

On the other hand, the value proposition for JSON API is rooted in consensus [1]

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

> As JSON-API comes from the Ember.js camp

JSON API has been proven in many languages and frameworks. The JSON API team is diverse and has only one member on the Ember core team (@wycats). More importantly, JSON API has been influenced by hundreds of contributors with diverse backgrounds and specialties.

At this point, JSON API is pretty far from its original extraction from Ember Data. It has come full circle to the point that a JSON API Adapter is being written from scratch for Ember Data (and is now almost fully compatible).

<comment><USER59> I guess I'm confused then. If I wanted a complicated standard but one with broad consensus and lots of library support behind it, why wouldn't I just use XML-RPC? Other than not being XML, what does JSON API offer? Because at first glance, it looks just about as verbose and unfriendly as XML-RPC to me.

<comment><USER60> Json-rpc it's what you get anyway most of the time since very few have a clue of what rest is. Not that is a bad design by itself, many of them are concise and workable without being rest.

What I am concerned mostly is the added overhead of fitting everything under a single standard. Sometime you need state aware api, sometime you need data retrieval api, sometime you need to expose a remote interface to constraint manipulating objects with server side rules.

Why it all has to be a standard escapes me. You mostly get absurdly convoluted operation when you try to fit one model under another.

</comment></comment></comment></comment><comment><USER61> What the hell is a PATCH request? This is not part of HTTP, as far as I can recall. Why not use PUT instead?

<comment><USER26> [http://tools.ietf.org/html/rfc5789](http://tools.ietf.org/html/rfc5789)

</comment></comment><comment><USER62> I don't get why so much negativity towards this. I have recently used this in a project where I was working on an iOS client to talk with a REST API based on JSON API.

I'm not sure about the server-side implementation, but using it client-side was a breeze. I managed to completely automate my web-service calls to automatically parse/generate the required JSON and update the resources client-side.

Then, all I had to do to interact with new resources was register resources client-side with it's mappings.

@interface ModelResource : NSObject

\+ (NSString _)resourceName; \+ (NSString_ )resourcePluralName;

\- (void)createMappings;

\- (void)addAttributeMapping:(NSString _)attributeName toProperty:(NSString_ )propertyName;

\- (void)addLinkMapping:(NSString _)linkName toProperty:(NSString_ )propertyName withResourceName:(NSString _)resourceName;

\- (void)fromJSON:(NSDictionary_)jsonData; \- (NSDictionary _)toJSON;

@end

@interface UserModel : ModelResource

@property (nonatomic, copy) NSString _fullName; @property (nonatomic, copy) NSString _firstName;

@property (nonatomic, weak) EmailModel _emailAddress;

@end

@implementation UserModel

\+ (NSString _)resourceName { return @ "user"; }

\+ (NSString _)resourcePluralName { return @"users"; }

\- (void)createMappings { [super createMappings];

        [self addAttributeMapping:@"fullName" toProperty:STR_PROP(fullName)];
        [self addAttributeMapping:@"firstName" toProperty:STR_PROP(firstName)];

        [self addLinkMapping:@"emailAddress" toProperty:STR_PROP(emailAddress) withResourceName:[EmailModel resourceName]];

}

@end</comment>


This Google ad has moved people to tears across India and Pakistan - <AUTHOR> http://pri.org/stories/2013-11-16/google-ad-has-moved-people-tears-across-indian-and-pakistan?re <comment><AUTHOR> This is the ad: [http://www.youtube.com/watch?v=gHGDN9-oFJE](http://www.youtube.com/watch?v=gHGDN9-oFJE) \- be sure to have subtitles on (unless you understand Hindi).

One interesting observation about the ad: the search results that the girl deems to be good and informative are almost all Wikipedia hits. It's actually pretty similar to my situation: Google is basically a better Wikipedia searching tool than what Wikipedia provides.

<comment><USER2> Hindi or Urdu? Haha... I always find the "language vs dialect" thing very interesting. The distinction when it comes to Hindi and Urdu is totally political.

Two of my old buddies, one an Indian, the other a Pakistani, could completely understand each other, yet both insisted that they spoke different languages (Punjabi/Hindi and Urdu respectively)

Another friend of mind, who left Pakistan as a 10 year old, always just shook his head with a smile and said "Dude, that's like a guy from Alabama saying someone from England speaks a different language."

<comment><USER3> A Yiddish scholar once said that "a language is a dialect with an army and a navy."

It's really true. One might think that mutual intelligibility (ability for speakers of one to make themselves fully understood by speakers of the other) would be the standard for differentiating languages from dialects, but the distinction really ends up just being political. The spoken forms of Hindi and Urdu are entirely mutually intelligible but have two separate names.

Many varieties of Arabic and Chinese are mutually unintelligible but are called "dialects" of one Arabic or Chinese language, presumably to promote a unified Arab or Chinese identity. Speakers of Moroccan Arabic and Levantine Arabic or of Mandarin and Cantonese can't understand each other any better than speakers of Spanish and Italian can, but we don't call Spanish and Italian dialects of Modern Latin!

It gets even weirder when you have a dialect continuum, like with Polish- Russian-Ukrainian. Russian is somewhat mutually intelligible with both Polish and Ukrainian, but Polish and Ukrainian are not themselves mutually intelligible! So even if politics didn't play a role in the distinction between language and dialect, it would be hard if not impossible to come up with a universal distinction.

<comment><USER4> A side note: as a teenager I spent one summer working in a clothing store in London, with a bunch of Spaniards and Italians. They spoke to each other using their respective tongue, and said they could understand each other. Just basics of course.

Maybe someone from Spain or Italy could chime in here?

<comment><USER3> As with the Arabic and Chinese language families, different varieties of Romance languages are similar enough in syntax and vocabulary that speakers can kind of make themselves understood to each other if they speak slowly and choose their words carefully. Same with lots of closely related languages, e.g. German and Dutch. But they're not nearly mutually intelligible to the degree that American English and most varieties of British English are or that Hindi and Urdu are.

Regarding the Spanish/Italian example, the father of a friend of mine was fluent in Spanish, French, and Portuguese. Using an Italian grammar guide and his knowledge of Romance vocabulary from the other three languages, he learned Italian in a single flight from the US to Italy to the point where he was able to conduct business in Italy immediately upon landing.

<comment><USER5> I'm Dutch, and people from the east of Netherland don't understand why I don't understand German, claiming the languages are so similar. But I have real trouble understanding German. Maybe when it's someone from the north-west of Germany who speaks very slowly and clearly. People from the east of Netherland have much less trouble, somehow.

(I'm utterly unable to understand people from the Dutch province of Zeeland when they're speaking to their parents. That's complete gibberish to me, though it doesn't have a special status as a local language, as far as I know. (unlike Nethersaxon, for example))

<comment><USER6> I'm from Australia and I can't understand from the Australian province New Zealand.

<comment><USER7> "Australia's gotta become one country first."

The reply from former NZ Prime Minister Rob Muldoon when asked if NZ would ever become part of Australia.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> As a fellow Indian, I just want to point out that this video and any other efforts to develop people-to-people relationships between India and Pakistan have zero effect on the ongoing conflicts between the nations. Indians love Pakistani singers, cricketers, food, their language(Weird, I'm not a native Hindi speaker. But people tell me that Pakistani's speak better Hindi than most Indians). I've heard from Pak friends that they too love Bollywood and many things India. Even Pak government doesn't wish any ill on India. However the Pak army and ISI have vested interests in keeping conflicts alive. They also fund terrorist organizations in every neighboring country possible. Lack of democracy in Pakistan(Elected governments get routinely overthrown in coups) is a greater problem than religious extremism.

By that extension, lack of democracy in Saudi Arabia, and Egypt was the root cause of all Islamic terrorism. Saudi's actively promote a version of Islam that promotes religious discord in muslim populations across the world. I think the US missed a huge opportunity in encouraging more democracy during Arab spring and even the Iranian uprising.

<comment><USER9> You for got add your RAW and Indian army, mate.

<comment><USER10> I grew up an (Indian) Army brat, and have enough friends in there to say this: never did I hear a single Army officer express any desire to harm Pakistan by itself. The prevailing view was always "I wish these people would get over Kashmir and leave us alone". Take it for what it's worth.

The Pakistani Army controls a huge sector of the Pakistani economy, and benefits disproportionately in the budget. The only way they can maintain so much power is to have a low-level conflict going with India.

Tomorrow, if Pakistan and India signed a peace accord, and froze the borders where they are, the Pakistani Army would be basically useless. They don't want that.

</comment></comment></comment><comment><USER11> Colour me cynical, but when a corporation is under fire from consumers, regulators and activists, a soppy and heartstring-tugging ad is _exactly what the doctors order_.

It is literally Google saying, _" Oh look, cute puppies!"_ when faced with a global barrage of criticism about its disdain for user privacy or its own past promises.

<comment><USER12> Bang on! I don't think you are being cynical, you are being true! People across borders should stop being emotional over an _advertisement_ by a multinational corporation. If they really have to become emotional, there is plenty of literature on this topic in India, Pakistan and Bangladesh. And if they even want to take actions, there are many NGOs trying to ease up the visa procedure, raising awareness among the people etc. Talking about the technology, I think some years down the line all this will become some kind of "ambient technology", if you know what I mean.

<comment><USER13> Do you prefer the generic "people fiddling with their devices on a sunny day, female voice playing buzzword bingo in the background"? Props for Google for being ballsy.

I also love how people throw in the "multinational" qualifier as if this makes a company that much more evil.

<comment><USER11> I don't see how in any way Google is being "ballsy" here. It is a safe, soppy and relationships-oriented ad - in what world can that ever be "ballsy"?

Furthermore, I don't see the parent use the word "evil" in his comment.

That said, when a multinational that ferrets around billions of dollars in revenue around the world through obscure countries to avoid paying significant taxes in any of the countries it operates it [0], suddenly attempts to portray itself as warm, fuzzy and a big proponent of India-Pakistan friendship, forgive me for taking them at a lot less than face value.

[0] [http://arstechnica.com/business/2013/10/to-reduce-its-tax- bu...](http://arstechnica.com/business/2013/10/to-reduce-its-tax-burden- google-expands-use-of-the-double-irish/)

<comment><USER14> Yeah, except for the fact that they are dealing with relationships torn apart by partition.

<comment><USER11> They are not "dealing" with those relationships, but merely milking them.

</comment></comment></comment></comment></comment></comment><comment><USER15> For those that don't understand the ad, the partition was, and to be honest, still is a _very_ sensitive issue in India. My grandmother experienced it first-hand: people lost their homes, were separated from their families, and many people died along the migration from Pakistan to Punjab. There was no way for people to get back in touch... until now, which is why this Google ad is particularly poignant. As much as everyone here has loved to hate on Google for the past couple of weeks, the ad shows everyone just how valuable their products can be. It's certainly worth something... and it's a lot more meaningful than whatever Apple is doing with their marketing.

</comment><comment><USER16> This is a beautiful ad and will make you emotional. As a person of Indian background I was able to relate to it easily but I wonder what others think of it? Are you able to feel the strong emotions based on reading subtitles or does language hamper the feelings and it loses its impact.

Kudos to the team involved in this and thanks for posting this.

<comment><USER17> At least for me, the background song (from renowned singer and lyricist 'Piyush Mishra') adds a LOT in making me emotional - which they didn't translate. So I decided to add a rough translation for the same in the comments, but thanks to new Google+ integration - only junk is at the top on Youtube now.

Here's it again (translation of only the BG song), timed for those who are interested:

0:59 : Those narrow streets of childhood jump in joy again ... Tying those little sweet thefts along with it ...

1:35: (Same two lines above, then ... ) Where I would fly like a kite, like a bird ... That was the time .. when my heart felt like a free peacock ...

2:21: When I would sit immersed in those paper boats all day long, ... or 'entangle' myself with those windows peeking outside ... Oh, what a time that was, when there were no restrictions in the heart ... ... That was the time .. when it felt like a free peacock ...

<comment><USER18> Yes, the song is beautiful as well - thanks for translating it, although it's hard to do justice to the original.

<comment><USER17> Yes, agree. All the feelings in the original language can never be translated. The poetry is lost! I still love to translate things that move me, just to give non-Hindi speakers a rough context. :)

</comment></comment></comment></comment><comment><USER19> Behind the division of the sub-continent lies a great debate, that of Jinnah vs Gandhi. Was it the true aspiration of the people to get divided geographically while getting independence from British rule? It seems the divide happened because of some ideology driven people (Iqbal) who convinced other leaders (Jinnah) to pursue it. Today, this is a raging battle in Pakistan, did Pakistan ever need to be an independent country, considering how peacefully muslims are living in India vs the ready-to-cut-throats Pakistanis?

<comment><USER20> For those interested in history, _Freedom at Midnight_ is a great documentary book on the liberation and subsequent partition of India: [http://www.amazon.com/Freedom-at-Midnight-Dominique- Lapierre...](http://www.amazon.com/Freedom-at-Midnight-Dominique- Lapierre/dp/8125931864)

It's a sad fact that the departure of the British Empire from various colonial possessions frequently resulted in a power vacuum followed by deep internal conflicts which remain problematic today - Ireland, Israel, and India being three obvious examples.

<comment><USER21> > _It 's a sad fact that the departure of the British Empire from various > colonial possessions frequently resulted in a power vacuum followed by deep > internal conflicts which remain problematic today - Ireland, Israel, and > India being three obvious examples._

Not a "sad fact". It's how the "british empire" planned it, melticulously and with great effort and cunning.

It's a result of their "divide and conquer" way of ruling, in their colonial era, and it's something they pursued afterwards in order to keep it's post colonial grip on those places. With lackeys, puppet governments et al.

Oh, and add Cyprus/Nothern Cyprus, Ethiopia/Eritrea etc to the mix.

<comment><USER20> You seem to think I'm saying it was unavoidable/inevitable, but I'm deliberately abstaining from commentary on the causes. Being Irish myself, I have my opinions about this but this doesn't seem like the place to air them.

</comment></comment></comment></comment><comment><USER22> Amazing work!

What strikes me most is how little the language matters. You don't even have to watch it with subtitles to see how solid the editing was. Kudos to the entire team that worked on these videos.

<comment><USER23> the subtitles might have been a bit more necessary if all the on-screen text wasn't in english. That seemed like a strange choice for an ad produced by Google India.

<comment><USER24> The official languages of India are Hindi and English.

<comment><USER25> Not to be pedantic but Hindi is not India's official language, it's only English. Hindi is the national language but English is still the only language for official communications including that of the government.

Not sure about Urdu's status in Pakistan though.

<comment><USER26> Given all the comments about Google and Wikipedia, it's funny how you forgot to lookup Hindi. It is in fact an official language of India. Please gets your facts right.

</comment></comment></comment></comment></comment><comment><USER27> The Ad also has short sequels as well

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

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

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

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

<comment><USER28> Thanks for these links.

Just a bit unlikely that Ali would be able to read 'saunf' in Devanagari, isn't it?

<comment><USER29> The romanized form "Saumfa" is also shown in [https://www.youtube.com/watch?v=vYVoM8tgbvA#t=0m26s](https://www.youtube.com/watch?v=vYVoM8tgbvA#t=0m26s) .

<comment><USER28> Ah, yes. It's just that I'd expect Ali to search for "fennel in urdu", which does show the same word in Nastaliq.

</comment></comment></comment></comment><comment><USER18> They built a nice series of shorter vignettes based on the original ad.[1] These are perhaps less easily translated but they are sure to tug at the heartstrings of a subcontinental audience. Cricket, biryani and street food - who knew power-cuts and diabetes could evoke such nostalgia!

Well played, Google. I'll refrain from criticizing you for the next hour or so! :-)

[1] [https://www.youtube.com/watch?v=vYVoM8tgbvA&feature=c4-overv...](https://www.youtube.com/watch?v=vYVoM8tgbvA&feature=c4-overview- vl&list=PL-kIBfSqQg3uMx9Z1fOpc7WPw2wDvbhFu)

</comment><comment><USER30> The original concept was produced in a video by Pak Sar Zameen Productions on December 12, 2012

[http://www.hotpaknews.com/2013/11/did-google-stole-the- idea-...](http://www.hotpaknews.com/2013/11/did-google-stole-the-idea-behind- the-reunion-ad/)

<comment><USER31> Naw, this goes way back. The group Junoon had Ghoom Taana. And lots more before that. It's not a rip off

Sorry. No cc [https://www.youtube.com/watch?feature=player_detailpage&v=86...](https://www.youtube.com/watch?feature=player_detailpage&v=86fVq7iJcG4)

</comment></comment><comment><USER32> The most interesting aspect of this video - other than the clearly emotional storyline - was how closely it reflects the way most of us use the web, smartphones, and yes - Google - to manage our day-to-day lives. A search for a landmark, a shop, to answer a quick question, to check the weather, to book a flight. Even more remarkable how almost none of this was possible a mere 10 years ago - at least not from the palm of our hand.

</comment><comment><USER33> Very Interesting Ad and as being a Pakistani I can actually feel it. Although, technically finding places in Pakistan using Google Maps is not as easy as shown in the video. There are still many problems with wrong land marks and more.

But as a whole the content of the ad is very strong and positive that it can touch million more hearts!

</comment><comment><USER34> Great ad. Here's something similar, by Coca-Cola: [http://www.youtube.com/watch?v=ts_4vOUDImE](http://www.youtube.com/watch?v=ts_4vOUDImE).

Not as emotional, but quite good.

</comment><comment><USER35> Hell, I'm just some random white guy in the US and the ad made me tear up. Yes, it was made for effect. Whether it was made by the newest evil corporation or not is irrelevant. The feelings it invokes are genuine.

</comment><comment><USER36> I wish Google could also improve the visa process for India which gets a brief cameo in the video. I've been trying for weeks to obtain a visa now and have been thwarted by the Indian government and its designated consultant's computer systems at every turn. It's to the point I've given up and am going to pay for a service to do it.

<comment><USER37> Are you from Pakistan? or somewhere else?

For Americans getting a visa seems to be easy. Maybe not for some other countries?

</comment></comment><comment><USER25> The sad part is as an Indian myself I know that the reality is much different. If I started calling Pakistani phones the government will probably start investigating me for being a suspected terrorist and the old gentleman from Pakistan will never get a visa so swiftly. It's perhaps true the other way around.

Even if people want to come closer the state and politics always gets in the way.

</comment><comment><USER38> This ad makes me tear up every time and the music is what takes it over the edge for me. The ad is scored so beautifully, the melodies and arrangements are incredible. Even though I can't understand what the singer is saying, I can definitely feel the emotions in his voice.

</comment><comment><USER39> "This Google ad has moved people to tears across India and Pakistan"

Probably not all across India. I am from the south and neither me nor my ancestors have any personal experiences from the partition. Don't get me wrong.. this is a great ad and I understand the emotion behind it. but this is only as moving as a similar story on the Israel-Palestine border(ok maybe a little more because of my high school history books and representation in popular culture). Culturally, South India is more seperated from the North compared with North India (Punjab, Delhi, Kashmir) and Western regions of Pakistan.

To me this is a well produced ad which highlights the troubles of a particularly cruel time in India's history. Nothing personal about it.

</comment><comment><USER40> I'll probably get downvotes, but here goes: I liked the ad, it moved me, it didn't bother that it was from a big corporation (re the discussion below). What bothers me in ads, and in movies etc, is how the men can always be some regular looking man, sometimes even ugly, while the women always have to be very attractive. I know I'll get called on for being too P.C. for this but c'mon, does it always have to be a very attractive indian girl? Does Virginia Woolf need to be played by Nicole Kidman? Salma Hayek as Frida Kahlo? The biopics about men aren't always played by Tom Cruises.

</comment><comment><USER41> Here's the story of Saroo Munshi Khan finding his home/family 26 years after he lost them with the help of Google Earth:

[http://googleblog.blogspot.com/2013/10/a-long-way-home- with-...](http://googleblog.blogspot.com/2013/10/a-long-way-home-with-help- from-google.html)

He wrote a book about his experience: "A Long Way Home" ([http://www.penguin.com.au/products/9780670077045/long-way- ho...](http://www.penguin.com.au/products/9780670077045/long-way-home))

</comment><comment><USER42> It's a pleasant ad, though it also reminds me of [http://www.stevenlevy.com/index.php/05/08/the-sophie- choice](http://www.stevenlevy.com/index.php/05/08/the-sophie-choice) :

"There were no actors seen in the Super Bowl commercial, and that was part of its charm: even though it broke one taboo, it maintained the company's geeky dignity of logic and verifiability. The star was the stuff that appeared on the computer screen. But "Dear Sophie" is more of a classic form of Madison Avenue pitching. It's probably something that Don Draper would come up with if Larry and Sergey were his clients. They would tell him that their product, the Chrome browser, has a lot going for it over its competitors, like speedier response and a single box to type in addresses and search queries. It runs Web applications more efficiently than other browsers, they'd tell him, and if everyone used it, it would hasten a new paradigm of cloud apps. Draper would say that all that stuff is well and good. But for our commercial, we're going to show a tear-jerking evocation of a father compiling an online scrapbook for to his daughter as she grows up.

Straight out of the Kodak playbook–don't brag about your specs, but play that song about Where Are You Going My Little One, and out will come the handkerchiefs. It's also a stratagem used by banks and insurance companies."

Mind you, that was two years ago and feels somewhat like ancient history now.

</comment><comment><USER43> How many of you paused the video to search for "jhajariya" and clicked on the Wikipedia link?

<comment><USER17> Not paused but searched after the video ends :). And 'verified' that the correct definition does appear. :P

</comment></comment><comment><USER44> I hope this is still hacker news rather than some emotional fools forum who ignore realities.

<comment><USER45> Don't worry, I'm sure someone will come along to comment on the web design on some computer screen in the background. And that will be OK.

<comment><USER44> Better would be if someone discuss how we can bring up [http://extendedsubset.com](http://extendedsubset.com) ;)

<comment><USER45> How important is it for you that we bring back the old content?

</comment></comment></comment></comment><comment><USER46> A Pakistani girl showed this video to me early this year, and she was in fact very moved.

The Pakistan - India divide is a tragedy of religion and politics, foreign and domestic.

</comment><comment><USER47> The India Pakistan separation has left a scar on the hearts of several generations. Power hungry and religious fanatics caused this separation. Today's youth view the separation as a boon, but the million people killed in the riots and other millions made homeless still haunts and affects the geopolitics of the region.

</comment><comment><USER48> Well it's moving someone to tears in the ol' USA too.

</comment><comment><USER49> So, the oldest sweet shop in Lahore just happened to be owned by Yusuf's grandson? How?

<comment><USER50> From the initial conversation between Baldev and Suman, it's clear that the sweet shop has been owned by Yusuf's family for several generations. Not sure how Suman knew it was the oldest though, unless Baldev told her that and the subtitles just didn't translate it.

</comment></comment><comment><USER51> Oh yes, we have the best sweets, and the most awesome Curry in Lahore. That is one thing we are extremely proud of. So people on Hackernews, next time you plan on taking a trip, come over to Pakistan for some of the most awesome culinary delights!

</comment><comment><USER9> Let's not forget it's an Ad only.

Emotional Marketing?

God bless Capitalism!

</comment><comment><USER52> Just wondering if reactions would be as positive if the product wasn't Google but, I don't know, Glock pistols or Royal Dutch Shell (aired 7 days after an oil spill). You could change the story to fit almost anything, after all.

</comment><comment><USER53> Like many of you said, it's true that Urdu and Hindi are pretty much the same when it comes to the colloquial, spoken form of the languages. However, when you experience more advanced usages of the languages, they begin to sound totally different. Watch a news broadcast in Hindi and Urdu and you'll see what I mean. The formerly seemingly identical languages diverge sharply in academic settings and literature because Urdu borrows it's more advanced words from Persian which in turn borrowed these words from Arabic whereas the more advanced Hindi vocabulary is based on Sanskrit.

Not to mention the script is totally different.

</comment><comment><USER54> You don't need to be Indian or Pakistani to be moved to tears by this ad...

</comment><comment><USER55> I grew up in and around Mumbai...the ad is (unsurprisingly) quite disconnected from the facts on the ground but holy cow. Great production values, great storytelling, relevant tie-ins to Google products. Just great.

</comment><comment><USER56> So half a day later, and no one on HN noticed the most interesting fact about the ad was its THREE AND A HALF MINUTES LONG?

I mean I've had mythtv and commercial skipping for I guess over a decade now and I adblock all browsers etc but do people "out there" really sit thru almost four minute long advertisements? Back when I used to watch them, commercials were long enough for a bathroom break, sounds like commercial breaks are approaching "short workout followed by a shower" or perhaps "cook and eat some hot pockets" length of time.

<comment><USER57> There are plenty of long ads around.

Sometimes they're good, and I don't mind sitting through them. There's one featuring a British Bi-Athlete (skiing, shooting). I have no idea what it's advertising. I looked up the gun he was using and they do a really neat laser & target system. Like Tin Can Alley but for adults.

Long ads are much less impressive when they're repeatedly something I have zero interest in ("It's showtime, you've been coding like a beast "[SKIP]) or when they're lousy ads created by people who don't know what they're doing.

I usually leave them running in another tab until the content is ready. I understand why other people would hate them and want to ad block them.

Also: I have zero interest in gambling, and I never want to see a gambling ad, but I get loads. I wonder what recovering alcoholics or addicted gamblers could do to prevent those ads from appearing, other than using ad-block?

<comment><USER56> "I understand why other people would hate them and want to ad block them."

Its not hate so much as being an unactionable distraction that interferes with buy the perry the platypus wooden action figure it does nothing... oh wait see how annoying that interruption was and how little it added to the conversation?

Personally I prefer paid promotional product placement. So I was working on a S-100 circuit board in my basement "lab" last night using my Hakko model 937 digital temperature soldering iron with 1/16th inch tip (or whatever millimeters it is) and my Kester no-kleen #235 flux 0.02 dia solder (well you get the idea) Like how most hollywood computers happen to be Apples.

</comment></comment></comment><comment><USER58> I like the "south park episode with ancient aliens" part most. [http://i.imgur.com/ZDoYFdR.png](http://i.imgur.com/ZDoYFdR.png)

</comment><comment><USER59> Interesting point is that no sweet shop owner knows any sweet by the name of 'Jhajaria' in Lahore. Even 'Fazal Sweets' shown in this ad doesnt know about it. Same seems to be the case in India: [http://thedailyretard.in/demand-for- jhajariya-on-the-rise-af...](http://thedailyretard.in/demand-for-jhajariya-on- the-rise-after-googles-reunion-ad-goes-viral-sweet-shops-owners-confused/)

</comment><comment><USER60> great ad..well done google. Maybe it takes a neutral 3rd party to make bothers start talking. Can we get a north korean version next?

</comment><comment><USER61> Superb advert.

Slightly amused after realising that the first thing I then did was use Facebook search to find Google's page to share it.

</comment><comment><USER62> No ad will ever beat this diet coke ad:

[http://www.youtube.com/watch?v=ZmBDeswu2dI](http://www.youtube.com/watch?v=ZmBDeswu2dI)

Now diet coke, IMHO, is crap and I won't drink the stuff but I can watch this ad over and over again. Can one of you marketing geniuses in the audience tell me why it is so awesome? :)

</comment><comment><USER63> But for Bania Gandhi, implementing 'separate' electorates as per [https://en.m.wikipedia.org/wiki/Communal_Award](https://en.m.wikipedia.org/wiki/Communal_Award) would have prevented India-Pakistan partition.

</comment><comment><USER64> On the topic of top notch commercials out of India, here's a memorable series from Vodafone: [https://www.youtube.com/watch?v=wtDYZHGzGLE](https://www.youtube.com/watch?v=wtDYZHGzGLE)

</comment><comment><USER65> Google seems to be the expert in heart-warming commercials. Remember their first super bowl ad? [http://www.youtube.com/watch?v=tQ4unnMgiSQ](http://www.youtube.com/watch?v=tQ4unnMgiSQ)

</comment><comment><USER66> Reading the subtitles reminded me of a dream of mine I would like to see realized some day: A live audio-to-text translation to English scrolling across the bottom of a Google Glass screen.

Talk about bring the world together...

</comment><comment><USER67> I love to see similar Adverts with divides between \- Israel and Lebanon. \- North Korea and South Korea \- East Berlin and West Berlin etc...

For me, this is one of the areas where technology can enrich our lives.

</comment><comment><USER68> i am from india and i can tell you that no one i talked to found this ad 'moving'. its the same cheesy bullshit that we see all day.

<comment><USER69> I am from India and lot of my friends find this one moving.

</comment></comment><comment><USER70> Very moving and and this article really helps everyone understand the history of the partition that occurred.

</comment><comment><USER71> The thread where all HN users reveal their nationality, hometown, family status and what not. So good!

PS fuck NSA

</comment><comment><USER72> /r/HailCorporate

</comment><comment><USER14> Is it true that Apple doesn't have a single store in India?

<comment><USER73> [http://www.apple.com/in/buy/shop/](http://www.apple.com/in/buy/shop/)

[http://www.istoreindia.com/index.html](http://www.istoreindia.com/index.html)

</comment></comment><comment><USER74> It doesn't hurt that the acting is also phenomenal.

</comment><comment><USER63> Are these Actors from Pakistan?

<comment><USER73> No, they're are Indians. It's made by Ogilvy & Mather, India.

Cast info: [http://www.missmalini.com/2013/11/15/have-you-watched-the- go...](http://www.missmalini.com/2013/11/15/have-you-watched-the-google- search-reunion/)

Production info: [http://www.ogilvy.com/News/Press- Releases/November-2013-Camp...](http://www.ogilvy.com/News/Press- Releases/November-2013-Campaign-for-Google-Search-by-OM-India-celebrates- emotions-of-reunions.aspx)

</comment></comment><comment><USER75> Great ad !!!

</comment><comment><USER76> an ad with a value.

</comment><comment><USER77> Yes I was suitably manipulated. Good job, mass emotional manipulation team!

But I am surprised they showed people searching for flight status and weather. Google Now is supposed to already know you're going to Delhi and just show you the weather there without you asking. Same for the flight status.

<comment><USER78> "Yes I was suitably manipulated. Good job, mass emotional manipulation team!" \- thrownaway2424

Just agreeing with your sentiment, might as well share the downvotes.

</comment></comment><comment><USER79> I don't care about emotionally manipulative film for its own sake. However, if this did actually do anything significant to improve Indian/Pakistani relations, I really would forgive Google for its asinine product design decisions for as much as half a year.</comment>


Ask HN: What are some simple things people can do to be more secure (online)? - <AUTHOR>

Basically, what are easy things that everyone should be doing to keep their information secure?
Things that the average user would be able to do (and should be doing), but wouldn't be so burdensome/onerous that the average user would choose to not do.
2-Factor authentication is an obvious one here.
Complex passwords/not reusing passwords would be another.
Things like that? <comment><USER2> This is what I tell people when they ask me how to protect themselves from malware:

If you are a Windows user, don't fully disable UAC.

Don't use pirated software, you never know what may be in there.

Don't open files you're not expecting or not sure about what they are even if they where sent from someone you know. If in doubt, ask.

Antivirus software is a poor substitute for common sense.

</comment><comment><USER3> Update both the web browser and the operating system with security patches as they become available.

Don't "over share" on social media.</comment>


How Good Software Makes Us Stupid - <AUTHOR> http://tech.slashdot.org/story/10/09/13/1342209/How-Good-Software-Makes-Us-Stupid

<comment><USER2> Compare and contrast: <http://news.ycombinator.com/item?id=1683888>

Many comments there.

<comment><AUTHOR> Thanks. The original BBC article: <http://www.bbc.co.uk/news/technology-11263559></comment></comment>


The Battle for Picasso's Multi-Billion-Dollar Empire - <AUTHOR> http://www.vanityfair.com/culture/2016/03/picasso-multi-billion-dollar-empire-battle <comment><USER2> This appears to be a fantastic example of why you should always make sure you have a will in place.

<comment><USER3> Or why copyright should not be effectively forever. Not one new artwork is produced by still allowing copyright on Picasso's artwork.

<comment><USER4> > Not one new artwork is produced by still allowing copyright on Picasso's > artwork.

That's quite a claim. It's conceivable that someone today considering whether to devote time to producing some work of art, rather than pursing another endeavor, would make a different choice depending on how many years he might expect that he and his heirs would have exclusive rights to it.

<comment><USER3> I have yet to meet an artist motivated by the existence of copyright 50 years after they are dead. If anything knowing your heirs won't be able to live off your copyright after you are dead should motivate an artist to produce more today and pass on the money.

<comment><USER4> > I have yet to meet an artist

You went from an unprovable absolute claim to providing anecdotal evidence. I'm not saying you're wrong... just that what you've said so far doesn't convince me that "copyright should not be effectively forever" or that "50 years after they are dead" is "effectively forever".

This is by no means my area of expertise, but I'll give you an (probably unoriginal) example. Let's say an artist creates something at age 30. He could use some extra money at age 70. Wouldn't he be able to sell the rights for more to someone who the law will allow to retain those rights for more years after this artist has died?

<comment><USER3> It is not an unprovable absolute claim that Picasso has not produced any artwork since he has died - it is a fact.

The only question is would having long copyright have motivated Picasso to have created more art when he was alive. Given that the extensions to his copyright occurred after he died we can be pretty certain that unless he was a clairvoyant that the later retrospective changes to the copyright laws did not motivate him to produce anything.

More fundamentally great artists create art because they have to - it is part of their core. Art existed before copyright for exactly this reason.

<comment><USER5> what's discouraging is that some of you are essentially implying that picasso should have sold himself as a service (make more art while alive) instead of doing whatever a once-in-a-timeline artistic genius needs to do to create priceless artifacts that, by the way, required the investment of his, and his family member's, lives to realize. when his works are equatable with the lyrics to "happy birthday" this might be worth revisiting; until then why don't you buy some art? [http://fineartamerica.com/featured/copyright-john- muellerlei...](http://fineartamerica.com/featured/copyright-john- muellerleile.html)

<comment><USER3> Actually not at all. I believe from all I have read about Picasso he would have been a productive artist even if no copyright existed - he was a great artist and creating art was at his core.

I actually buy a lot of art - I have long since run out of wall space to hang it all :) None of the artists I buy are producing art just for the money and copyright plays no role in why they are an artist.

<comment><USER4> > I believe from all I have read about Picasso > None of the artists I buy are > producing art just for the money and copyright plays no role

You seem to be presuming to know the motivations of every artist to have existed based on your personal experience. Is it so inconceivable to you that there may be someone who, let's say, is considering writing a book, wouldn't at all be motivated by how much money he could earn in return for the investment of his time? And take into account the fact that he could potentially sell the rights for considerably more, the longer copyright guarantees exclusive rights to the owner?

<comment><USER3> The value of lengthly copyright is basically zero to any rights buyer at the time of production due to the very high discount rate used in the arts and publishing industry. If it weren't zero then publishers would pay more to young authors than old authors. If you can find one artist that has ever said they create more because their heirs can live off the copyright 50 years after they are dead please show us.

The only value to retrospective copyright extension is to give a windfall profit to rights holders long after the artist is dead. It is outright theft of our cultural heritage.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> Reminds me of when Claude Picasso formally objected to an Australian pizza shop called "Pizza Picasso", their tag line "Pizzas of Art".

Didn't go well for Claude. Pizza Picasso is still open for business here in Sydney.

From article:

In September 2001, an intellectual property hearing in Canberra threw out Claude's objection. In his summary, the hearing officer, Jock McDonagh, included this memorable sentence: "I am not aware of any connection that Pablo Picasso might have had with restaurants or pizzas in his lifetime. While the mere mention of his name might immediately evoke images of his art and artistic genius, it does not likewise summon up visions of pizza."

</comment><comment><USER7> Authorities should null and void the whole lot for public good.

</comment><comment><USER8> Marina doesn't come across in the best light.</comment>


ClojureScript interface to Facebook's React - <AUTHOR> https://github.com/swannodette/om

<comment><AUTHOR> David Nolen's post explaining the benefits:

[http://swannodette.github.io/2013/12/17/the-future-of- javasc...](http://swannodette.github.io/2013/12/17/the-future-of-javascript- mvcs/)

> immutable data allows a new library, Om, to outperform a reasonably > performant JavaScript MVC like Backbone.js without hand optimization from > the user.</comment>


Ask HN: Can AI break cryptography? - <AUTHOR> I've been wondering about this for some time, and theoretically, it should (at least to an extent) be possible for AI/ML to break some cryptographic functions -- or more concisely, decrypt some crypto outputs. However, is this proven to be true/false? <comment><USER2> Simple answer, no.

Trained AI works (in the simplest terms) by incrementally tweaking coefficients in mathematical statements to best approximate a set of data points provided. Generally it does this by being able to measure how close or far away the AI is from the right answer in trainable cases and then minimizing this distance.

For this to work in cryptography, we would need to have a formula which already breaks cryptography in a general sense that we can tweak for specific cases using AI.

What AI _might_ be able to do is to demonstrate previously undiscovered relationships in number theory by throwing a whole heap of cryptographical relationships at an AI to uncover an undiscovered correlation. The chances of this are pretty small, but an AI might get lucky.

<comment><AUTHOR> > What AI might be able to do is to demonstrate previously undiscovered > relationships in number theory by throwing a whole heap of cryptographical > relationships at an AI to uncover an undiscovered correlation. The chances > of this are pretty small, but an AI might get lucky.

Yeah this was what I was thinking. Train the AI on millions of crypto and plaintext datasets on thousands of algorithms and it might uncover some hidden numerical ways to relate the two together.

</comment></comment><comment><USER3> AI won't. Quantum computing may. But then cryptography will evolve as well.

</comment><comment><USER4> No, why would you think so?

<comment><AUTHOR> Well, AI can "imagine" the full contents of complex 3D scene simply by being shown three images at various angles, so I thought there might be a possibility to train an AI how to look for patters in crypto and plaintext and "imagine" the function as well.

Any way you can point me to a paper (or otherwise) which explains why this is mathematically impossible?

<comment><USER4> I'm not a mathematician so the best I can say is that cryptographic functions are specifically designed to be "unimaginable".</comment></comment></comment>


Recruitmate – An app that applies to jobs for you - <AUTHOR> http://getrecruitmate.com <comment><AUTHOR> Hey guys, I was tired of applying to jobs last year, so I came up with the idea at a hackathon to build a job applying program that lets you apply to hundred of positions in 1 click.

Simply fill out your ideal job title that you're interested in, upload your resume and contact info and my program will do the applying to individual companies for you.

Have a try! Let me know what you think!</comment>