 Thank you for inviting me to give the keynote here. I was trying to send it a spot where I don't have feedback. I thought about what the best talk I can give, and this is my one slide. Thank you very much. It's been a pleasure. So we've reached to the end of the day, and we've learned a lot about what happens when you have a bunch of people very committed to the cause of making developer lives easier. And this is what happens when we, that love, kind of shares return. But before I kind of really end this with you guys, and actually food is waiting. That's very hard to compete with that. So it's almost the end. I want to talk to you about the end of something else, and end of an era. I want to talk to you guys about the end of single-page apps. I understand this is a single-page JavaScript conference. And I understand the danger of the Shutter Island situation, where I can be. But I deeply believe that we should move on beyond single-page apps. And I'll tell you why. It's because of the end users, because of the people who use your app. They are not here. And I'm here to represent them. I'm a technologist by training. I got my CS degree from Columbia with writing the minimum amount of code necessary for me to actually get my degree. But one of the things I actually did a lot is that I really am passionate about product design. So I'm Chris C. I'm a technologist slash designer. And I'm passionate about making things so that people can have awesome software that they can learn how to use. But it's built correctly. But it's also built for the right reason. And when we talk about single-page apps, congratulations. It's automatic turn on. I feel like I'm in a carousel with horsies and music. I want to give a little brief history of single-page apps that we're going to talk about the end of something, how did it begin. And since we're at an Ember conference, let's talk about the Ember edition of this story. And it's hard to talk about single-page app without talk about apps. What is an app? And it's difficult in this day and age to talk about apps without talking about Apple. And don't worry, my computer didn't just restart. But it did happen that about 2008, this happened. Apple decided to embrace the internet or the web. It wasn't quite true before that. So this was like, hey, we understand that the web exists. And there's a thing called Safari. And it's pretty good. And WebKit's awesome and stuff like that. Let's go and make our calendar app, which is awesome, on the web. So this is Safari, MobileMe. And it does the thing that DesktopApp did. So if you go to DesktopApp and Snow Leopard or shortly before that, you get a very similar experience within Safari. And you log in using your .mac, MobileMe, .me, whatever they call it now, account. And then it's life's good. And what I'm happening is that, even though for the user, who is what I'm representing today, that they look the same and work the same and hopefully have the same calendar entries in them, if Sproutcore worked correctly, the data, I should say. There's Objective-C on that side. And there is Sproutcore and JavaScript. And it's totally different, like the implementation and developer experience is entirely different. And to make this happen, to make this web browser, to introduce this idea of a web-based single-page app to the world. And it's a big team, but this dude, right, it's hard at work. This is a classified picture. I smuggled an apple. Tom Dell hard at work. And Go Petino working on when he was working on an apple on a Sproutcore Go base. Actually, I lied. This is actually in 2012 when Tom is getting a manicure. It was a fun project. We were working with a firm called Ideo and they were happy that we did some awesome stuff and they treated us to a manicure pedicure. That was my first time. But apparently, look at his smile, definitely not his first time. So, all kidding aside, Tom, you know, sorry. I had this picture, I had to use it. So, Sproutcore and with the work that Tom and many, many other people worked on was the foundation with the collaboration between Tom and Yehuda. They decided to embrace the web, like instead of making it so that it replicates Objective-C and Cocoa and all this UI widget in Sproutcore. You know, let's make a Sproutcore too that acknowledges that HTML and the style, design styles is a thing. Can we use this online binding thing to make that work? That's kind of roughly the idea of what Sproutcore could do to us. And that was too confusing and there's some other things. So, it became amber. And more importantly, it became the Tomster amber. And this is just awesome. And right, in 2011 the first commit happened and, but a lot of people were like, hey, this is not the first single page JavaScript framework, there was one before that called Backwell. And then some other people from Mountain View was like, we actually made one called Angular before that and you should use that because we're Google. And then later on, in a couple years later, it's like, hey, Facebook, Instagram, we have other thing and we have another part in the Silicon Valley called React. The truth is that there are many other ones and these are the vintages if you're into wine of the types of frameworks per year, jQuery, XK, Sproutcore, Media, Polymer. I'm sure one will appear every year. And that's all good. And 2015 is the year of the 2.0. 2.0, everything, like just do everything one more time, make it better. And I'm not gonna go and discuss what the differences are but I would say what the similarities are. They're basically, there's some code and then some content and you kind of make an arrow between them. You make it work. As Tim Gunn said, make it work. Project one way. Not exactly the same reaction I expect when I'm actually in New York. Anyway, so single-page apps make it work and make it work we did. In every possible way, we made it work like 100 times and here's the great thing. The JavaScript and HTML5 is all the same but we made this 100 times. Like if we made this to-do list MVC app as like some sort of thing, I think it would be great. Now the great thing is the user experience between this to-do list browser-based app is actually quite superior to whatever happened before in the desktop app where you have to first find a meeting of them and decided that that means learning Haskell and French. So both of those things are actually kind of my life goals and the great thing about it is that it is better. Like I think people are much more used to be able to enter URL, go to where it is and the idea of the web style of UI and the way we use language and words to describe what you can do is see advancement over the desktop app and widgets and things and that's a departure not just because of the foundation between Sprout Core 2 and Sprout Core 2 and Ember but it's just like a new way of thinking about what user interfaces can be and much more kind of literate interfaces. Either way, if you look at this a little bit more, the cool thing about desktop apps was this ability that you share things using a file. So you have this to-do list and I want to share with someone and say, hey, my coach, life coach, everybody has one, does everybody have one? Oh okay, I do have one. I want to save as a file and share in Dropbox and that's one way to serialize the state of this app and share it. On the browser, this wasn't out of the way possible but I want to be able to get a link out of this and then share that link and it's possible today but if you dial back the history of single page that was not always possible. There was a lot of awesome domain name slash app going on and nothing changed and thanks to Ember Outer which introduced the concept of hey, this is a webpage, this is a document, this is a piece of content, people are going to share this and that's really important and today we sometimes forget that we could have gone the other way where you install an app and you can't really share it and because the web app doesn't have a file you can't even share that but with the URL, with these endpoints, these routes on your app being a full member of the web this really actually helped kind of bring that parity between what you can do for sharing. Sharing is okay, it's pacing a link and Slack does magic with it, sometimes asks for creepy things but sure, I'll let you access to all my Dropbox file ever. But when it comes to embedding, this is a little bit trickier so I'll tell you that when you go to school or you're writing a paper or something like that, you do this, you take something that you made or chart a table and you copy and you go to your thing and you paste it. That's embedding, right? People don't even think about it, we do this a hundred times a day, I wouldn't be able to make this deck without being do copy and paste a million times and it's so second nature that we just take it for granted. Oh, of course, you can embed things on the desktop app but if you're embedding this on your blog on some website or something and hopefully it's still functional after that, you have to find the embed button which is not always there, you need to copy and pick or make sure you got the whole thing, sometimes it helps with Slack, sometimes it doesn't and then you have to go and switch to an HTML editor or something, paste it in Beko and go to Preview Pay and make sure it did it correctly. This is just to get this list onto a page that's MyLifeGoes on the web, on WordPress, whatever. What are we doing here? Like why is this so easy on this side and so bad on the other side? We haven't solved this problem, the URL doesn't really help you. Okay, link to that and say, oh, you're the log, you don't count, do you have an embed code? And then it's like, oh my God, all I want to do is consolidate MyLifeGoes so I can have a meaning of life identify in front of me in the document. That's all I want, declare it to the world. So, look at this situation, right? Your user sees this thing, which looks exactly the same, maybe the fonts and nobody actually used Calibri, but you know whatever, the fonts are fine. I copy and paste two steps, how hard it'd be. And then on this thing, what very similar thing and on the user, what they need to do is either five steps where I have to deal with all these code, developer don't mind doing this because you don't do this, use embassy li, it's done for you, it's beautiful. But for your end user, they have to deal with this, they have to copy and paste that. And yet, for the desktop experiences handling content. So that's one thing that's still missing, right? Like we've kind of come pretty far emulating what you can do on the desktop, except the part that allows you to handle things as if they're content, not apps. Right, apps don't integrate without API, CLIs, MPMs, and you know whatever. Users don't think in terms of this acronym, nobody know what that is, but well, we'll solve our problem. Our workflow is great when a command line, right? But the user workflow is shit. Sorry. So this is emphatic. That's kind of what we want to be able to do is to replicate the two steps and allow the developers to solve the other 18 steps to make it work. That's our job as developers, to make things simpler so that the end user doesn't have to see the leaky abstraction and actually patch out the things that we have done yet. And that's essentially what I wanted to talk to you guys about today. It's something that I've been thinking about more than working on in many attempts like clowning on Mount Everest, you try multiple attempts at it to come up with something that will allow us to make this same as either an API or as a method. I don't know what it is yet. Like this is like before Ember was Ember for this idea. But what I want to be able to do concretely is to be able to copy and paste across multiple jobs with app. If I take a piece of content, I see in an invoice app like Freshbook and I have some other payment. I actually will copy that and paste it and have that invoice be imported. Because that's how I would do it if I have an Excel and then some other thing that I have to paste or save a file and share the file and email the file, whatever it might be. The reason why people are still doing that because they can't do it on the app that we're building for them. So they take a freaking screenshot. They export to PDF. Every single time that happened, put $20 in the tip jar of not having fulfill your application as developers to make the lives easy for people. This is not easy. And you know, Rob Jackson and Lauren helped me do a spike on kind of copy and paste and they convinced me that drag and drop is actually a special use case of copy and paste. If we can do that, you can certainly have the drag handler, create a stop, figure out what the idea is and actually do the thing. And obviously the easiest way of clicking pick, like you click this and you go in there and pick that, that is actually exactly the same problem. So let's call that card movement across multiple jobs with app. So cards are things that we visualize in our app as some components. You know, Mike is showing us how to use materialized CSS to actually make that look that way, but it only looks that way. It actually cannot move, right? It has this affordance or piece of card that you can move around, but it actually isn't that. It's just some diffs that get some outlets and you yield and then you render it. Within the developer workflow is certainly not something that's meaningful to an end user. So let's look at what a possibility of what this kind of drag and drop or click and pick could look like. Again, these are just kind of abstractions of what it looks like. So let's say I have a promo creation app, you know, instead of using Illustrator, I'm using some web tools. Some people are made with CSS and SVG and awesome. There's just great demo, like kind of applause in the room. And then on the other side, I'm using a team collaboration app, which another group of people, some of you out here has built. And so one of what I'm gonna introduce, this idea is that can we bring these two apps together? So one of them is an Ember app and you create this new promo using tools that you guys probably have learned today and kind of make it better and even more friendly and more faster with greater performance and developer thing. And that could be some sort of a card, a component and I would love to be able to kind of work with Jay on graffiti and make it work across different things and create this kind of cross-component framework to create this Visit Norway promo that will go on the website somewhere. And before it goes on, I wanna make sure that I'm able to check with my VPL marketing or whoever to make sure that's okay. So what I really wanna do is to bring this thing over to the other side. So I wanna copy the card and somehow take a snapshot of the card, kind of take a screenshot but preserving all this life cycle and the app-ness and the fact that it's alive. And then we essentially say, oh, okay, let me snapshot the HTML, maybe the JSON, maybe take a screenshot using phantom and get that kind of image in there and then drag it into a React app. A React app that will accept this card and say, paste this card in and then it will actually either boot it up, display the JPEG if it can and whatever and whatnot. So all this really means is that I now have the ability to go back and say, you know what? I actually think that this is not the right image to use but because I have access to the JSON that was snapshotted, the actual application so I say, which is, I'll talk a little bit more about how that would work, I can then from within this Slack-like app boot up the iFrame of your app and say, I know, it's like sending a photo to another iPhone photo editing app where I want to boot up this JSON to your modal which you give me to a component wrapped in an iFrame so you can load your own libraries and stuff like that and I want to be able to edit this, right? And have that be a suggestion coming through all by the way the VP raised the price because why would you charge 250 for a round trip to Norway? That's too good of a deal. So essentially what I just showed there is basically three things working together. One is that we will inject some common JavaScript, some sort of shim on the environment to create essentially the ability to create this kind of action and then we're gonna figure out what are the parts of the app that are container of cards and that accepting cards and make them kind of glue together and finally the card itself and cards themselves in at least my version of it are more than just component, they're actually full apps. In fact, the little funny story is that I was trying to do this in my previous job, I was the head of R&D at MHG Labs, the little kind of my Ember fame is that if you go to ember.js.com the first logo of who is using Ember.js is MHG Labs and that's an organization within McGraw Hill that started. And we were one of the very early support of Ember and kind of lived through Ember data, zero point, I won't say, and I've been trying to do this kind of reusable component thing and the reason why Ember CLI kind of existed is because I asked the app labs and at the time it was, I think, Luke and Steph to like help me build this kind of reusable card where each card is his own project and then you bring those project together. Huh? Right and there was making a lot of apps so Steph said, let me just automate this part of making a lot of these small apps and that became Ember App Kit and that became Ember CLI. So it's a really good example of when we try to solve high problems, we get tools along the way and we share with the team. So a little bit of my ghost star on having to move this forward. I didn't write it on a code, which makes me even awesome. So the cards itself are actually fully formed apps and it could reuse components within this code base and export itself that way. But let's just look at what that looks like from a structural point of view, which means I have these cards inside container which allows me to drag and drop. A lot of you guys build this application to have this architecture. It's just that we want to do it in a way that has to standard so you can drag and drop between multiple apps that use the same standard. And what happens then when you bring this thing inwards to essentially you're traversing this kind of hierarchy, the card tells a container I want to become something. So serialize the state and then the environment captures that and then essentially push it to the other one. So a little bit more specific about and that's what CardSci is doing is to look at kind of what happens in this workflow. First your app renders and it's a lifecycle and then you snapshot your data that you can read in the future when it was giving back to you, when you kind of re-hybernate and teleport to the other places. You want to know, okay, what's my DNA? And then there's a push and pop going on. That's kind of how clipboard on copying pays work. So you put it something and you get it back on. And then you restore from that snapshot, you essentially boot up your Ember app with that snapshot and say, hey, don't use the URL on the route because I'm within the larger app in this Slack-like app. But I've got all the data necessary to repopulate my state so that I can go and show, visit Norway at the right price, possibly even having that app later on go to server and professionally this data if that has changed since the snapshot. So the specifics of this orchestration, we have done multiple attempts of this and there are a bit of different projects, some of them open source, I've used this pattern, but they're all based on this idea of asynchronous messaging where the message just gets passed back and forth between this layer so that by the time it reaches the destination, you have all the bits necessary to reconstruct your reality. So in a nutshell, what card stack, which is a name I invented so that I can give a name to something, it's amazing how important is to have good names, right? And so it's a stack that allows you to make things work exactly what you expect as cards that can move. And what is interesting about cards, it's that it has this like four characteristic that we have to maintain, it almost become an acceptance test of whether a card is a card. One is that it should be renderable into some sort of size, a big card, a small card, zoomed in full screen view, thumbnail and it should change this template and that will kind of map very nicely to the different ways we can kind of have different types of views and then the modes in there within the mockup. But it also is like an app because I can say boot yourself up or I can say, oh, this is a video card, playback, stop playback. So it acts like a widget with something's kind of reacting to events that's going on in the outer environment. But I think this is the most important when we're talking about Snapshot is that it can serialize the state like Microsoft Excel saving itself to a file. It can then say I would just boot up back from that because once it serializes the state then that thing becomes mobile because you can then move that piece of bit as a way to kind of reconstitute its component. So adding this idea of restoring from it and not relying on an overall app to kind of manage your underlying state, you can actually say, hey, for this little card thing which is more than component, I have a serialized state that makes it act like a file. And finally, you can ask the card to say, hey, you're an invoice card from like Western Hotel. What is the final price? I need to reimburse you for. This is currently done using restful API but you can certainly interrogate the boundary and send message back and forward to this, either an iframe or something more, less sandboxy but similar async messaging abstraction and say, give me the value that I would expect using some sort of schema.org way of courting that. So it actually acts like an API that's happening in your browser, happening at the glass, not necessarily requiring you to fetch it from the API in the back, right? So the card boundary here is that the cards exist in the middle and then through the implementation of HTML and JavaScript and JSON, it creates a reality. And finally, Oasis was something that was about the sync passing nature. It turns out the HTML5 app, as spec has a really good way of dealing with passing data between running apps, iframes, it's called message channel. But it doesn't work on every browser. So when I approach Yahoo and Tom and say, I wanna do this card thing, help me out there and they say, well, the first thing you need to do is polyfill message channel for all the other things. So Oasis, js.io, I believe, is actually in the tilde org in GitHub, is that. But we learned that once we have message passing, we wanna use it everywhere, whether it's inline iframe or not iframe. So that was one of the inspiration of how that done. So going back to this picture of CardStack being that kind of message channel to coordinate between two different not iframes but two different websites, different domains, you need a little bit more magic to make it happen because origin work against you. But if you have an environment that's running on some sort of origin, we can bridge that. But what's interesting about this is that Windows has been doing this for a long time. They just call it different things, right? Instead of card, it's an object, insert object. Everybody's familiar with that when you're writing a paper. It's like, I want a clipart. Don't use a clipart. Instead of a container, it's a document or maybe a spreadsheet and there's a different type of a presentation that is the thing that contains the thing that you're pasting in. And then instead of an environment, this kind of ambient JavaScript running globally across things and hopefully not doing evil things, it's your clipboard. But with that, you can actually create the same workflow where you render your thing as either a JPEG or also a table and also an Excel object. So it depends on what you're pasting into. Maybe a Photoshop doesn't understand the Excel stuff, so it just paste the JPEG in. But if you're pasting into another Microsoft Office application, it would take the highest possible rendered version. It's like, oh, I would like to consume the best thing. So it can imagine an SVG export and a PNG and a animating gift or something like that and being rendered and snapped to that way and then let the consuming container decide which one to pull it in. And then obviously pushing and popping into the clipboard is a feature that's been there for a long time. Pushing a multiple things to the clipboard is something that fortunately is no longer there. So that's the UX thing. But let us pause for a second and say, why am I talking about Windows so much? Because this is a group of people, okay, Mac as well. Windows and Mac, these are creation tools. People make livings on them. They create new meaning. They curate content. They write papers. They write journal. They use these tools, not like an iPad where you can play with things, you can actually make things by using Windows and Mac. Why? Because you have tools that gives you the power to create new stuff. And to do that, you need to reuse and compose and assemble and that's where copy and paste come from. If we keep letting our app be the only universe the user can and then I'll give some API if I find you pity enough to be able to tap into my data that is yours, that's a problem. And in fact, I would actually think that for all the good work that Bill Gates has done in Theranthropy, he actually made his money from Microsoft Office and Microsoft Office made his money because in 2000, no, not 2000, 1990, I can't pronounce the century correctly. Microsoft introduced something called Olay. And it's not Spanish for anything. It stands for object linking and embedding. And linking, we talked about sharing a URL and URLs and embedding is something we do like badly. But Microsoft recognized that E is very, very important so they created something. And with Olay came something called Olay Compound Document which allows you to take different application state and mix it together and have each application that can render an equation, render an equation when they encounter that within your Word document. So to most users that's .doc.xls.ppd. Those file format is the results of the work of thinking about what productivity means, what making something means and how do you want to turn an operating system to go make that happen. So Apple got jealous so created something called OpenDoc about a year later. OpenDoc didn't really succeed but if you look at the intention, it was actually kind of like, let's one up better on Olay, let's improve on that concept. So from Wikipedia, the description of OpenDoc, they said this, the basic idea of OpenDoc is to create small reusable components responsible for specific tasks with a framework in which these components could run together in a document form like a storing data created by each component even if they're from different vendors in this way users, not developers, could build up the documents from parts. That is 1992. Some of you guys are not even born yet, right? Like, I mean, this is a long time ago but the second thing they do is that since there's no main application only the visible interfaces document itself, the system is known as document oriented. So they want the document, not the app, the document to be what you're creating. But a year later, this happened. No, let's go back first. So it turns out there was actually a lineage to that concept of the document being the experience and the app kind of hiding between that and this hypercard. And it's amazing, Apple Script came from it, it's, you have documented a link together, it's like predated, it's the web by a lot. And about two weeks ago, I gave a meetup talk about something else and someone from the audience said, Chris, I would like to show you something. And he showed me this. An original copy of the brochure for a hypercard from Apple. Like, this is like worth money, right? Like, that is like an artifact that people would just pay money for. But this is, you know, when I read through it, it's like, oh my God, this is what we haven't done yet as an industry. And this is like freaking 30 years later, right? That we still haven't fulfilled the vision of what hypercard was able to do. And I think part of it is because hypercard has this hypertexting and OpenDoc has this like document created, building up on component things. But then in 1993, oops, sorry. One year later, the web was born. It's crappy looking compared to everything that we've seen before. It's incredibly limited. It can't do anything that the Olay compound document or OpenDoc is, but it was open and it has this amazing ability of hypertext and all these kind of good qualities that OpenWeb gives. But it basically back bashed it down to the dark ages in terms of what the user can do. Like on the desktop, amazing thing and it took literally probably between then and maybe jQuery for the web to cat up to what the native app can do at that time in 1993 or four. So we kind of went on this web path with Perl and PHPs and server-sized stuff and stitching together different deltas in a DOM. But the good news is that if you fast forward 22 years and it is 20 freaking two years since Mosaic was launched by Mark Andreessen and then launched officially, we have this, we have everything. I don't mean we have everything, we have the debate and try to see who's gonna win at the end. But I mean we have the primitive of the system that was kind of the ambition of all this off. We have a universal pervasive programming language and runtime, Java tried to fail, .NET tried failed. This is now here, right? What we can do with Java is amazing. We've got a practical, practical, universal data interchange format, JSON API, JSON, JSON LD, JSON will all the kind of crap, right? But it's awesome because people actually use them unlike XML and EDI and other things that people don't really wanna touch unless you've paid a lot of money to maintain legacy code and you tell yourself, saying, you know, it's gonna end, it doesn't. And finally we have the most powerful rendering instruction set. I saw the Mixmo, some famous using WebGL, mind blown, the degree of innovation and speed of what you can do inside web browser, inside web browser, inside nw.js, inside desktop app, inside, we just did an app for one of our companies on the LG Smart TV Ultra HD screen, totally mind blowing, the liquid fires running on the HD screen on like a 4K image. This just like blows my mind. And to me, being early to Ember, I really feel that we need to kind of reflect upon ourselves if you have everything that anybody has ever dreamed of as far as development tools and ecosystem and community and support and all this stuff like that, what are you gonna build for your users? We know we're gonna build for ourselves. We're gonna build apps because that's what we do. App is king and we have the greatest developer centric experience you can do. Like everything gets better every day. But end users, actually, cross that out. Let's call them creators. Because they're not really end user of your app. They're created on their own destiny. They're created on what they're passionate about. They use the tools you give them to make more meaning than you can do. For them, the content is king. They wanna make this or they make a, one that has synced to music, some that has video, and stuff like that, that's what they wanna make. It could be a business person making a model using D3 underneath, but creating projection and sharing with other people and investors. Now they can't do that, so they paste it into PowerPoint and share it as an image by taking a screenshot of your D3 app. We should be embarrassed about that. We should give them an app that you, that card that can embed within another experience like a Slack or some enterprise version of Slack and then have them be able to see the snapshot data which is when you send it and then click, I would like to see the latest data on this and actually go and use Ember data or something else, load the latest data in and have that same underlying rendering code show the latest data from the end user. That is progress and that is not possible today with all the things that you guys have done because we lack the abstraction, we lack maybe the history of saying, hey, what's the next thing once you have your app working? They wanna make content, the content need to be alive. It needs to be rendered in real time with live data if that makes sense, with snapshot data with that makes sense. And in 2015, what we really need to do is to have the Ember community show this card-based approach some love, right? Let's say, what does it mean to allow us to move beyond single-page apps, right? Which for those who has been in the DOS era, it's basically WordPress and Lotus 123, right? It takes up the whole screen, a single page or single screen. It takes over everything, it has its own conventions and I am on my own domain. You can copy and paste maybe within my little word processor but not beyond and not outside. That I think is like 1998, 1988, right? That's way back. So the reality is that users are using multiple apps. So they're making, they're using single-page apps as plural and they're using multiple at a time. So what we really wanna do is not really the end of single-page app is the beginning of allowing multiple apps on a single page and that could be your app, it could be a dedicated portal type of app where bring things together, Slack is kind of fulfilling that promise and maybe they're not apps, maybe they have this idea of being, look like a file, maybe an API into a receipt system. So the JavaScript that's running your browser is an agent that moves around and it can be mobility and whether it's drag and drop or automatic kind of synchronization, it's multiple cards on a single page and there are many types of cards that you can build, an account could be a card, a payment could be an invoice, certainly it can be a card. A receipt can be tied to an invoice or take the data and pre-fill everything so that it's all integrated in the glass, in your browser or in a backend is running node doing the same thing, not running the DOM part, but on the logic of it. And you can certainly have containers that would allow you to build an open source version of Slack, it does it way better than Slack or maybe Slack embraces this and actually make them the new future of what communication with live links and not screenshot look like without asking you for API keys for every single thing that you do and have keys to your MPy. So we are here because Apple decided that this little area is where your app will live. It will be next to other thousands and millions of other apps on the app screen. But if you think about what Apple did when they were thinking about OpenDoc, which by the way, I have to correct this, it's this Apple that wrote this. And this idea of a reusable component not for developer for end users studying and build up this document, it's so compelling that I'm just gonna say, you know what, I'm just gonna make that the cost that statement. Sorry, I'm reusing things. I forked in and I checked it in. So that, yeah, that's it. Cost stack, I wanna fulfill the vision that we broke apart from a little bit because Mosaic gave us this big network possibility to reduce the end user capability. But with all the work that you guys have done and all the talks you've heard today, I think it's finally possible to go and basically pick up where OpenDoc or even OLA has left off and see we can work together, not just in a community in sharing code, but allowing the thing that our app be shareable among the end user using nothing but copy and paste. So if you guys are interested, I'm looking for people to work with me on the Core Dev. And it's been a great privilege in the work that I've done to be able to work with Yehuda and Tom in the beginning of Ember and also the beginning of the concept of Cards when I was the head R and D of a previous company. And I've also worked with Luke and Steph and more recently Lauren and Robert on different projects, approaching Cards kind of in like specific silos and slices of opportunity and come up with some libraries like Oasis and Conducted along the way. But I think this deserves its own project. I think this deserves its own thing. So I actually just filed a 5.1c3 for CardStack which is called the CardStack Foundation. I don't think this is a company. I think this is something that deserves to be a new type of community where the end users, the creators, the people who use your app and make meaning are part of that process and not just observing what we do from the outside. And but there's a more short-term thing. Since I've been publishing this talk on CardStack at IO and I've talked about the philosophy at all and the technology, you can go to CardStack at IO and kind of catch up on what I've said. They're a little bit more detailed and about kind of Card UI as a trend and how that relates to this. I'm getting a lot of requests from companies who want to use this idea all in part. So if you guys are available for project work, come talk to me. There are plenty of people looking for help in kind of taking baby steps toward this approach. And concurrently, while I've been working on this foundation since last, I think about April last year, at the time where my baby boy was born, I was like, I need to do something meaningful in my life. And it's beyond just learning Haskell in French. And it's really to start this. And I also realized that if people are gonna be creating cards and you need to become to say that if someone were to use your card. So I was thinking about media licensing and licensing these kind of apps and all the content contained within these apps, these cards in a way. And that's what I'm working on with a bunch of folks. Hassan and Will is here and also Yaplabs helping us create something called monograph. It's using the blockchain to register your work, which could be a card. And then right now it's up with images and art and then allow use to trace. I use this thing in other things. So how much royalty do I owe you if I'm getting a big payday right now because NBC picked up my show, right? So be able to do that in an automated way. I felt like it was important and for profit correspond to this. So if you guys are interested in blockchains and geeking out, talk to us and Hassan with the thing, with the Ember shirt, which again is not a very distinguishing feature in a place like this. So proudly we have reached the end. And thank you so much for everything with your attention. Thank you.