Hacker News Reader

Comment by danShumway | Hacker News Reader

The Bible isn't that large in terms of actual data, it's all text. So storing a bunch of translations locally seems pretty easy. And from what I can see from the documentation, this only allows querying chapters/verses across translations, so it doesn't seem to be doing a lot of serverside work to link data together or to find references to names/places, or to merge translations together in some way.

Is there a reason I'm missing why this is an API instead of something handled locally in a structured data format? Does it have access to a bunch of licensed translations that I couldn't use locally or something?

I guess I'm just a little confused at what the value add is of having be online instead of local.

View on HN

The problem isn't "pretty easy" per-se (different translations assign different chapter/verse numbers in places, for example) but there has been lots of work spent on it already. There are protocols and formats to manage Bible texts, and entire organizations revolve around maintaining these (e.g. https://crosswire.org/). Some of them even have provisions for dealing with copyrighted materials (with unlock keys that you can buy).

The red flags I see:

* That site doesn't mention such prior art _at all_.

* First thing I run into when trying to get a list of translations is Cloudflare. Nice, preparing for hyperscaling already! However, no discussion anywhere about the threat model of providing texts that can spell trouble in parts of the world through arbitrary third party services.

This specific API doesn’t attempt to handle any of the even vaguely interesting problems like versification translation or footnotes, or even more basic things like where paragraph breaks lie. Instead, it’s just verse-per-line stuff loaded into a relational database of four tables: verse ∈ chapter ∈ book ∈ translation, all indexed by auto-generated IDs rather than anything sane, leading to a supremely awkward and remarkably inefficient ID-based REST API that’s unreliable to boot. I’m afraid the more I look at it the more I say it’s simply bad, having been implemented rather than designed, so that it’s unfortunately just about useless for any actual purpose.

The most likely explanation for Cloudflare is garden variety DDOS protection. I don’t see that as a red flag?

The barebones website doesn't discuss _anything_ about which data processors might end up with the ability to connect your IP (or even better markers) with access patterns to that API. The service didn't actively hide Cloudflare but it also didn't document it. I wouldn't know how many other services are in use right now that I didn't stumble over, or how many there will be at any time.

For a service that (if actually useful, which this isn't, so I expect it to flounder and therefore not do any actual harm) could be dangerous to use in some regions of the world, that seems reckless, as if "uhoh, this could be dangerous" was never even a consideration.

I don't know about the author's intent but licensed content seems to be one of the strongest reasons to use an API. Some translations have their own (esv.org for instance) but not all do. Unfortunately getting permission to add a translation to such an API is difficult at best and others have tried.

Reply on news.ycombinator.com