 Because I'm about to do that same thing, I rename the talk, what not to do. But no, we're actually going to talk about Pub-Pub and why we don't implement the annotation standard and why we'd like to and invite you to tell us why we're wrong and help convince us as a model argument for other larger players who I think are more important than us. So with that in mind, just a brief introduction to Pub-Pub. We are an open source end-to-end scholarly publishing platform. We work mostly with academic content. We're turnkey and collaborative in real time and automated and end-to-end and all of these things. Basically, you do everything from submission to editing and collaborative editing and drafting in real time, multimedia, version control, all the way through to actually publishing and designing your site and depositing. Of course, we support annotations. It's a huge part of the platform. And in fact, there's hundreds of users now, 400 plus communities who use Pub-Pub. And they use annotations in really, really innovative and interesting ways, like this open review of a book that happened late last year and earlier this year, got thousands of comments actually on the source material from the community that improved the book that's going to be coming out later this year. So that's really cool. And also, we're part of this larger infrastructure at MIT called the Knowledge Futures Group, which is devoted to building open, transparent, and importantly, community and institution-owned knowledge infrastructure, basically. And so that makes it really, really awkward that we don't actually adopt the web annotation standard. Like I said, we want to. We think we're a great candidate. And we've had multiple opportunities to adopt it. We've actually rebuilt the discussion platform like three different times internally. We're rebuilding it a fourth time. And each time, we've decided not to adopt the standard. And so this is telling you why is, again, like a friendly people who actually really want to adopt it, but to tell you how it just never makes it to the top of our roadmap. So there's three basic reasons that we keep coming back to. The first one is that the definition of annotation for us is still a little bit hazy. Like there's a weird line for us between what an annotation in the context of a peer review is versus what an annotation in the context of a comment is versus something else. This example here is a track change annotation. We probably would build it into our annotation system, but how much should we expose that to other people? Should we make exceptions for it? And so that's a question that comes up. And there's also a language problem. We don't call them annotations on our platform. We call them discussions. And so if we were to adopt it and release it, how do we tell our users that this is what we're doing and that we're connecting it to this larger thing that everybody else calls by a different word? So that's one thing that are all open questions for us that we hope that you can help us and others facing this problem address. The second one, I've even learned that this conference about tools that can help us with this, but we've rebuilt our system three times. We've updated references to annotations three times. We're a little bit nervous about what happens if we have to now make these updates across syndicated caches. That just seems like a really thorny problem. It looks like the community is solving that, which is really nice, but that continues to be something. Then the third and I think most important reason is that this has never happened. We've never had a user request for interoperability, which is a huge shame, because that's the main benefit of it. But if you're a product manager and you're prioritizing features and you look at the web annotation standard and everybody goes, here are these great things you can do with interoperability and nobody's ever asked for that, that's a big problem. What I can share with you is a couple reasons why we think that may be the case. The first one is that Pub-Pub is built for communities. And it's built for people who have very specific behaviors and norms. And it's built for people who have very specific brands. And what we find basically is that culture and brand don't interoperate very well. Someone on rap genius or now just genius annotating something is going to do it very differently than someone who's annotating something in a scholarly book about something. They're just going to use different language and context. It's kind of awkward in that scenario. And then I think the other thing that we've learned about it, and again Benjamin addressed this a little bit and I think it's important to note that, is that interaction and user interface are super tightly coupled. And one of the main uses of annotation on our platform is actually people embedding these discussion prompts in line into the document. And then taking those annotations and putting them back and fleshing out the document based on that, that this is an awesome article from a group called Cursor based in Heidelberg that basically builds all of their publications in that way where they start with prompts and they have the community sort of build the article around it. That's obviously going to be very awkward in an interoperable context to see this weird incomplete thread that doesn't make a lot of sense and only makes sense in context of a document that didn't exist when the annotation started. So those are the things for us. And so I think the question that we're asking and that we love answers to is this one very roughly formulated. I did it literally after I heard what Benjamin said and wanted to give you something a little more useful than just to complain about the standard. But basically, we need to be able to make the argument for interoperability to ourselves and to users in a way where we start hearing from users that they really want it. And that may mean us dipping our toes in it or it may mean that we have to keep pointing our communities in directions where we say, look, what we could do if this was interesting to you is this interesting to you. And so in conclusion, what I'm going to ask you to do is, no, I'm just kidding. What I'm going to ask you to do is seriously treat this as an earnest invitation to help us make the argument and in so doing help others facing similar decision trees, others who are way more important than us, I think, fully acknowledge the standard is new. It's adopting. It's growing. It's evolving to address a lot of these concerns. We also acknowledge that we're probably curmudgeons who don't fully understand the value. But we know we're not alone in that. And so use this opportunity to do that. You can annotate this presentation at that bit.ly link and tell us why we're wrong. You can come up to me later and talk about it. And with that, thank you so much. Time for one quick question. I think part of the value might be what were people doing for Pubhub before Pubhub existed? And the question, the answer, might be they weren't able to do it, right? Until you enable some functionality, people don't realize that they wanted. And maybe if there could be some collaboration between Hypothesis and Pubhub so that you both support the open standard. Totally. We'd like to do it. It's just a question of, yeah, do we, where is the value that allows us to justify it, especially on a very small team? OK, what tools could we build that build off of your thing that would help you justify that? Yeah, that's a great question. I think maybe that's another question. What third-party things can we build for you that help you justify that? Awesome, yeah, that's fine. Thank you.