R12 Atomic Economics
Strategic Intent​
All software objects have economic forces shaping their construction, instantiation, evolution, and demise. Some of those forces are on the software code that makes them
Make a diagram of the economic forces on a Dreamcatcher object and how it interacts with the machine that made it.
Contrast to the forces on conventional software objects
every object also contains a link to governance, and to global energy markets and computation markets, which shape the objects behaviour in an often hidden way.
Our object model should be able to model the energy markets and computational markets that run our objects, allowing an internal representation of the external world that contains us, and allow interaction and decision making based on this information.
This model should describe why datacentres pop up for conventional programming.
Should show:
- upgrade of interblock
- downgrade of interblock
- upgrade of running software, in presence of dispute
Conventional objects, to be useful, need to be persisted, then scaled - these are simply investment hurdles that need overcoming
The attribution trees of conventional objects contain within them the seeds of their own destruction. Because they block their utility meeting the paying customers, but leave a large hurdle, once they achieve any kind of significance, they are constantly subject to competitive attack.
The powerful structures learn to fight competition before it rises through suppression or assimilation, but surely this defers the inevitable.
Below is a discussion that needs to be processed into this Request:
mcnasty — Yesterday at 1:04 PM @rexmondo what is the form of completeness where a system can model itself, is aware of itself, and can interact with other instances of itself ? take ethereum for example, can any program be represented in solidity ? maybe - probably. Can it reference itself as a model, or interact with other instances of itself ? no, since it has no concept of such things in the language, and I cannot think how they could introduce that in without making it so different as to be unrecognizeable. I also think that the rate of change of the solidity language is so slow as to be considered non-existent, so it will almost certainly not expand to have this ability, this ability to reflect upon itself. I wish there was a feature list for programming languages - I think it would include reflection, asynchrony, multithreading, remote invocation, persistence, throwing errors - what else ? rexmondo — Yesterday at 1:16 PM In lisp they called it homoiconicity Meaning the language was expressed entirely using data structures for the language, so the language can read its own source code like it can read any data in a program Generally the suite of features I think you’re referring to here is called meta programming mcnasty — Yesterday at 1:18 PM I found this list: https://en.wikipedia.org/wiki/Comparison_of_multi-paradigm_programming_languages Comparison of multi-paradigm programming languages Programming languages can be grouped by the number and types of paradigms supported. rexmondo — Yesterday at 1:19 PM Yeah that list looks good I think theres possibly a more mathy term on the top of my tongue I’m gonna need to think about mcnasty — Yesterday at 1:53 PM I'm just wrestling with the notion of being able to wrap other chains. Surely if you can wrap any other chain, including yourself, then you have significantly more operational power than the other chains ? and just like ipld can wrap anything, such a chain should probably only be done once - like there isn't much point having several different types since what would their advantages be over each other anyway 🤷 ? I mean there aren't any competitors to IPFS that I can see, really its kinda like "welp, that solves that problem" rexmondo — Yesterday at 1:56 PM So as I keep saying, I think the ultimate power of a blockchain will probably prove to be auditing Wrapping a chain for a finite sequence of blocks in order to make some sort of statement about what was observed in that sequence is like moving the auditing process in-band In fact, to me this suggests the entire validation process could be looking at alternate possible sequences of blocks I think the whole chai in chain thing has as much possible power as the stream in stream thing that libraries like rx promote mcnasty — Yesterday at 2:00 PM but I want it deeper than that - that's like saying "the ultimate power of xyz language will be its debugger !" but really, all languages should operate on the blockchain model of actions, replayable actions, snapshots, then signatures its' about taking a bunch of different concepts to their conclusion - like docker containers - I don't want the whole OS I just want my single covenant isolated storage - I don't want a whole table, I just want my chain backups - I don't want this incohesive dump - I just want my data and I want to access it programmatically and natively rexmondo — Yesterday at 2:04 PM Yeah I see what you’re saying mcnasty — Yesterday at 2:04 PM ultimately I want to see silicon that is optimized for this way of operating because it has potential to be massively parallel rexmondo — Yesterday at 2:05 PM Things get tangled up with their context and they really shouldn’t Context free compute mcnasty — Yesterday at 2:05 PM I hear some of the erlang guys lamenting about these things - they don't want faster cores they want more cores. They don't want bigger ram they want more isolated ram units yes context free rexmondo — Yesterday at 2:06 PM I think if other industries realized the amount of time devs spend just getting the env worked out to try some new tool they would gag mcnasty — Yesterday at 2:06 PM ipfs gives us some of the context freeness - we need to provide the missing compute bit on top rexmondo — Yesterday at 2:06 PM It’s like if you were building a bridge and you spend the first 30% of the project designing your own bolts Like why would you ever do that Just use the same bolts as everyone else It’s not like you’ll want to be stuck maintaining the bridge forever mcnasty — Yesterday at 2:07 PM gosh that is shameful when you put it like that "Hey for this project we're going to try something nobody has ever done before" "ORLY ?" So Dreamcatcher would be like putting a toll on said bridge, and paying out to anyone who maintains the bridge in the future I imagine it would be quite well maintained. Well I hope so, at least. rexmondo — Yesterday at 2:09 PM Also, it should be more than maintained It’s should be made of as many’s standard pieces as possible so when the state of the art changes it can be upgraded in a predictable way by someone who didn’t build it We need to free compute from computers mcnasty — Yesterday at 2:10 PM yes thats exactly what we want rexmondo — Yesterday at 2:10 PM So that we can talk about the raw atoms of compute Why is there 18 dialects of sql when everyone uses json in ram Why do you need to load a framework to ask 500 computers to perform a big task in parallel mcnasty — Yesterday at 2:12 PM I believe its because in the closed source world, you could make money by being slightly better. In the open source world in which blockchains must operate, you cannot make money like that rexmondo — Yesterday at 2:12 PM Why are the primitives in programs things like bools and ints. Why aren’t they processes? mcnasty — Yesterday at 2:12 PM yes - why is asking 500 computers so dramatically different from asking the next core, or even the next thread ? oooooooooooooooooo now you're talking the process primitive or rather, object primitive, since it has persistent state and can be network transmitted and queried rexmondo — Yesterday at 2:13 PM Yeah for sure I think we need to make the bolts and riveting and welding of the programming world It’s shameful they haven’t been made yet It should be trivial for any moron to make a web scale business mcnasty — Yesterday at 2:19 PM Using this type of diagram I have been trying to find a way to make a specification for interblock - like an RFC - that asks for these algebraic like interactions between object primitives, and then maps each one to various aspects of object oriented programming. But it goes further than conventional object oriented in that it pulls in multithreading, scale, persistence, transmission, queries, upgrades, security, and history as well.
Then, to take it all the way, I wanted to spec the financial aspects of program construction and maintenance / expansion as well, in the same algebraic type way, saying that the economics of constructing apps using serverless object primitives at its base should follow a standard model, since the bottleneck of computing is rarely cpus, and more so programmers, and most of all business folk and economic forces. mcnasty — Yesterday at 2:19 PM I need more 100% emojis to indicate my agreement... rexmondo — Yesterday at 2:22 PM Honestly, the idea of a visual and algebraic dictionary of financial primitives sounds like something I wish I had when I was 12 years old I would be in a way better place now lol mcnasty — Yesterday at 2:23 PM the hardest part of programming is the economics of it rexmondo — Yesterday at 2:23 PM I would say the bottleneck of programming is making the business folk understand the devs and vice versa A Rosetta stone for that would actually change the world mcnasty — Yesterday at 2:24 PM i think the problem is the business folk even being there in the first place lol basically I think we can describe the dreamcatcher in terms of operations the smallest possible dreamcatcher serverless object is capable of. So all the object functions I outlined plus attribution to the code commits it ran on (including interblock itself) and attribution to the execution of that object, and attribution to the information the object represents rexmondo — Yesterday at 2:41 PM Yeah I think I’m seeing it The primitive transformations plus their dilution basically mcnasty — Yesterday at 2:42 PM what do you mean by dilution ? rexmondo — Yesterday at 2:43 PM In the cap table sense I guess Since change is a response to external stimulus, building things is mostly a process of dilution of interest Like adding more and more external expertise until an ideal outcome is achieved mcnasty — Yesterday at 2:44 PM oh ! yes I get you every single object has to have certain basic features to be useful, and is subject to certain economic forces, which can be expressed on a per object basis in the current paradigm that would be hard to calculate as it isn't built in to the stack and worse, things like persistence are not accounted for on a per object level anyway, further complicating the per object accounting code attribution is done using tools that amount to just pen and paper and revenue per object is never shared directly with contributors in order to induce further future contributions from new and old people mcnasty — Yesterday at 2:59 PM The more I think about Dreamcatcher as both cleaning up the object model of programming by standardizing the nuts and bolts and welds of the stack, and also providing a per object method for complete lifecycle management including financial investing and incentives, the clearer it gets 🤷 what are large programs other than collections of smaller objects, each object subject to those same forces... that introspection that I'm grasping for is the ability of a system to model its entire supply chain, and be used in its own operational management rexmondo — Yesterday at 3:12 PM Yeah, I like this. It’s like row level access control on steroids Persistent tracking of stakeholders at every moment in time of even the most fine grained datum mcnasty — Yesterday at 3:14 PM yeah - automatically and from day 1 rexmondo — Yesterday at 3:31 PM Persistent tracking of stakeholders at every moment in time of even the most fine grained datum mcnasty — Yesterday at 3:58 PM Persistent tracking of stakeholder provenance at every transition at the most fine grained datum ? rexmondo — Yesterday at 3:58 PM Yeah mcnasty — Yesterday at 3:59 PM its not the stakeholders we're tracking, its like where did they come from and how much did they contribute. and its not "of even the most fine grained datum" because its only the most fine grained datum rexmondo — Yesterday at 3:59 PM Yeah that makes sense mcnasty — Yesterday at 3:59 PM Persistent tracking of contributor provenance for every transition at the most fine grained datum or did stakeholder capture something more ? I don't mean to kill your statement - I'm just trying to bake some of our core concepts in there tighter If I said "Persistent tracking of contributor provenance in every block" - what would have been lost compared to your statement ? because every moment in time for us is every block, and the most fine grained datum is a block, too, so like... combine ? rexmondo — Yesterday at 4:06 PM Contributor I think is tighter So I’m grasping here a little bit But mcnasty — Yesterday at 4:09 PM I think it is a Dreamcatcher Object if it contains within it these automated lifecycle management abilities rexmondo — Yesterday at 4:09 PM I think there’s a sense that stakeholder might be meaningful too mcnasty — Yesterday at 4:10 PM yeah stakeholder seems more encompassing rexmondo — Yesterday at 4:10 PM Data always exists because someone chose to record it mcnasty — Yesterday at 4:11 PM and I think collapsing time and datum into block loses the contrast to the conventional way of thinking about stakeholder tracking, which is always time based and large datum based rexmondo — Yesterday at 4:11 PM Patterns in nature become data when a person tries to attach a causal narrative to them I always think of it from the science perspective that I don’t own something just because I’m trying to think about it and understand it in a narrative sense Contributor I think implies some sense of ownership somewhere Stakeholder just means I care rexmondo — Yesterday at 4:13 PM I like this idea of unifying time and data I have to play with it in my head a bit mcnasty — Yesterday at 4:15 PM I think "updating" is better than "tracking" as it implies a liveliness about it rexmondo — Yesterday at 4:15 PM Yeah, and it’s less creepy mcnasty — Yesterday at 4:16 PM lol "Persistent updating of contribution provenance in every object block" ? rexmondo — Yesterday at 4:17 PM Yeah
Further discussion:
mcnasty — Yesterday at 11:27 AM @msm @rexmondo this is a crude attempt to describe an atomic model of the economic forces acting on every programming object. These forces are there on all programming objects, but in Dreamcatcher objects, we interact with those forces directly, per object state transition.
Black circle is a block in a blockchain
Red arrow: attribtion paid out to 3 types of contribution: 1. Code contributions, including Interblock and Dreamcatcher 2. Energy contributions - the hardware and energy required to execute this state change 3. Symbolic contributions - contributions to whatever real world thing this object models, if anything
Yellow circle: By making the Red attributions open to redirection by future contributions, the yellow circle represents an incentive to future contributors to improve the current object, that they may receive red arrow contributions. This is an attractor. In subsequent blocks the Red attribution payouts pay to a previous future contributor, indicating how the incentives work. Image rexmondo — Yesterday at 4:44 PM The yellow one seems like an attractor that would actually steer the whole chain mcnasty — Yesterday at 4:44 PM that's the hope rexmondo — Yesterday at 4:44 PM At first I thought you meant attractor in the sense of pulling attribution But I think those two things must impact each other mcnasty — Yesterday at 4:45 PM hopefully inducing contribution rexmondo — Yesterday at 4:45 PM The yellow is like a probe into unexplored state space mcnasty — Yesterday at 4:46 PM yeah an invitation to contribute these forces are on all programming objects - conventional included - but the attractor is blocked in artificial nonfree ways, as are the attribution payouts rexmondo — Yesterday at 4:48 PM Like vendor lock in and ip ownership mcnasty — Yesterday at 4:48 PM the Dreamcatcher model aims to make those attribution and attraction be direct, and subject to a free market yes exactly rexmondo — Yesterday at 4:49 PM The diagram is actually really helpful, thanks for drawing mcnasty — Yesterday at 4:49 PM ok thanks rexmondo — Yesterday at 4:49 PM I think the open question for me is how explicit is the yellow thing and what does it look like mcnasty — Yesterday at 4:49 PM its getting clearer for me, what we're doing. still needs some work obviously the yellow thing is connected to the Dreamcatcher rexmondo — Yesterday at 4:50 PM Which is the place where people describe what they want mcnasty — Yesterday at 4:50 PM sorry thats super ambiguous.... connected to the Dreamcatcher marketplace of requests, ideas, labour, and funding so this model provides more direct connection in that the consumers of objects can directly indicate what they want changed, the labour pool that can enact those changes is open to the whole world, and the funding ability again is open to the whole world, with the payout for improvement being connected directly, automatically, to those who do the improvements rexmondo — Yesterday at 4:52 PM Lol no it’s all good I think I know what you meant mcnasty — Yesterday at 4:54 PM in contrast to conventional programming object, the consumers are connected through the product manager who marshalls their requests for change, then the labour is restricted to employees of the company, then the funding ability is closed down further to the business owners making decisions, with the purpose being the business owners take a massive cut of the hopeful returns from construction and improvement so we build company structures that choke the machine something fierce, in the hope that we can get a larger cut than the investment we had to make rexmondo — Yesterday at 4:55 PM Which is like searching the design space through a keyhole mcnasty — Yesterday at 4:55 PM if there was ever a way to not build an engine, software construction companies would be the example to use rexmondo — Yesterday at 4:55 PM Yeah it’s like 100% backwards And I say that as someone that is doing product work and marshalling user requests actively mcnasty — Yesterday at 4:56 PM plus, we get some second order social benefits - engagement, ownership by the user base, enthusiasm - all those good social capital things I think that whole story can be illustrated by considering a single Dreamcatcher object as it goes through its complete product lifecycle, including financing, then saying that larger projects are just collections of objects. rexmondo — Yesterday at 5:00 PM Yes Yes yes yes mcnasty — Yesterday at 5:00 PM then a contrast to the lifecycle of a conventional software object, highlighting the restrictiveness of the process, and the inefficiencies of the capital allocation, with some sort of gesture towards high chances of failure and high costs rexmondo — Yesterday at 5:01 PM In fact I believe that so strongly that if that wasn’t the case I would say you’ve designed something wrong rexmondo — Yesterday at 5:02 PM “Inefficiencies of capital allocation” to me means people buying shit they actively disdain, such as the attention of the unwashed masses, because they think it will make them richer It all seems much clearer to me than it did a few years ago If you actually care about what you buy, for its own sake, rather than as a speculation vehicle, everything is flowing in the same direction It’s no wonder we dont have the bolts and riveting of software collectively worked out in the current incentive structure mcnasty — Yesterday at 5:08 PM bitcoin as an API has outlasted most software products I can think of. Hopefully we'll get this right and it will last a long time too - like what else could it possibly need to do 🤷 and if we the initializers of the project are subject to the same incentive model, there's really no point trying to make a separate and competing system - its more energy efficient for each individual to contribute to this larger thing, keeping all the bolts and welds the same anyway, I'll keep pushing forwards on that atomic diagram - it is both a good explanation of the overall system, and also a demonstration of the granularity we operate at mcnasty — Yesterday at 5:31 PM Also that atomic model won't just be a diagram, but will be observable in the live operations of each Dreamcatcher object Further, we can use our objects to model conventional objects and track and compare their incentive structures and dispersal routes