1,315 karma · joined February 12, 2009
More generally, modern blockchain technology brings a lot of capabilities besides this replicated, ownerless consensus that personally I see as building blocks for your architecture. Most of them are not necessarily exclusive to blockchain, in fact lots are cryptography capabilities, but are enabled or facilitated by blockchain architecture or by each other. These are things like:
- Immutability, which is the guarantee that you have a historical record of data stored, and it won't be further changed, accidentally or maliciously.
- Notarization, which is the ability to record and identify the authencity of the originator of the information, even if you don't want to reveal the infromation or the originator identity.
- The balance between transparency, anonimity and privacy: you have tools when designing your solution to make all transactions and information trackable or not. For example you can design it so you can record transactions without revealing sender, receiver and values and still guarantee the consistency of the whole, that there's no double spending or creation of resources. Or you can design it so you can track the whole history of a resource from its creation to its consumption.
- And the coins/tokens per se, particularly when you are not looking at them as general currency or toll tokens that you simply buy and spend somewhere but when you look at them as incentives where you can control how they are created, distributed, deposited, what it means to hold/deposit them, and how to spend them. You can change who the stakeholder is and monetize user's attention, his data, behaviour. I don't think people quite figured it out yet how to properly apply this for things like social networks, journalism or creative work ("patreonism"), but it's being explored and moving along.
Everything is still quite immature and moving at breakneck speed with uncountable new projects and ideas appearing all the time, which I see them as proof of concepts of the capabilities above, variations of them, of even new different ones. And lots of scams or profiteers wanting to get into the blockchain/ICO hype.
It's quite hard to find the balance between the exagerated hype and the naysayers (which I feel lots are just an exagerated reaction against the hype), but I assure you, it's way more than just what anyone with a CS background can come up with.
Still tyranny of the majority (or of the influential stakeholders, actually), but it's a different issue.
Hopefully we do leave the laughable ICO era behind, and even if traditional relational databases get cryptographic features, but I feel the sum of capabilities the new technology can offer is larger than that.
I'm unsure if incentives (the coins) must be a part of every application of this technology. I was open to thinking that it might not, but recently saw this presentation from a Andreessen Horowitz's partner [1] where he strongly asserts that yes, it must, and I'm thinking he might have a point.
Not everyone would want to do that, so there's usually a mechanism to indicate you want to be eligible to do so, depositing your coins or similar.
That's for block rewards - nothing prevents a blockchain currency to be designed to generate inflation and add interest on everyone's investment - some do exactly that.
The inflation rate and actual utility of the currency are important factors too - if most of the currency is already distributed and the inflation is low (thus block rewards are low), the richer don't get much richer. If the utility is high, redistribution occurs more naturally as well.
Perhaps the inflation is not low but there are other distribution mechanisms that distribute currency based on utility in a higher rate than block rewards (for example on steem, of all newly minted coins in a block ~5% goes to the block creator, ~65% goes to content creators, ~6% to commenters, ~17% to curators and 7% as interest to those that have commited their stake in a long term deposit).
But yeah, in the end it indeed is a factor which is one of trade offs I mentioned, but there are ways to combat it.
Proof of Stake says that instead of distributing the work queue proportionally to the computing power you demonstrated to have, it does it proportionally to the amount of currency you have saved. It similarly prevents the attack where one could create infinite personalities to get in line, with different trade offs. In particular, beside the energy savings, it can be a much more scalable model, where you don't have to wait 10min in average for someone to solve the hard problem and instead you can know right away who are the next people eligible to generate the next blocks.
I did state it, repeatedly, but it doesn't count because everything else remains the same and it doesn't magicaly makes everything simple and easy. Allright.
Yeah, you are the one claiming that blockchain has to somehow identify and categorize songs automatically in order for it to be in anyway useful. The undeniable appeal claimed is about how organizations coordinate and share information.
> Moreover, it means that every single company agrees that anyone can just write whatever they want to this database, sure.
No, you can design it with whichever rules you want on who can write, on what's written, and how the consensus is determined if that information is accepted.
> Oh cool. Data is useless without access to it though. Hence, APIs. You are not a programmer, are you?
This makes no sense. If I have a copy of the data, I can access it. Yes, I'm a programmer.
> Just count the number of assumptions you make to make this work:
Aren't those mostly the same assumptions you have to make to have music licensing work at all? Through an intermediary, on a relational database somewhere? Everyone has to agree to use this system, to provide truthful metadata, and use this intermediary's information as the only source of truth?
> BTW. Blockchain cannot handle either payments or royalties. It can hardly handle a few payments without buckling under its own load.
Again, don't take Bitcoin's limitations for Blockchain limitations.
It won't, and it's a strawman you are setting up. Of course you have to design your business logic and rules and answer all the questions. There's nothing a blockchain, a relational or a nosql database will do for you there. They will give you different options and different tradeoffs. The point here is that this distributed solution has interesting trade-offs and opportunities that makes this a good match for this particular problem, regardless of rules of what defines a song or how licensing rights rules are defined.
> BTW. Again. That same word, database. Nothing a relational database couldn't handle with much more ease and efficiency.
Yes, sure. You can have a third party with a central relational database that does all that, and all companies trust it. The proposed solution is more akin to a relational database replicated between all interested parties. All the parties having the same vision of immutable data allows interesting tradeoffs for this particular problem, that's all. No one is claiming it will identify or classify songs for you.
> Because blockchain is a magical technology that transmits all this information directly into your brain without the need of APIs.
No, because you can design a solution where any interested party can join the network and have a copy of the data. Or not. Trade-offs.
> Also, the article you linked is a bunch of demagoguery
I think it's a very pratical way of understanding the oportunities and capabilities that open up with new technology, particulary if you have a knee-jerk reaction such as shown above. Scepticism is healthy particularly given all the hype and magical promises around it but if you look at it through the framework proposed there I hope you can see how it opens design space that was unpractical before.
Don't mistake Bitcoin's limitations for Blockchain limitations. These are characteristics of the consensus mechanism, of Proof of Work in particular.
I beg to differ [1]
> So how in the seven hells is blockchain going to help?
It's not a silver bullet, and most things are not ones that were not possible before. But it facilitates some combinations, makes some things a lot more practical, and opens space for innovation.
In this case, in particular, what comes to mind is:
- there's a replicated consensus of all this attributions. Every single company agrees and has a shared database of the rights and the licensing. - the disintermediation: there's not necessarily a need to have a middle man managing this informations and agreements. - auditable, notorized, unforgeable history: you have this immutable record of when songs were released, who held their records, who and when licensed them, etc. - open information: if you design this system as an open network, any interested party can join and get the information it wants without needing APIs, etc.
All this without getting into tokens and handling the payments and distribution of royalties on the chain, and other innovations that the capabilities of the blockchain can bring.
[1] https://blockchaintechguide.com/a-blockchain-based-future/
It's impressive the number of supposedly senior candidates that can't follow simple instructions from the platform or write a couple of lines of code in their language of choice to sort the words in a string or something similar.
I fully agree that multiple complex algorithm or puzzle questions are bad - require a longer time investiment that most candidates should be willing to devote to such process, are distanced to the reality of most programming tasks and favor those who enjoy and practice programming puzzles.
Popular enough to turn it into a book? :)
Well, maybe it was because I'd read the story before (and really enjoyed it) so I couldn't get the same enjoyment from the book.
Anyway, good work and keep writing.
https://www.robinsloan.com/books/penumbra/short-story/
I felt like the book was mostly filler added after the popularity of the short story.
I also couldn't find the details in the site anywhere.
"In terms of licenses: GPL is all you get for now. I can always add more liberal licenses later. LGPL for a decoding library, or maybe even MIT? We'll see, I'm not in a hurry."
https://boards.openpandora.org/topic/18485-free-lossless-ima...
https://boards.openpandora.org/topic/18485-free-lossless-ima...
- for interlacing it uses a generalization of PNG's Adam7; unlike PNG, the geometry of the 2D interlacing is exploited heavily to get better pixel estimation, which means the overhead of interlacing is small (vs simple scanline encoding, which has the benefit of locality so usually compresses better)
- the colorspace is a lossless simplified variant of YIQ, alpha and Y channel are encoded first, chroma channels later
- the real innovation is in the way the contexts are defined for the arithmetic coding: during encoding, a decision tree is constructed (a description of which is encoded in the compressed stream) which is a way to dynamically adapt the CABAC contexts to the specific encoded image. We have called this method "MANIAC", which is a backronym for "Meta-Adaptive Near-zero Integer Arithmetic Coding".[1] http://www.joelonsoftware.com/articles/fog0000000069.html
A linguistics professor was lecturing to his class one day. "In English," he said, "a double negative forms a positive. In some languages though, such as Russian, a double negative is still a negative.
However," he pointed out, "there is no language wherein a double positive can form a negative."
A voice from the back of the room piped up, "Yeah, right."
I use the free version, and while I noticed it is a bit different since a few weeks, didn't really notice anything that would bother me.
What I seem to find is that the first two weeks of sale on Early Access sales paid for the investment [1], which may be what you are thinking about.
Anyway, I agree with your final point - in this model sales must pay for the salary of the team working on the project plus additional development costs, and that's much easier when you are a single indie developer. Double Fine seems to be too big for that.
I still maintain my position that, if you're paying to get in the alpha of a game, you should be prepared if it develops to be of a different genre of what you are expecting, if it focuses on different things, if it's cancelled, or if it's simply bad. You can get frustrated, sure, but not surprised.
[1] http://indie-fund.com/2013/11/spacebase-df-9-recoups-investm...
I haven't played the game, so I can't judge each side merits on the controversy, but it seems to me that a major issue were people expectations of Steam's Early Access model. You are buying an unfinished game, under development, to fund it. It's not a pre-order. It's not a model Double Fine created, they just experimented with it using DF-9.
People seem to expect from this model frequent releases with shiny new content for an indefinite amount of time. The most popular early access games deliver on that, with a release date that never comes and frequent patches that don't necessarily have the goal to finish or polish the game for release but always adding new things.
Failure and the game being cancelled should be an outcome expected from this model, as well as from the Kickstarter model. A game being released that don't meet your expectations is another, and it should be factored in your decision of buying a game that's under early development.
When they got ten times as much funding, it came along with hundred times larger expectations which caused the scope to grow a hundredfold equivalently. Tim's fear to meet those expectations caused him to make the game he wanted and knew people expected instead of the one he pitched. Scope grew to include hand-painted art, professional voice overs, orchestral music score, and a much larger team for a longer time so they could make a longer, more polished game. On the first few documentary episodes their struggle to match perceived expectations with the actual budget is clear, and the wishful thinking on estimates and plans also clear in hindsight.
All this because it turns out that, after all, $3M is not a large budget for a triple-A game, specially when you remove kickstarter and amazon's processing fees, rewards costs and shipping, and the costs of the documentary. Consider a team of developers, designers, artists and animators that are needed to build such game, each costing a conservative estimate of US$100k+/year to the company, then add all external assets and services. The burn rate is big for a project on that scope.
All in all, I'm fairly happy on how it turned out so far, and looking forward to part 2. I back independent games on Kickstarter to encourage the shift on the stagnant producer-driven market and don't treat it as a pre-order. Broken Age turned out to be one of the better ones I got (Book of Unwritten Tales 2, Wasteland 2 and Shadowrun Returns were the best ones, Takedown was probably the worst, glad I skipped on Clang).
In fact, I think the documentary alone is worth the $30 I dropped in the pledge. If you haven't seen it, it's available for purchase for $10 and they started releasing episodes publicly for free recently: https://www.youtube.com/playlist?list=PLIhLvue17Sd7F6pU2ByRR...
If software development or game design are things that interest you, go see it now, it's very good.