 Hello, everyone. Good to be here. So I'm Vaughn McKenzie. I'm from Jack. If anyone knows us, we are in the Music and Media space. The name of the presentation today is a new engine to power the web of content. And I just really wanted to start first by kind of acknowledging that in terms of music, there are a lot of music blockchain startups in the space. I thought it would be a good idea really to just kind of recap why we're in the space and why we really think that music and blockchain really do make sense. And yeah, the clicker works. So first of all, what is the problem? And I think that the way that most people, as consumers, experience music is that we just think of a song as an MP3. So when we play a song or we hear a song playing, we just think, that's a song. I'll play the song. That's all I need to worry about. The problem with music is it's very hard to figure out who to pay. And that's because a song is actually kind of complex. So let's say that a few people get in the studio and they start working on some music. You actually are creating a very complex ownership structure. The reason why is because a song, which actually is not represented in the music industry, don't really think of songs. They have completely other terms to describe things. Songs are just for consumers. But you have this thing called a recording. There's a copyright in there. And that copyright is normally created when an artist makes a recording. So if I go in the studio and I record something, I create this thing called a recording. And that is normally owned by a label. So labels own recordings. And in compositions, you can think about recordings being the implementation of a composition. So a composition or, as it's called in the US, a work is really just the nuts and bolts, the mechanics of how this song was made, the lyrics, the melodies, and so on. And that's made by writers. So producers who make the instrumentals or obviously the people who just write the lyrics. And that's normally owned or represented by publishers. And every single time a new publisher or writer comes onto a track, so you can have five producers, ten producers, five samples, all of those things have their own ownership structure. These are like micro-businesses. Every single one of these, they're argued by lawyers and figured out by managers and accountants to try and create this structure. And nobody has a real picture of how this works. Now, this is one song. On Spotify, there are over 30 million songs. So you can imagine how complex that is to try and keep track of. And the way we keep track of that is with proprietary databases. Now, this tries to explain how when we think about how music goes from people in the studio to creating it all the way through to a consumer listening to on the other side, it's actually quite complex. Because the song itself is a collaboration. It's then pushed in the metadata and the music becomes separate, as they always are. And then they move down the supply chain in different ways. Now, on the work side, there is a standard identifier called an ISWC. And on the recording side, it's a standard identifier called an ISRC. And people like to apply these things willy-nilly. So they just applied all over the place. And they don't really map down to the actual unit we're trying to describe. And as we want to keep sync between these databases, we create these exports and we just send them around. So there's these flat files flying all around the industry. And this is what we're kind of using to sync, right? So in order to figure out who owns what, we're just using these flat files. Now, as we were saying before, the problem here is that we end up with complete information asymmetry. One person saying one thing, another person saying another thing. Only way to keep those two things together is to send this flat file. And that means there's fragmented content rights across all of these databases. And that means that even inside one organization, which could be global and own and control different things and assets in different territories, it's quite hard to keep an internal consensus in that company. And really, the only way the music industry has learned how to solve this is just to create a new database. So we end up with more and more and more fragmentation. And really, we ended up with more and more databases. And then we end up with parallel data reconciliation. So again, most things are traveling around via XML and spreadsheets and getting delivered to FTPs. There's not very many APIs either. So actually, syncing is very much manual. And that's problematic, because we are using proprietary databases. And access is ownership. If I want to tell you what I own, I have to give you the data. So it's quite hard to build out kind of one single database. However, one day, the music industry did try to do that. And there was one big global database. And it didn't really work for reasons we weren't going to. But centralized governance is problematic. If I have ownership, I have control. And really, that's why blockchains are a great solution to this problem. They help us to avoid it. We have a network of unbounded parties. We have the need to collaboratively maintain a single data set. And we want to do it without putting in a central authority. This is why blockchains are a great fit. So what Jack, what we're building is an open data network. And we've kind of started to coalesce around this idea of a single source of truth. And think about blockchains as single source of true systems. And actually, thanks to incentive structures, blockchains are highly effective single source of true systems and our highly effective knowledge production systems. So when we think about single source of truth, we try to think about it in the way that it's always been defined in enterprise. And that is say, if any one of us are working with an enterprise or a consumer, we're known in that enterprise to one department as, say, a customer, and a different person in a CRM, and a different person to sales, and so on. And enterprise service buses help us to try to create a single source of truth about who that customer is. That's what we believe blockchains can help us do around rights. So using the Ethereum ecosystem and web for the infrastructure, we can power a new paradigm for content on the web, a single source of truth for content rights built on top of an open, inclusive data network, which we call meta. Now, when we were coming up with this, we ran into a few problems. And the first is, if we want to build a single source of truth, we have to define truth. And truth is pretty subjective in the music industry because data changes all the time. And I don't actually really know as if anyone is right, who was on that song. I wasn't in the studio, how do I know? So that creates a problem. And what we've tried to do is kind of a proxy for truth. And what we've kind of moved to is authority. So authority requires really robust identity structure, which kind of led us to building out this thing we call meta ID. So you'll see here on the left, that we have this single meta ID. And meta is basically an open decentralized data network that can be used to build decentralized databases based on meta IDs, where participants are incentivized to provide trustless services to the network, such that they can be automatically penalized by providing proof to a smart contract if the surface hasn't been provided. If any of you were in the Swarm Talk earlier on, or the one earlier in the week, you'd have heard Victor talking about Sorpsware Swindle and a service layer infrastructure, and that's exactly what we're implementing here. So with the meta ID, the provider can convert their database into meta objects and push them into the network as meta streams. Then anyone can provide generic indexing services, so that's what the validators are doing here. And they basically enter into a service contract with a smart contract. And they provide services to the network and using Merkle proofs. The node can just check that the actual information they provide as a meta stream is included in that index. Therefore, with our GraphQL API, we can basically query that graph of objects and serve it up to a DAP. Now, the interactions between contributors to the MediaGraph DB, so moving ahead a bit quick, in respect to music and media rights information, we can use the meta network to implement a decentralized database which has a defined schema and is maintained by validators who are ordered with tokens to secure the integrity of this specific database. The interactions between contributors to the what we call MediaGraph DB here, which is basically participants who insert or update data into this database. And validators is governed by a SwapSwap swindled game, as I mentioned in the Swarm Talk earlier, where validators put up a stake which can be claimed or burnt if they fail to perform their duties, much like proof of stake. Now, what that allows us to do is build out this object, which we call smart content. Using method MediaGraph, we basically create a new index, which is called smart content. And the validators work to basically make sure that everyone conforms to that schema. And it extends the MediaGraph schema to include assets, licenses, metadata, and anything else required to facilitate a commercial transaction. So you can see here, we have our graph. And basically, this is a Swarm manifest, and it has a content address link that we can just find it. And it returns the rights information, the type of right, the percentage, the actual owner, which is a Messer ID. And you'll see that we have these checks here. And checks basically just assure us that the person who actually owns this thing has signed it or some delegate thereof. And that's really what the indexes or validators here are doing, we're working to maintain to make sure that this thing is adhered to. So the structure facilitates trustless kick through licensing, using smart contracts and service guarantees, using swear and swindle contracts where we get usage analytics and automated real-time payments for free. So what are we working on at the moment? A few things. So if you'd heard before, the JAG team has been contributing quite heavily to Swarm. And we started off by working on PSS, started earlier in the year. PSS being a routing protocol, which again is being spoken about just after this talk in the breakout hall. And PSS is a routing protocol, so meta nodes can communicate to each other and broadcast updates across the meta network. We also worked on a network simulation framework, which allows you to view the nodes that are in a Swarm. And then we've also begun work on Pot. Pot is basically the core infrastructure or technology that will be behind Swarm databases or SwarmDB. And we'll be working on that alongside a few of the other projects who are engaged with the Swarm team over the coming months. We've also been working on fully decentralized applications. What you're seeing here is an application that we were calling JAG, we're deciding not. It's really called the smart content DAB. It's basically a DAB that allows you to build smart content and manage it. So the theory would be you enter into the network with your MSRID and you're able to load up any of the assets you actually have already built in. And then you can customize them, add licenses, add assets, so on, and push them into the JAG network. And it uses pretty much many of the components we've already discussed, smart content indexing, media graph index, meta, Swarm, ENS, and Ethereum. So it's kind of trying to use the entire stack. So upcoming releases. First thing is the meta white paper. We've been working on it for a while now. Some people may have already seen a first draft already. That really defines the structure that we're talking about here in terms of the service level agreements between nodes, which is quite powerful because it would allow things like licensing where you just enter into a contract with the license and provide all kinds of services, including the actual storage, serving up the streaming of the assets. Again, a lot of live peer people talking about that as well. And this kind of framework really I think will drive out all the next generation of that development. The second part is the meta ID DAB. And the meta ID really allows you to create a public address and then connect all of these other authorized providers to it so you can imagine signing up as an artist with a meta ID and then being able to connect any of the other trusted providers like your label or your publisher or your Instagram, anything where you like to dock your identity. And then the meta test net, which will allow you to start building these decentralized databases. We plan to push that in early 18 so you will actually be able to try this stuff out. And final hat tip, obviously I'm the CEO. I'm not the one building all this stuff, so I just wanted to let you know the people who you can speak to if you're interested in learning a bit more. Fred and Victor, obviously my co-founders, Fred's lead application engineer on Jack. Victor obviously the architect working on Jack and Metta. Lewis Marshall, who's heading up Metta. He's the best person to speak to about all the stuff I just described. And Oren as well, who's also working on Metta. Let me have Lewis, who obviously is the developer working on PSS and Luke, who's heading up Metta ID. So again, if you do have any questions and you do wanna reach out to us guys, please do just go and reach out to them. And you can find us on, we do have a GitHub, github.com slash meta hyphen network. There we have most of these things defined conceptually. We have documents. We also have the Metta ID framework, the first version of that, which is open source. We plan to open source more things over the coming months, so please do check it out. We obviously are on Gitter. So again, just Gitter with the same thing slash lobby. And then if you do wanna join us on Slack and talk about things that may be less technical, community.metta hyphen network.io and you can just jump into Slack there and speak with any of the guys. So yeah, that's the end of my presentation and thank you very much.