Hi and welcome to this second installment of the first Joystream community update.
So, this segment is about the Sumer network which is a network we’ve been working on for about, I want to say, three months now.
It is going to be building on Antioch which either is going to be released or has just been released depending on when this video comes out.
So, the goal in the Sumer network is to do three separate things.
First of all, we want to introduce the next and I want to say final iteration of our on-chain content directory.
I am going to explain this in further detail but I am just going over the overview.
Then we are going to introduce Atlas Studio which is new part of the Atlas product.
And then we are going to introduce a new working group which we are calling the operations working group.
So, let’s go through this.
So, the new content directory.
The new content directory is an enhancement over the existing one and through pretty important ways.
I am going to go though what the content directory actually is as in the next slide but just let’s dwell on this for a moment.
The first one is that it is radically simplified.
The existing content directory that we had was actually very very complex because we were trying to achieve the goal of having the community to be able to update
what is in the content directory, so stuff like videos and channels, and playlists without having to do runtime upgrades.
So, runtime upgrades, as I probably have mentioned prior to this in this community update, is a way in substrate chains you can change the rules of the system.
So, for example, you can imagine at one point in time a video has a title, and then at some later point in time maybe a video has a title
and also what language the content of the video is recorded in or what language the people in the video speak or something like that.
So, that's a relatively small thing to change but you want to make it easier for the community to change stuff like that,
and if changing every little thing like that requires a community update, it's going to be really hard for the community
to iterate quickly on this part of the platform which really needs to be very flexible.
If you wanted to introduce other things, not just videos, let's say you wanted to introduce like eBooks or, you know,
some other mild variation of what we already have, it would also be very inhibiting if you'd have to do a runtime upgrade because we have to do a runtime upgrade,
you have to dive into the rust code, you have to change it, you have to figure out how to take all the old stuff in your state and turn it into the new stuff through a migration step that runs inside of the consensus of your blockchain,
you have to update all sorts of dependencies and libraries and infrastructure to reflect how the new system works, you have to test a lot in advance.
I mean, if you do it significantly, if the change is significantly big, you should probably also do a test,
integration test where you run through a simulated upgrade with some representative state in your system,
you see how it works after the runtime upgrade, does your account still work, does your voting system still work, and so on.
So, it's a lot of work.
And if you make a mistake, you can permanently destroy your chain.
So, it’s risky, it's hard, and it's, you know, requires a lot of care.
So this is a very long-winded way of explaining why we ended up having the old content directory that we had.
And the point of that content directory was that it was sort of very abstract, almost to the extent that it was like a relational database where it allowed the community to define schemas
and concepts on chain so that you didn't have to do runtime upgrades to define new things or change the way things were represented.
That's great. The problem was that it was extremely complicated.
It became really hard to both have work properly on chain, it became really hard for people to understand how it worked.
And really what it turned out to be was that you couldn't even get something that was all that flexible, so you couldn't actually get all the flexibility that you wanted.
So, what we did in this release is we just said screw it.
What we're going to do is we're going to put the heart of what it means to be in the content directory on chain,
and then we're going to make the metadata associated with all the different things on the chain, such as videos and channels, and so on.
We're going to make sure that that's actually very easy to change.
So, you don't need to change the low-level business logic of the chain itself in order to make the sort of smaller tweaks that I described,
such as the fact that a video may have
a language So, you sort of lift that out of the chain entirely.
We also just decided that this is the way our content directory is supposed to work.
So, that's a pretty big decision.
And that's what's landing in Sumer.
So, let me go through now, just very quickly.
So, the video of myself which is not that useful is covering up a part of the diagram which is useful.
What's supposed to be there is a square which shows the unchanged storage system.
I’m going to figure out later whether I change that or not but let's just go with the flow.
So, the on-chain content directory has in this representation, as you can see, memberships.
Channels have within them stuff like videos, and playlists, and series.
All those actually exist in the chain but they haven't been fully implemented, and they will not be implemented in the consumer product like in Atlas itself.
These are people who are sort of employed in the content working group to manage and make sure that everything in the content directory is going according to plan,
and they can also own channels themselves on behalf of the platform to feature official platform content and that kind of stuff.
Now the interesting part here is that on chain you just have this sort of index of all these things, you know, what videos exist, who owns them and this sort of stuff.
You also have an index of what data exists, so like the images, the cover photos, the actual video media files.
There's like a list of them you can think of or like a map basically which holds a representation of who owns everything,
how much space has member number X used out of all the space available to them to publish to their channel and so on.
And, of course, when the storage infrastructure is supposed to be replicating what part of the data.
Right now, of course, that's fully replicated in the current storage system but that would be changed in a future version which I’m going to get to in one of the later videos.
But basically, that index also lives on chain in the data directory.
And then of course the actual storage is on separate off-chain infrastructure and storage nodes that are also responsible for shipping the data to users.
And, as you can see, one of the things that actually are possible in this release is for things outside the content directory to also use data.
So, stuff like your membership avatars, we are aiming to have stored in the same storage system.
So, before, you know, for your avatar you really have to reference some URL somewhere but for what we're going to be introducing, the first step of that in this
Sumer release is that you could also store assets like that in the storage system itself just like the videos for the content directory.
Likewise, that could be used in other parts of the system, for example, as attachment in proposals or in forum posts and so on.
So, it’s going to be a general infrastructure piece for the rest of the runtime.
So, that's the first part of what we're doing in Sumer on the content directory.
The next step is that we're launching Atlas Studio.
So, Atlas is the sort of the viewer product where you can see videos and channels and so on.
And Atlas Studio is sort of the flip side of that experience where you can actually see all your channels, make channels,
upload stuff to your channel, manage it, delete stuff - basically like the channel publisher owner experience.
That really is a very big step in the direction of making it easier for people to publish content to the system
which before or at the current time has to be done through a command line interface which is a very rough experience.
I think I can show a few outtakes of what that experience looks like.
You'll have, you know, a nice experience for filling in the basic metadata and setting up your channel and editing it. 3
You will have a way to view all of your videos, and change and edit the metadata associated with them.
You have drafts for stuff that you haven't committed to chain locally stored.
This all runs in the browser, just as Atlas itself does.
There'll be a smooth sort of upload flow for providing the media files and the basic metadata for videos in a step-by-step way
which ends with you signing a transaction which, now actually that's interesting, uses the Polkadot JS signer extension rather than the native wallet or,
I should say, local storage wallet that is in the normal Pioneer product that we're currently using.
So, that's also step in the right direction of having people use an external key manager.
So, there’s also, as I mentioned, we can store assets now like images on the storage infrastructure, so that means we're going to be helping you set
and provide the right assets, manage how they're going to be displayed as part of those upload flows.
So, that's Atlas Studio which is the second major goal to launch for this release.
I also forgot, of course, we're going to be, if you have a look at the experience here for uploading and editing videos, you can see there's sort of like a tab system here,
and that's because we want to make it easier for people to manage multiple things at the same time.
With that, of course, comes the need to manage a lot of different uploads at the same time as well, so there would be a separate area to manage all the different assets
that are uploading at any given time. Uploads can fail, you could lose your connection and so on.
So, we'll have a graceful way for you to retry anything that hasn't worked in the past.
I don't think we could have had anything reasonable even in the CLI to make this possible.
This is a very big step in the right direction, and it's a huge effort from a lot of people, designers and developers and infrastructure pieces that are needed to get this to work.
That's fantastic.
Then the last piece of the puzzle is the Operations working group.
So, what is this? Well, I am going to get to what a working group is in a little bit more detail later but if you're a little bit familiar with Joystream,
you’ve probably noticed that there's the council and then there are these groups that are responsible for specific things,
and the operations working group is a new group like that, and what's special about it is that it's supposed to be
for any kind of activity that doesn't have at least yet an on-chain footprint or a role.
So, let's say if you're a forum moderator, that implies that you can do certain things in the forum that other people can’t do.
There's an on-chain forum in Joystream, as most people probably noticed.
Likewise for the storage system and so on.
The operations group is meant for all of those activities we're currently doing and which will be part of the system in the future which don't really have any direct privilege on chain.
We just want to provide the basics of what a working group allows you to model - stuff like what the roles are so everyone can see,
it's transparent how people got into the roles, how they applied, what were the merits for people being admitted.
People have predictive, they have predictable reward schedules for what they will be paid, they have predictable stake at risk,
so they can be given a little bit more responsibility in terms of what they can do, what they can be tasked with on behalf of the group and of the system overall.
So, the examples we're going for at the moment are things like developers, we have at least one of the founding members,
I believe, is looking to be one of the first developers in the operations working group.
In general, managers, marketers, anyone who would like you could think of almost like a role or a job but doesn't require you to do a lot on chain as VM.
So, that's the operations working group.
I’m hoping that this will be sort of a sandbox for discovering lots of roles that we haven't explicitly modeled into the system.
Maybe we will as a result of what we find out but I think it's high time for something like this.
What is actually… again my little preview thing is covering part of the image. I'm not sure, if I can actually move it now. Can I do that?
No, I can’t. All right. So, I'll just try to explain. The goal of this is just to show how the working group fits into the overall system of Joystream.
There is some general information in this community update series so I'm sort of straddling the line between very general stuff and stuff very specific to the releases.
I think in the future we'll do some like deep dives where we try to go systematically through each one of these, and give you a more fine-grained and a thorough introduction.
I just want to sort of tease you with that here.
The governance system in Joystream is actually a lot more, it is deeper, I would say, than what you find in a lot other crypto system.
In a lot of other crypto systems, you just have a flat coin voting, sort of voting pool which has proposals.
Typically, they're actually limited to things like signaling and spending maybe in upgrading the protocol.
So, you don't even really have that rich of a portfolio of proposals to choose from.
In Joystream that set of proposals are very very very broad.
Of course, at the root, sort of the root of trust for the whole system is a coin vote which happens not on individual proposals but on election cycles where you elect a council.
A council is a sort of one actor-one vote where you have council members vote on proposals.
I think the current setting we have for that is every two weeks there is a new council elected.
I’m not actually at all sure we are confident about what that number should be on main net but that's what we have at the current time.
That's mostly just informed by what's practical in order to have new people in the community, learn what's going on.
We'll see, that's interesting, it will be interesting to figure out what that ought to be but anyway there's a council which lives for a council period.
The same, the members can stand for council, and they can be reelected for future councils.
The main responsibility of the council is to vote on proposals, and the proposals do the things that I've just described, including hiring leads for individual working groups.
There's one working group per subsystem you could think of it.
There's a membership subsystem which is primarily at least in the Olympia runtime, which I actually haven't mentioned, but that's the third community update, I think, so it’s coming.
Prop is mostly preoccupied with invitations to grow the membership pool.
You have the storage working group which is primarily about operating the storage system, storage infrastructure.
You have the forum for operating and curating the communication on the forum.
You have the operations working group that we are talking about here.
It's these different subsystems that run some part of what the overall platform needs to work.
Inside of each working group you basically have a leader which is someone who applies to occupy that role through a proposal to the council.
And that leader is basically responsible for spending money out of budget that is allocated to that group from the council for all sorts of things.
So, you can imagine, for example, if you're a storage working group leader then you need to figure out, well, how much money do we need for the next let's say month,
and then you have to go to the council to have them give you that much for your budget.
The leader is able to pay the rewards for himself and everyone else, all the other workers, as they're called, in the working group, for providing the service to the system.
The leaders are also able to change what someone has as their reward and can slash them if they do something they're not supposed to do.
And, of course, same applies to the leader with respect to the council.
The council can update the reward and slash them and fire them and all this sort of stuff.
So, the working group is sort of the lowest sort of bureaucratic organ in the overall governance hierarchy of the Joystream system.
And we're getting a new working group in Sumer.
That hopefully was a useful introduction to working groups and the operations working group.
I think that's the last of it, so thank you for joining me for this Sumer update, see you in a bit.