← All Talks
Lightning Talk Development and Protocol

ATProto design philosophy behind BookHive

Nicholas Perez · @nickthesick.com
Sunday, March 29, 2026
4:00 PM – 4:10 PM PT
Performance Theatre
Available in-person & via livestream — Stream 2 (Performance Theatre)

This talk will go into depth on the design philosophy that underpins my project BookHive, a book tracking application comparable to Goodreads. The main point is a call to action that we should give users' agency over their data, by aiming to make the data that we store in their PDS as interoperable as possible. This means more than just recording IDs in their PDS, actually giving them the data that you use to construct your application. https://nick-the-sick.pckt.blog/the-design-philosophy-of-bookhive-s23cz85

Hi. Pleasure to be here. So yeah, like. So yeah, this this talk is going to be about the design philosophy behind bookhive. So it's not actually like design in terms of like UI design, although I did do a redesign last week, released it, all that. But so you can you can enjoy the website now, but uh this is going to be more about the philosophical aspects of this. So I think that what we have here with AT Protocol is really a trend reversal. Sorry. We have a trend reversal in terms of uh the web started as being open, and then we slowly saw this being clawed back by these systems, um, these large social networks.

You know, there was uh things like um Twitter used to have an open API, Reddit used to have an open API, they slowly crawled that back from us. And I think that what we have with AT Protocol is is um we're we're we're right now running into uh user agency at an all-time low. So what this means is that like um we're we're we're constantly being forced to do these Windows updates. We've all been sunsetted by uh some sort of application and just essentially screwed over. Um we have no other recourse. These APIs are closing down, and we increasingly with AI now, data is seen as a moat, so there's only more incentive and pressure to close down these APIs.

Whereas AT Protocol, as we all know, is is meant to be open. So when the web first came out, there was this idea of a user agent that I think that we just kind of forgot about. Like it used to be that the the idea of a user agent was meant to be that when you're looking at a document or something, you might want have some preferences. We're all different people, we all have different preferences. Why are we all looking at the exact same interface? It doesn't make sense. You know, something as simple as the font size or your font family.

So the idea of this user agent largely just didn't pan out. But we're all trying to do something better, and I think that's what AT Protocol is all about. So my little slice of this is working on something called Bookhive. It's an alternative to Goodreads. Um you can track your books, organize shelves, and all of that data is stored in the user's PDS. So when I was designing what to store in for bookhive, when you could imagine this sort of system, all that it really needs is uh some identifier for a book, whether the person has actually read the book or not, when do they do it.

That's all that you really need to store to the user system. So you could literally just store this, and that would be enough to render the bookhive UI. But what does this give the user? It's just some random identifier, it's absolutely useless to them. They can't do anything with this data. So this is what I actually store. I give the people their book. They they want to know the book's title, the author, the actual cover art. I actually upload it to your PDS as a blob, and all these other data. There's also particularly with books, there's no real standard identifier for a book.

It's an open problem. Everybody, every data set has this different identifier for a book. Um so I give you everything that I know about the book. Anything that I have, I tried to give it to the user. It's all about giving the user what's maximally useful to them. So we have an opportunity to build social software where data actually belongs to people. Let's not waste it by giving people just these random identifiers that they can't do anything with. The PDS is not just a database. So you normally think of a database as trying to store like the minimal representation.

It's not about efficiency, it's about agency. So there's a little bit of a thought experiment that you can take with this sort of thing. If bookhive went down, which it does all the time, it runs in my living room. Is the data in your PDS actually useful to you? And I'll get back to that as well because I forgot to reorder these slides. So one way that I handle this is with a central data store. So what this means that's on protocol. So normally centralization is a bad thing. But in this case, what I'm doing is I I did as I said before, and I give each user their data in their PDS.

But I also have this one little URI that it uploads.

Not everything that you need to to store into the user's uh PDS. They might not care about a book description or I can't make an update to a book if there's ever some some sort of a amendment. But we can everybody can reference this and we can all talk about the same book using these URIs. And there's an interesting opportunity here for doing things like backlinks. Honestly, I haven't really explored this that much. It's only been out for a week now. So here's some proof that this user agency and that the data is actually useful. Um Popfeed.

Popfeed actually is able to interoperate with uh BookHive. They're able to display all of the book data because they have all of the book data. Another example is um book explorer, which was made by Tice. Tice actually um he wanted to be able to manage his books in a different um application. So he he made this table view, and you can completely use a different front end. It doesn't have to be bookhive. This is real interop. The only reason that all of this works is about is because bookhive stores the maximally useful data in service of the user.

So there's some takeaways here for for builders since everybody here is uh related on the building side. Store what's useful to the user, not just what's useful to you. You may only need those identifiers, but give the people their data. It's theirs. Wherever possible, try to use standard identifiers. And I'm actually out of data, out of time.

All right. Empower users, be their agents, open data, open source. Thank you very much. Thank you so much, Nick. Unfortunately, we do not have time for another for any questions, but Oh, sorry, yes. Actually, we have time for one question. You're right. Yes, in total it is 10 minutes. Um, does anybody have a question? Yes, let me bring this to you. I don't know if it's much of a question, but like my comments said this to you before. I like that this is a good low-hanging fruit uh for people to migrate from Goodreads away. Uh that's what I tell my friends.

It's like this is one of these apps that you can already use. Whereas with social media, it's a little more difficult if people like, oh, private groups and stuff. It's like, well, it's not working with app proto, but for Goodreads, I think as an alternative, it's really great. Um with the data structures that you have like as to whole on your PDS, like I guess we could just clone it down, right? Do you offer like the database itself too uh for download? Yes. Amazing. Thank you. Great. Thank you so much, Nick.