What I'm demonstrating

• E-books can work offline - important for flights, holidays, trains etc
• No server trickery needed - both publications and reader can be hosted statically
• Speed & simplicity - no heavy framework or render-blocking JavaScript in the way of content.
• It's just the web - publications are just html, so can use css, images, video, audio, svg… anything the web can use. However, script is blocked in the e-book reader, as running arbitrary script would be risky.
• Links - Linking & navigation works as expected, even within imported e-books provided two users have added the same e-book to the reader. Bookmarks can be used as, well, bookmarks. Fancy that.
• Archive obfuscation - The archive has an empty byte added to the start so it can't be read in a regular unarchiver. I don't personally care for this, but if this is what publishers want, it is possible. I guess it worked for WOFF.

What I'm not demonstrating

• UI design - I mean… I just can't.
• Best-practice maintainable code - I hacked it together on a plane for fun.

How service workers are used

• Request interception and caching - makes the whole thing work offline and produces urls and normal navigation patterns in the e-book reader.
• Archive building on the fly - once streams land, the archive format can be generated and read in a more memory efficient way. Although the archive could be generated by a build system, the client side build allows dynamic building of the archive based on user options.

Publication format

They're just web pages, but with the following requirements:

• Relative URLs - so they can be opened anywhere.
• A manifest file - with the name of the book and the urls it requires.

That's it!