Dantes Wiki

Has This Ever Happened to You?

You are excited to start the third book in a series. You begin reading and it’s going great. But then they start talking about characters as if you know who they are and…well it’s been a while and maybe you don’t exactly remember who that is. Or maybe you are reading The Count of Monte Cristo and just can’t keep all the French names straight.

You think well, maybe I’ll just do a quick web search to refresh my memory. But Google and wikis don’t know which book you’re on; what if you spoil a massive plot twist down the road? Best not to risk it.

The Concept

A wiki-style web platform for fiction that only shows details that the user has already been told and just forgot.

All we need to do is:

1. Completely deconstruct a wiki.
2. Tag every piece of information with where it originates in the source material.
3. Filter out everything the user hasn’t gotten to yet.
4. Pick the most up-to-date version of any conflicting info.
5. Put everything back together.
6. Hope for the best.

The Data

The wiki has a list of publications, in chronological order if possible. A publication can “follow” another publication if we can reasonably assume that readers have already read the prior book. For example, The Two Towers follows The Fellowship of the Ring, but The Fellowship does not follow The Hobbit. This assumption will make things much easier on our editors because they can build on the info from previous volumes instead of starting over for each book.

Each publication has a list of chapters.

Content is organized into articles such as Bilbo Baggins or Took Family. Each article has several components. Some components, like name are unique: the article has only one. Others, like body paragraph can appear multiple times in the same article.

Each component has a collection of updates, one for each time the content of the component should change through the course of reading all the chapters. Each chapter may replace, remove, or carry forward the content from the preceding chapter.

Example

We meet Gandalf in the first chapter of The Hobbit, so there is a component update for body paragraph tied to that chapter that gives a description of his appearance. In the second chapter we learn that he rides a white horse, so there is a second update that overwrites the description, adding the detail about his horse. A user who has read the second chapter will see the additional detail.

Browsing the Data

As a reader, all one must do is tell the site which chapters they have read, then navigate the site like a regular wiki.

The site will automatically (and forcefully) mark complete any publications for which the user has progress in a following publication.

The site has a global search that only returns articles that the user should have access to.

Implementation

I used the VILT stack (Vue, Inertia, Laravel, Tailwind) because I was comfortable with VLT and interested in learning I. I started out with Laravel’s Vue Starter Kit which comes with authentication, user registration and login, and some layouts + components. I used Spatie’s laravel-data package for contructing resources for the front-end, and Laravel Wayfinder to auto-generate TypeScript types for them.

It’s a fun, opinionated stack that does a lot of things for the developer and feels suited for prototyping. It seems like it could become a headache if performance ever became a high concern.

I also build a Filament admin panel for data management. Most editing tasks are done via the regular Inertia user interface, but some infrequent tasks like user and publication management still require using the admin panel.

The Middle Earth instance is hosted on Laravel Cloud which was very easy to set up with its own PostgreS database. The only external services I had to hook up were Nightwatch for monitoring and an email service. Laravel Cloud can hibernate servers and databases when not in use to save on compute time, so it may take 10 seconds to wake up the app if it is slumbering.

Drawbacks and Limitations

User Account Required

Currently, user accounts are required for browsing because that’s how I implemented keeping track of which chapters the user has read. It shouldn’t be too difficult to remove this restriction.

Lack of Moderation

Due to a lack of moderation features, editing priviliges must be manually granted by an admin. I would love some help; let me know if you wish for these powers.

Confusing

Traditional wikis have a very intuitive model. I see a page, I can edit the page. Dantes Wiki is fundamentally complex given that every page is composed of individual pieces that each have their own timeline. This causes a challenge in making the site easy to use.

Performance

Since the server tailors the site content for each user, performance is much worse than a traditional wiki. The user’s specific viewing history needs to be considered when rendering an article or determining the list of articles they can access. This requires looking at a ton of database rows.

Also, instead of caching one article that can be served to every user, the Middle Earth wiki would need to store

(1 + 19) x (1 + 23 + 21 + 19) - 1 = 1279

versions of every article to cover every combination of progress through The Hobbit and The Lord of the Rings. (LOTR chapters are added together because we assume one book is read before going on to the next. 1 is added to the number of chapters to include zero progress. One is subtracted from the total because there is no content if the user has made zero progress with any books). If we add The Silmarillion and count it as 5 chapters, we would need to store up to 7679 versions of each article.

Caching would be more reasonable for series where all books follow previous books, like Dungeon Crawler Carl. This avoids the multiplicitive issue and would only require a number of versions equal to the total number of chapters.

Caching would be much worse for series with a flexible reading order and optional books, such as the works in Brandon Sanderson’s loosely-related Cosmere novels.

Fandom wikis are already lousy with ads, suggesting it’s not something people are willing to pay for. Therefore, a technology that increases hosting costs is likely not a wise business decision.

Alternatives

What are other ways to solve the problem addressed by Dantes Wiki?

• Look up and read a synopsis of previous books/chapters to refresh your memory
• Employ spoiler tags or similar features on existing wikis
• Ask a LLM and hope for the best
• Maybe someone has already made something like this. I don’t know; I did zero research.
• Talk to a friend or other human (last resort)

Future Work

It would be nice to:

• Remove the requirement for a user account to view the wiki
• Add attribution and edit logs
• Add some juice to the editing process to reduce confusion

Of course, a project like this could go on forever. For now, I’ve hit my timebox and will be turning my attention elsewhere.