Hi, and welcome to part five of the Community Update.
Here I'll be going through some new specifications for features that are either, actually some of them are finished,
others are in progress, others we haven't started on, just to give people a flavor for some of the things that are coming down the pipe.
So, let's start with the new storage distribution system.
This we have already started to implement.
A quick sort of refresher for those who may not know.
The current storage system is sort of the simplest possible thing you could imagine.
It has an on-chain index of what all the data that exists in the system is – like the hashes, and the sizes of things, and who owns them and so on.
There is a designated role as a storage provider that means that you're obligated to basically store all the data that is in the system.
So, that's the first clue that really wouldn't work at scale.
You also have to distribute all the data that you are storing as a storage provider.
That's sort of the way the system works today.
I think we've largely gotten away with it because there hasn't been a ton of load in the system because the publishing and consumer
side of things hasn't been the way we have prioritized our development roadmap.
We're a DAO and governance-focused project so we've invested a large share of our resources in developing that first.
In the last six months we've, maybe a little bit more than that, we've sort of shifted our attention or, I should say,
broadened our investment horizon to also cover our investment scope, to cover more on the content side which is also going to result in the storage system
needing to handle a little bit more scale and a little bit more realistic policy space.
It couldn't have come any sooner.
What's coming up in the v2 version?
There are a few highlights that are worth mentioning.
First of all, we're going to be separating the role of holding on to data and replicating internally in the infrastructure
and distributing data to end users who are, for example, sitting in Atlas.
Those are really two very different activities from an infrastructure point of view, from an economic point of view.
One is about having very reliable infrastructure that doesn't explode or, you know, catch on fire or whatnot.
It's not so bandwidth sensitive.
Then you have this distribution activity which is about very quickly getting a much smaller subset of data to potentially a large number of people simultaneously.
That's, for example, a role where it's important maybe where you're located and who you expect will be in touch with you, and the latency involved and so on.
So, those have been separated to do distinct roles.
Another big improvement is obviously that not everyone has to either store, if they're a storage provider, everything or distribute, if they're distributor, everything.
It's sort of sharded so that some of the storage providers store, basically, it's partitioned into different families of storage providers.
We don't have any erasure coding or other scheme that tries to get away with avoiding storing and full replicas
to the degree of safety and redundancy that you want, that hasn't really been important to us.
The first step has really just been to move away from everyone storing everything.
Maybe we will incorporate that in the future.
I think, SIA, for example has that Messiah but I'm not sure how important it is for the main net level of load that we're imagining.
So, that's a very big difference.
Another big difference is that not only members or, I should say, channels can store stuff in the storage system and have it distributed.
The council working groups could store assets as well which is very important because there's going to be an increasing set of assets of all kinds,
you know, binaries and source code and documents of different kinds that you want different
parts of the system to be able to persist as different people are flowing through those roles.
That's why we've introduced the capability of those different subsystems to have their own designated storage spaces, so to speak.
Also, we're taking much more seriously the need to be able to reclaim space or basically delete content.
That's something that really hasn't worked in any sort of scale even with Sumer.
So, that's something we're also introducing.
Lastly, we are allowing the distribution policy, basically how it is you allocate your bandwidth resources across space and time to be much more flexible
because what you can imagine is that for a given channel, for example, for a given piece of content
there's going to be a predictable geographic bias in who will want to access it quickly.
If you're some Spanish cooking show, overwhelmingly there are some parts of the world which are going to want to access that content,
and you would want to be able to optimize for the location of the distribution infrastructure that services those, as opposed to something else like a Finish knitting show.
That's another very important distinction.
This level of sophistication is more than enough for main net purposes.
So, that's the v2 storage distribution system, and the work has already started.
Then we have the concept of gateways.
The issue the gateways attempt to address is the fact that it's really important for the tokenomics of the system to work specifically in the sense
that if you're a user, a consumer coming in to view content, you're consuming obviously expensive infrastructure resources
like bandwidth and storage and so on, but you're also, of course, enjoying the fact that someone has made a fixed investment of creating the content that you're also viewing.
For the system to work overall there has to be a way to get the viewers to contribute some value back to the platform and everyone else.
The obvious way to do that is just requiring all the viewers to have Joy token and create memberships and have to have a signer and an ex in their browser and find
their way to some front-end application hosted somewhere, and they have to acquire Joy in some way in order to view the content.
I think it goes without saying that would be a huge barrier to entry, and it would really restrict your ability to onboard people who don't even know anything about crypto,
don't know how to or don't want to deal with how to acquire it, how to manage it, how to store it, how to spend it.
It's still not a great experience if every time you have to watch something, a big signer thing popped up and asked you to sign off on spending some Joy, that would not be a great experience.
Even if you made something a little bit more lumpy, like if you paid for x number of views or for some period of time, it's still a very steep onboarding experience.
I think, one of the main things we have to unlock is a way for just a general audience to, in an economically sustainable way, enjoy and consume the content, and that's what gateways are supposed to do,
Gateways are basically front-end operators who are free to monetize and own the relationship with the end user in whatever way they see fit.
If they monetize through advertising, that's fine, if they monetize through some sort of in-app purchase in some app store, maybe on a smart TV, I don't know, they're free to do that however they see fit.
And, specifically, this ability to support advertising which, I think, is pretty important in order to be able to reach scale within a timely manner,
I think you definitely would need to allow that at least in the mix, and that certainly requires you to be able to own the relationship and own the front-end primarily
to avoid abuse and other things that will happen if you don't do that properly.
What gateways do is they basically have a business model around delivering a front-end user experience owning the relationship with the end user,
and what they do is they take on the burden of acquiring Joy and burning it in order to benefit,
well, in order to actually give their registered users access to the infrastructure and to the content.
They sort of internalize all the small transaction costs of everyone trying to do that on their own.
The gateways do that on their behalf, and they have long-standing relationships with infrastructure providers, with the leads and the gateway working group and so on.
You should think of them as a new role in order to make it much easier to acquire and retain users that are not eager to instantly jump on the on the Joy bandwagon to acquire in order to use the application.
Those are gateways.
They're really important, and they're probably going to be developed, well, it's not clear, probably the work will be in somewhat in parallel with the v2 storage system work,
but it's probably not going to come out at least two or three networks into the future.
So, those are gateways. Then we get to channel tokens and DAOs.
This is something I'm really excited about.
This is sort of, I think now it's being called social tokens.
Basically, it's a way for creators and small communities to issue tokens that give you a claim on the value that's generated by a channel.
I suppose we could also type to videos but this specific specification has to do with channels and the revenues that channels generate, and it gives you governance rights
and how that channel is managed to the extent that the channel token issuer is interested in doing that,
and it really tries to formalize something that's been attempted a good number of times.
For people who have been in the space for a while there was something called Tatiana coin which basically tried to do something like this,
well I would say simpler version of this, where you would buy it, and that would give you the right to certain, I believe it was a certain number of songs or something.
This was a musician, I think, smart media tokens, perhaps a little bit closer to this.
There was a Steemit initiative which was supposed to give you the ability to create a community or monetize your community by issuing a token tied to it, I'm not entirely sure how the tokenomics was supposed to work.
I think it was perhaps a little bit more speculative where it wasn't clear where the value would come from but here the value is really supposed to come from the value generated by the channel itself.
So, that’s channel tokens or we're calling them channel bowels, social tokens.
I’m not sure how we're going to explain this but the idea itself is something that's sort of been around for a while, and of course if you're a creator,
you can issue one of these tokens for your channel that you could raise Joy in order to be able to fund various expenditures, and you could obviously trade the channel tokens also.
So, those are the channel tokens.
And then, lastly, we have crowdfunded bounties. This has actually been implemented already.
So, this is an idea for solving the problem that sometimes community members would want to organize within themselves in order to produce some sort of public good
that has a platform-wide benefit but, or maybe even a benefit within some subsection of the community,
which it's not worth it or it's not clear that it's going to be feasible to get the council with all of its priorities to actually accept and to fund,
or maybe even that there is some budget constraints for the council, so they couldn't even do it if they wanted to do it.
The idea is to implement something called an insurance contract which is, basically, very similar to,
I guess it was called tipping point at one point, and then was, I don't remember now,
it was this huge startup which was trying to basically incentivize collective action by saying “I'm going to do something only if a sufficient number of other people
or sufficient amount of money has been dedicated to do it”.
To some extent you could think of the free state project in the United States as a similar type of initiative for political collective action,
but basically it's the same idea where you can make a bounty and you could say - this is going to fund x if y amount of funds are provided
And then people, if the funds are secured, people can come and work on a bounty, and there's going to be a dedicated person for each bounty who's assigned
to as adjudicating whether someone's contribution is good or bad or worthy and how the funds should be distributed.
So, basically, a bounty system combined with a crowdfunding system.
There's actually a little bit more sophistication in this because we're also trying to model something called the dominant assurance contract
which tries to make it incentive compatible to contribute to one of these by allowing the bounty to be owned
by an entrepreneur who puts up a little bit of money, where if all the people who contribute to the bounty, if they contribute to it and it fails, so it doesn't reach the goal of,
whatever the goal is for whatever purpose, they all get to split the little prize or it's called the cherry in the bounty that's provided by the entrepreneur.
If you are to make a concrete, let's say you want to make a smart TV app for Joystream, you could make one of these bounties where only you could work on it,
so only you would get the raised funds, and you put up, let's say, two thousand dollars
which will be released to the funders if an insufficient number of people end up contributing to reach whatever goal you need, let’s say you need you need 120 000 in order to do this.
That actually makes it now in the interest of people otherwise who would sit idle and not be able to contribute because they get to speculate on the outcome that it doesn't actually work.
So, that is already implemented, it's going to be some time until it's actually exposed in Pioneer so you can use it but on the runtime side this all has already been implemented.
There are other things but I think these major four new specifications are the most interesting ones to cover at the moment.
That's it, see you in the next video.