Hyperbook, aka e-Vellum. Inspired during - not after, that's not how my mind works - a long read tonight about Ted Nelson's vision of hypertext, minus any of the transclusion, a strange variant of the same commercialized bullshit he otherwise so vehemently rails against (and therefore would tickle companies like Microsoft pink if it were to ever come true).
Internet-connected paper inside a traditional-looking book cover; the cover can have a paper look and feel with thin/flexible silicon undercoating housing the OS, CPU, RAM, wifi adapter, and any other bells and whistles needed to make and keep the book interconnected. Connection is private (tunneled via VPN, proxied?) because I'm no disciple of Mark Zuckerburg's prying-for-profit nor any fan of Window's 10 advanced spying features, nor am I a disciple of today's more nefarious hackers' seemingly infinite, larcenous reach into every facet of our online lives.
Book can be turned on and off just like any computer; off switch completely disconnects. Pages are made out of about the same stuff as US cash; perhaps thinner for a more lightweight experience or perhaps a bit thicker for increased durability. Use of paper threads will vastly increase, irregardless of final paper weight, to strengthen paper and provide on-page interconnectivity, depending on which color thread is being used (a simple visualization to decide: blue threads are for hyperlinks; red threads are for page strength and reinforcement).
It doesn't matter how many pages the book has because as each page is finished you can either stream the next one from its Web resource or else load it straight from on-board cache (this is where the otherwise intrusive and quite dangerous pre-fetch feature that's been around for years, that Mozilla is now turning on by default in Firefox, would finally come in handy, provided the web resource you request your pages from is secure). The book can have one page, a hundred or a thousand. For simplicity and ease of use and recognition it might be nice to standardize around a set number: 300 pops into my head as one possible water line.
The cover and pages would be treated with a ScotchGuard-like finish; the cover would have a thin, flexible, damage-resistant non-conductive metal or metal-like lining to further protect the book.
The advantage of this design is it gives you the old-fashioned book in it's most familiar shape and form while eliminating the need for physical libraries and enabling inline linking on physical book pages. It can also support PDF and similar technologies via its use of threads as links. It's The Book, the book that contains all books while simultaneously containing nothing. When you unwrap it, you pull the plastic shrink wrap off, turn it on, and there's sample books to get you started, but you can delete those once you're ready to get your own books, leaving The Book literally empty except for the first page.
That first page will give you a simple UI to download books and PDFs from the Web and also provide a link to another page, which will hold links to all the books you've downloaded for offline reading, along with links to any books you're still reading via built-in streaming technology. When you look for stuff to read, you'll have the choice to either stream or download your selections. Cache by default/necessity will be huge, because you might want to store a lot of books for offline reading, re-reading or eventual sharing.
The tricky parts are always a) getting the text of any book you stream or download to "print" on paper (I have no idea how to do this - yet - but maybe on my next 3-mile walk or another 300 3-mile walks from now, I'll finally figure that out - I already know it's got something to do with light) and b) getting links on the paper to work - and this book will need working links.
Ideally - say for the PDF-reading portion of it - the book will have a program that scans your streams and downloads in realtime for any links in the HTML; the links will act as pointers for the code to send a signal (is this an electro-magnetic pulse?) to, say, the blue threads in the paper, which will insert the links into the appropriate places in the text. Imagine the blue threads run as many lines to a page as there are lines of words in your chosen book or PDF; then the program simply has to decide where in each blue line the linked word will appear once "printed" and insert the link in exactly that spot.
Basically, including links in the book are about setting a line-height to ensure they become clickable where they should, so it's a problem that's more easily solved than the dilemma of how to print streamed or downloaded text on paper in the first place, which is sort of a Battle Royale if ever there was one. Forget breaking into websites, oh very l33t onez; chances are that will never be as hard as making a single interconnected paper-paged book (even just one prototype!) that actually works. You'd think half these coders would have some can-do and work on something like this rather than steal your credit card info, which has got to be a snore after the 30th victim or so.
If I were Steve Jobs up on the stage (whose amazing marketing skills I will forever admire) I'd sell the book like this: "E-Vellum is the book to end all books. It is ... The Book" *whips it out from behind to thunderous applause/trillions of camera flashes*. "Simple, lightweight, portable, it goes where you want it, feels like what you're used to, and does what you thought it never could do. *dramatic pause* Watch." *some onscreen demos* I'd also give it a better name than e-Vellum (*eyeroll* - or is that iRoll?). And then the audience would throw confetti and I'd become an overnight zillionaire and finally buy Facebook simply so I can shut it down. Thanks for the memories - and maybe for some of those memes - Zuck.
Pushing that daydream aside - because confetti is messy, someone will have to clean it up and I'm not exactly Steve Jobs - I do think if some of the kinks could be worked out - at least on paper and/or in theory - that this might make a great Kickstarter project.