Relight is a tool to help you study the Bible and theology from a reformed perspective. We do this by making classic reformed resources (and some more modern ones) more accessible, and by linking them together in new and helpful ways.
A lot, and the collection is only growing! We have commentaries from John Calvin, Matthew Henry, Matthew Poole, and more. We’ve also got the Westminster Standards, the Three Forms of Unity, several reformed baptist standards, The Lord’s Prayer by R.C. Sproul, and more! Check out our library to see everything.
Roadmaps are tricky for any development team, and even trickier when there is only one developer on the project—so we don’t like to get too specific about our plans. In the near future, we’re hoping to add Charles Hodge’s commentary on 1 Corinthians and some other resources. We’d also love to add features like Strong’s tagging, Greek and Hebrew bibles, a more modern translation as an option, as well as better tools for finding related content that leverage machine learning. Oh, and we want to add user notes, tagging, and highlights and we want to make a mobile app. Phew! We’ve got big dreams.
This is something we very much want to accomplish. Understand that there is only one developer working on this project. Actually, there are only two people working on the project, David and Sarah. Maintaining a web app is hard enough, but we are working on a real app. We just did a pretty big rewrite of all our code to make the app easier to turn into an iOS and Android app.
With each platform we choose to support, we make the project more complicated. Adding iOS will mean adding Swift as a language (one which David has spent quite a bit of time learning over the past few months), together with several libraries of tools. Adding Android will do the same, and anyone who has worked on iOS and Android apps will tell you that Android apps are harder to make, like a lot harder to make. So while we’re hoping to eventually have an iOS app and an Android app, iOS will likely come first. We may actually have to enlist help from another developer to get an Android app done, but we do want to do it as well.
We plan, by the way, to support offline mode for most of the app’s features—although due to the nature of how Relight is made, some advanced features, like Backlinks will likely always require an internet connection.
We are using a definition of the word reformed that means the resource needs to not contradict what the Westminster Standards, the Three Forms of Unity, and the London Baptist Confession all agree on. There may be rare exceptions to this for historic works from men like Augustine, but we want to get a lot more reformed goodness packed into Relight before we go after resources like that.
At this point, we’re deciding mostly by what is going to be easy to import relatively quickly. The Relight library is unique in that everything is interconnected, so there is a process every book has to go through to be added to our library. Besides trying to find resources that won’t be hard to convert, we also try to grab the resources we think will be most helpful to people—which is admittedly a pretty subjective qualification, since we’re basically going off of what has been most helpful to us.
We’ve stated this in several places, but we are only interested in adding reformed resources. We define what we mean by that the previous question, and it’s worth noting that if we are ever importing a resource that we have questions about (questions like, “is this helpful?” Or “is this reformed?”), we will ask the elders at our local church. David and Sarah are both members in the RPCNA.
Join our little online community and post here!
This is a little complicated. The first reason we only have the KJV, and probably the most important reason, is that it’s really hard to get access to translations besides the KJV (and other 400+ year old translations). Modern translations are published by businesses who want something in return for letting our users have access to their translation. We’ve approached some publishers and they weren’t interested at the time given the size of our audience.
It’s also important to note that Relight is a free app. It’s made by us, David and Sarah, mostly in our free time, and we don’t have the resources to pay publishers for their translations. We hope some day to have a large enough audience that some publishers may just give us their translations because they want to help people get access to God’s Word; the publisher’s aren’t evil. They just have a lot to do and they’re only going to invest time into getting us the translation and negotiating a contract if they see it as worthwhile. The biggest thing you can do for us is share the app. The more people that use it, the more leverage we’ll have next time we reach out.
The second reason we only have the KJV is actually principled. Don’t worry, we’re not KJV-onlyists. We just believe that the verses and words omitted in many modern translations are actually part of Scripture and they shouldn’t be omitted. And so did the men who wrote pretty much all the resources on our site. If we added a translation that didn’t have, for example, the ending to the Lord’s Prayer, a lot of links on our site, especially in the catechisms, would break and require development time to handle gracefully—and even then, it would be a kind of awkward experience no matter what, having to write a little explanation for why the verse you just clicked on doesn’t exist in the translation you chose. That said, there are a few modern translations that don’t omit these verses, and there may be a way for us to include them from the footnotes of other modern translations. We’ll be evaluating each translation we pursue with the elders at our church and trying to do what’s most helpful for people.
Lastly, please know that we do understand that the KJV is a difficult translation to read, at least in some places. And we do hope to one day add more translations.
We’d like to hope this question mostly answers itself, but in case it doesn’t, here are a couple reasons we made Relight.
This is an excellent question. Right now, it’s mostly sustained by will-power. But we’ve mentioned a number of times that we would love to put more time into the project than just our free time. Also if we get too many users, the server costs could become something that we can’t afford to sustain on our own (although David wants to brag here about how the architecture means we can support a lot of users on just a $10 a month cloud server). In the long run, we’re not sure how we’ll do that, but we want to make the following promises:
First, thanks! There are a bunch of ways you can help, as outlined below:
That’s not a question. You need a question mark. Try “What do I do if I’m having a problem with the app or one of the resources?” Anyway, if that’s the case, you can contact us here. You can also report it on our online community and have a much better chance at hearing back when we fix it (it’s harder to keep track of emails than requests that come through on the message board).
Version numbers are weird. They don’t behave like math expects them to, and they often give users cause to think something big should happen with certain kinds of releases. When you go from version 1.0.3 to version 1.0.4, no one expects anything, but when you go from version 1.3.2 to version 2.0, people expect fireworks and a cake.
It’s hard to tell when you should do a big version, and when you shouldn’t. Version numbers get weirdly political and debates around them get weirdly heated. I can remember working in support for software and having people complain that their favorite feature didn’t make it into the new version 6.0. Some people even got upset because they feel like it hasn’t been long enough since version 5.
Anyway, we decided to try and dodge all of that. We wanted to be able to launch one big thing whenever we want, not wait until we have 5 of them and can justify going to version 7, since we’ve been on 6 long enough to have the version number 6.95.84. Each version is just named with the current year, and the number release that it is. So if the first release in 2024 goes live in March, it will have the name 2024.0—same if it goes live in January. After that will come 2024.1, then 2024.2, and so on. You understand counting.
This way no one gets their hopes up. If we have some big new feature or change, we’ll announce it. We don’t need a full-integer version number to do that. If you want to know what’s changed, you can follow the blog or follow our social media. When we have something big, we’ll make a big deal out of it with pictures, gifs, and maybe even lots of shouting.
Right now, almost everything on our website is in the public domain. The only exception currently is that <em>The Prayer of the Lord</em> by R.C. Sproul is © 2009 R.C. Sproul Trust. (All worldwide rights reserved. Used with permission under license.) We’ve done a lot of work to clean up the public domain works and make them accessible, but the content itself is in the public domain and we don’t want the work we did to change that. What we mean is that you can take the public domain content from the website using whatever tools you want, and you can use that content in whatever way you’d like. If you want to write an elaborate script in Haskell that extracts every other word from Calvin’s commentaries that starts with ‘p,’ and then publish that to some obscure message board, please feel free.
Something worth noting is that we would eventually like to add more things like modern Bible translations and books from various publishers. The policy for public domain books, obviously doesn’t apply to the copyrighted content. We’re still growing and learning how best to make copyrighted materials, but in general, you’ll find the copyright at the bottom of any chapters (and the table of contents) from any copyrighted works. If you see a copyright, you’ll want to go to the publisher to find out to what degree you can quote it. Most publishers will at the very least allow copying a paragraph or two for things like church book studies or Sunday schools, but it’s always safest to look the policy up on the publisher’s website, or contact them directly with any specific questions.
There I was, in the jungle, surrounded by ninjas. Okay, nothing so exciting. Basically we had some ideas for an app and David started learning programming so that he could build it. He had a little experience doing minor scripting things, but this was his first big project. It took a while, but, well, obviously we made a thing.
In terms of technical mumbo-jumbo, Relight is made with Neo4J as a database, which is what powers features like Backlinks, and we hope it will power a lot more features that help you find connection between different pieces of content. The backend is written in Python, using something called FastAPI—basically a fast web server so you don’t have to wait long to refute anabaptists on Twitter. And the front end was recently rebuilt using NuxtJS, a nice clean front end framework that should make adding new features really easy. It had previously been written in Jinja2 and JQuery, if you’re wondering.
