"The Dawn of Democratised Innovation Attribution"

"Exploring Innovation Networks: Analogies from Network Communications"

IN DRAFT

Target​

I11 Request-Idea

Inherits​

Dependencies​

Why ask for Requests and Ideas to be divided?​

It's not a vague vs precise thing. It's headmark vs compass bearing thing.

The general rule is that you should always know what your '1-up' is trying to do, regardless is what he's telling you to do. It's recognising that centralised command and control is inferior to decentralised command and control, but by decentralising, you could give misfires. You need to let the guys know not only what you think they need to do, but why you've asked them to do it.

So the strategic intent is the high level "Start with why". That's needed because it's not possible to write the tactical intent (the compass bearing) in sufficient detail to avoid fuck ups by itself, you need to give a headmark. But it's not enough to just state why you're trying to do something (the headmark), without giving some guidance.

The Ratcatchers and Regulators thing comes from Admiral Beatty and Admiral Jellicoe in WW1. Beatty was the ratcatcher, and didn't plan ahead at all well, and gave full reign to the captains under his command. Didn't go well, as they each had a different idea of what the overall objective was, and so perfectly executed their own commands, just in different directions. Jellicoe was the Regulator, and literally had a huge book of rules which all the captains under his command had to follow, and so was exceptionally brittle as soon as the hun came over the horizon.

The middle ground is the way. Don't over specify, don't leave people in doubt of what the whole point of the thing is.

So it's fundamentally different from nested Requests, in that strategy is about why, then there's a phase change to tactical which is about how, what, where etc.

The destiny of blockchain is to model the entire world. What point then is any instrinsic currency ?

Object oriented programming is the dominant form of computer modelling.

Our purpose is to facilitate trade between all currencies and all objects, predominantly labour, technology, customers, and assets.

With enough granularity and autonomous agents, we can get back to barter.

When we first started towards the Dreamcatcher, we wanted software defined companies, to cure the ailments we had in our current publicly listed companies. Now we're saying that each object comes with a software defined company attached via API.

Why aren't software defined companies popular ? What are manually operated companies the favourite ? Is there some relationship between the granularity of a thing before it becomes programmable ?

Points

1. Future of all currencies is to be replaced with barter
2. Any crypto currency is arbitrary anyway
3. Object models allow direct trading of the item
4. We can model any currency, with provenance, and fractionalize it to nano portions
5. miners can earn whatever currency they wish
6. liquid exchanges let you swap for any other currency
7. There is no currency since the value we are creating is captured in the NFTs that make up the system

Given that we built this whole thing on non-fungibility and modelling of the real world, it makes no sense to have a currency of our own. Any arbitrary fungible unit of value that has no internal control mechanism will periodically crash. With no regulation, this cycle is accelerated, as the system can be used as a 'bigger fool' scheme, but is harder to squash due to its distributed nature, with a multitude of bad actors having no coordination except the same pattern of ill intent.

Systems that launch with a 'shares' like nature, such as ICOs and other "Initial *" offerings bake in their demise from inception by setting the exectations and incentives of multiple powerful actors in the system.

The question was: "When asked "what does the Dreamcatcher do ?" how can we include this graph at the heart of what it does ? "oh it makes things fairer" isn't very precise. Showing the wage theft gap as the addressable market for the Dreamcatcher says it has a lot of potential, in provable numbers, I think ?"

I think we're missing the main point if we talk about removing power from Capital. We're not leading a revolution - we're tuning an old, large engine that could do so much better... But we need to convince Capital and Labour to make it work. We can't do that by being anti-capital.

Bear with me now, as half an eye to turning this into a blog-piece, and typing this on a phone... Previously we had two main economic models:

Labour dominant: Communism at it's core was to remove influence from capital and rent seekers towards Labour. To do that, it was necessary to centralise as there was no pracical alternative. Guessing I don't need to say why centralisation is bad, other than summarising: few brains = bad; many brains = good.

Capital dominant: Capitalism aimed to decentralise, but failed because of network effects. The more Capital produced, the more than can be produced, and so there's (all else being equal), a exponential effect that accumulates Capital over time. So you inevitably end up with small and reducing group of Capital holders. Not helpful. Again, few brains = bad; many brains = good.

[Sidenote - this distinction between Capital and Labour is outdated, but going to use it as a traditional framework below. By example, the four of us are working together now. Who's Capital and who's Labour? Say if we hire a guy at half pay, and half Attribution? Who's Capital and who's Labour then? The point is the differentiation is in reality blurred - there just hasn't been a practical way to recognise that until now.] So what we're proposing is a third way.

Many brains <-> Many brains = genius.

NB, no one is losing out here. Both Capital and Labour are improving efficiency. Laying to one side arguments that benefit is relative to your immediate neighbours which you compare yourself with, improving efficiency has got to be a good thing... AXIOM - Innovation is a good, as of and by itself. Making Innovation more efficient is therefore necessarily good. So to test this, here's a thought experiment. Two people, one is the Capital guy, the other the Labour guy.

It's important to note that there is a symetry there. The Capital guy can fire the Labour guy, and the Labour guy can fire the Capital guy (by resigning). But there's an asymetry of information - the information gradient.

Have talked about this Information Gradient a bit, but this is more important than it may seem. These two don't live in the same world. Capital guy knows about capital; Labour guy knows how to build stuff to make a ROI. Capital guy knows very little about Labour guy's world; Labour guy knows little about Capital guy's world. So we're now approaching a zero-sum game. Each will be looking out for themselves (of course) - even though it would be to the benefit of both if the Project succeeds. Therefore: AXIOM - Wherever that's an Information Gradient, there's an inefficient market. To dig in to the world as seen by each of the players:

Capital Guy​

The Capital guy is trying to increase his pile by using it to build Stuff, sell Stuff, and make Return on Capital Employed. But he doesn't have the skills, so he needs to give it to some CEO, who will then go off and hire a bunch of people to execute on an idea. To find the CEO he's probably having to look through his local network to N levels of separation, depending on his patience. In my experience, N=2, which is pants.

He then has to offload his own aim of building his pile to this CEO guy, who then goes out to look for talent to build the idea. That's a fraught process, and I'd argue close to being random selection, based on some filter. So the Capital guy ends up worrying about his Contribution being spanked on marketing socks (Tom, Ben, you get the reference), "Tribe Two" consultants out to gouge a day-rate (Tom, yup, you'll also get the reference), and because of the Information Gradient, Capital Guy has no idea whether his pile will increase or disappear.

Worth thinking about that for a moment. Capital guy has close to zero control about whether his Contribution will provide a Return, beyond, well, you know, shouting, firing people, closing the company etc.

The result is that start-up investment is seen as ludicrously risky, and so the risk multiplier means that the Capital guy would be an idiot to not grab as large a percentage of the pie as possible, even before the pie is ready to go in the oven.

In addition, at the early stages, Capital guy has the Information Gradient in his favour. Two guys in a garage vs Round-A $3m...

I do have a lot of sympathy for the Capital guy though. Being out of control sucks. Capital guys doesn't have real control, beyond raising, hiring, firing and folding. So small number of Big Hammers...

Labour Guy​

OK, so other side of the coin, the Labour Guy. Labour Guy has more direct control over what's produced, but they have perverse incentives (cf Adam Smith). You could work hard on what the Capital guy wants you to do, but you're also interested in increasing your pile. How to do that? A smart Labour guy will be trading off working full tilt on the Project, setting up their own Project, maybe gouging for salary while the going is good.

But again the Information Gradient kicks in. Capital guy has identified that there's a large risk, and so will be holding as much of the pie as possible for as long as possible. Labour guy can bake that pie, but won't go full tilt if he's not going to get any. It's a zero-sum game.

Again, Information Gradient = inefficient market.

So we get the weirdness of two groups, who if they cooperated with each other could build The Thing, expecting that it's a zero sum game and, using the tools each have to hand, trying to maximise their own return not the important thing, which is to see whether That Thing is useful in the market.

Dreamcatcher​

AXIOM: Dreamcatcher intends to reduce and ultimately remove the inefficiencies we see now in Innovation. From the Capital guy's point of view, the ideal situation is that the Labour guy is working full tilt on the Project. Ie, there's zero Information Gradient between what the Capital guy wants and what the Labour guy wants.

From the Labour guy's point of view, the ideal situation is that the Capital guy will give him his full worth of the effort he puts in. Ie, there's zero Information Gradient between what the Capital guy wants and what the Labour guy wants.

So there's a potential here that there is no information gradient, and that both groups have exactly the same incentives And that's my point. Dreamcatcher isn't anti-capital, anti-rent-seakers (although I hate rent-seekers). It is about working towards making Innovation maximally efficient, which isn't a zero-sum game. If it works, everyone benefits... @everyone Feel passionately about this. Know we have a lot going back and forth, but would love it if one of you guys would kick the shit out of what I've said above. Right now, for me, that reduction in inefficiency of innovation is everything, and we need to lead with that not being a zero-sum game...

Distributed apps at best can have tamper detection.

Decentralized apps at best can have censor resistance.

Consider then a github clone with a central token. Once roughly 51% of all the governance tokens have been controlled, which could be done by censoring maybe three or four people if not distributed well, then the entire app is at the will of the censor. Worse, perhaps the underlying blockchain is overthrown somehow - then the github token goes down as collateral (excuse the pun) damage. The problem is confounded by the requirement that surviving blockchain operators need to communicate with each other, as forking is considered a system failure. This repeated communication makes them easy targets. Yes, the system could start again as soon as the first copy re-appears and starts operating, but during that window the censor is in control - supression is the norm.

An inverted version of github makes its own dedicated set of blockchains for each git repo that anyone wishes to host. These apps might communicate with each other, and might even trade using some currency selections. They might share block producers, they might not.

To take down an inverted app requires finding all the blockhosts and all the key owners of all the github repos that every get created using this means of operation. The problem is far thornier than the other classes of apps. We believe this is censorship proof operation - if a censor can find every actor who is running a copy of the software. Whole subsegments of user can go offnet, and run local only. You can only supress what you can detect, and so this is the worst possible scenario of any censorship effort - we should strive for this, and not accept inferior systems that offer anything less that censorship proof apps for everyday users.

Email is an example of a sort of inverted app. It has massive distribution, it is not centrally controlled. The central control however, is exerted by the DNS namespace, and the IP allocation tables of the internet. but it has many of the characteristics, and its wild spread indicates the scale for these types of apps. It could be that email is the simplest form of such a thing, as it really just does transmission and receiving. More complex and more useful interactions such as long form stateful collaborations have yet to see such an exlosion, but git offers a glimpse of what that could be like. If only git came with its own independent version of github wrapped around every repo that was created. Its components lack the resilience and internal integrity necessary to travel thru many inverted instances unaltered.

The first inverted app is the dreamcatcher. Each idea is free floating, owned by its creator and optionally private. Then projects are created - themselves a form of idea - to capture these ideas, seek missing ideas, and refine them into something usable. Each project is entirely sovereign to itself, optionally run by whomever has compute capacity to do so. It is completely free of any centralized token control, system control, or even version control. It can, at the freewill of its owners, communicate with other organisms such as itself, or with other external systems such as email.

The spreading of a codebase creates a desire for future improvements to that program. This is primarily how we get paid, and the service we are offering - future improvements quickly, of quality. The more people get copies of our software, the more pressure is created.

The power of enduring social pressure. The emergent will of a thousand whispers.

Inverted apps put their consumer first, and coordinate while being fractured into many pieces. inverted apps harness the inverted capital allocation mechanisms enabled by dreamcatchers to perform functions in line with the benefit of their consumers, not their controllers. Distributed apps spread the operation of an application across multiple physical machines with control held by a central entity. Almost all cloud applications that hope to offer any kind of reliability operate in this way. Decentralized apps are distributed apps that spread the central control amongst many entities, often dynamically. Whilst the control may be spread around, the central control is still fiercely present, usually in the form of a token as a central registry of intent. Inverted apps are the opposite of these forms, in that there is no central coordination of intent, but rather any central tendencies emerges, without force or registration, and are apparent when entities communicate. For example, the collection of all bitcoin chain forks is a crude form of inverted app - the forks do not communicate well with each other, but their central token registries are at least partially split from each other to serve the needs of their respective user groups, and sometimes they coordinate via exchanges where overall, the utility of cryptocurrencies of this class is enhanced. Inverted apps can easily wrap controlled apps, but controlled apps are incapable of wrapping inverted. Inverted can wrap inverted. Inverted can emulate controlled where needed. Almost all blockchains could currently be classed as perverted apps - proporting to offer freedom, but really having no more structure than a public company with central product and distributed public shareholdings. These operations have no future.

an inverted exchange is different to an exchange on a blockchain. True inversion means that any partipant can come and go if the possess commodity electronics. Ethereum for example you need to have ETH, then you need assets on the chain - the list of barriers goes on and on. An inverted exchange would let people peer with one another and find the best prices. Yes there would appear aggregators, but these would be assistants, and easily replaced at any time they stop being useful.

A new software delivery model for SaaS is emerging

Dreamcatcher aims to provide a mechanism for alternate views on all aspects of a Project not only to co-exist, but to combine to improve that project and all Forks of that project.

This stems from the belief that it’s hard to see individually what particular opinions are correct ahead of time, and that the more outlandish opinions may often be the most valuable. It also stems from the belief that in gathering many opinions, de-duplicating and combining them to become more precise, and by combining the judgement of many people in deciding their worth, we’re maximising the chance of making the right decisions.

This approach is across the board. It applies just as much to how a Project is governed, how it’s funds are spent as it does to what work should be undertaken and whether it’s complete.

That is, the method of consideration needs in itself to be open to opinion and consideration.

This is important because, generally, the closer you are to the work, the clearer your thoughts on the appropriateness of that work. Likewise, the closer you are to the overall goals, the clearer your thoughts are on those. The DC needs to capture both, filter and apply wide knowledge on assessing them.

We want to be able to capture the fringe ideas because that's where the big gains come from. We also simultaneously want to manage a wealth of fringe ideas without being paralysesed when those ideas are incompatible with each other.

The Principles are:

1. Give us everything. It should be free and easily done to raise any level of idea, from all levels of the project from the work being done to how the project is being run to the Wishes the project is pursuing.
2. Then to be sensitive enough to detect which ideas are valuable, and to amplify and act on those quickly. We do this through de-duplication and merging to sort out the noise, and amplification of those views that stand the test of peer-review scrutiny.
3. And where agreement can’t be found, give an easy route to Fork the Project, explore both stances to see which one is actually the better, and allow a merge back in preserving the history of both.

By doing this, the speed of the project to react to new circumstances or new knowledge is maximised, way beyond any traditional project structure.

Dreamcatcher is the home for all of those lone-wolf, smart guys that have so much untapped value, but which are drowned in the rigid structures that are currently used to produce stuff.

"AMD Silicon" covers wide range too:

1. circuit designers
2. silicon fab
3. supply chain

Our applications must be easily portable to this mode of operation

Need to move to open silicon, with trusted fabs

If cloud@home then the workload is rapidly relocatable, and so the customer may choose to run some base load on prem, have other load on cloud@home, and sell their spare capacity on cloud@home

cloud@home makes use of idle resources, and shares yours out too. you can have enough resiliency for standalone operation in a disaster, but can rent this capacity out when not in use

Show diagram of comparitive trust chains, latency, cost, fault tolerance of cloud configurations

https://www.theregister.com/2020/07/14/google_amd_secure_vm/ So your chain of trust can now be as short as "AMD silicon", Which paves the way for cloud at home type scenarios where renting off a home supplier has the same security guarantees as renting off a cloud supplier

event driven workloads designed for distributed storage - so the workloads would have to be designed specifically for cloud@home unless its just small little apps

"Mirror mirror, on the wall, who is the fairest of them all?"

Contents

1. Example project funding of Interblock
2. Example project funding of DOS

Software companies make up trillions of dollars on the stockmarket, but the best quality software is actually free - how can we connect these two extremes to something more sustainable, and how can we get more software, of a higher quality, faster, and cost lest money ?