Development ideas to think about. For STEEM, for EOS, and beyond.

Computer science time. Let's dance.

 

— 〈  1  〉—

The simplest way to do introduce a powerful new use case on an existing decentralized the-code-is-the-law blockchain is literally to dump code as text into a memo in a block.

Take as many posts as needed. Linked sparely by glue text that can be sniffed, and catch with a bot on a front end.

An indeterministic search by several front end processes will sufficiently quickly find and order the pieces regardless of what order they are found.

(Each piece may contain gluing code that suggests the location of some others, creating a search gradient, with other glue text sufficient for virtual content rather than location based search. And priority indicated both by A > B in some numerical sense if A ≺ B and by A = (a,b) while B = (c) making it approximately clear that X-a,b ≺ X-c even if we don't look inside a, b, c, to numerically compare them and gain speed.)

Relatively fast. The front end has a guard of several heuristics that decides what kind of code is in which post.

Maybe just an image or postscript as binary as text which merely needs to be loaded in memory with its extension restored to be viewed and navigated. But what I'm thinking is something like Smalltalk/Squeak/Pharo images. Yes: on the blockchain. Archived. Permanently.

Users of the front end can input Smalltalk commands to an image living inside the blockchain that can be loaded in pieces. Loading in a mimimal kernals and actors one by one as needed, each actor requiring one or sufficiently few posts to be loaded sufficiently quickly. The code is live.

The request is also posted to the blockchain.

Output is either displayed. Else it's self timed and when computed the result is posted in the blockchain. And the image is unloaded. Both also permanently archived. A pragmatic self timed operation on a distributed system much like asynchronous microprocessors.

The requesting user can search for it.

May exist a form that reduces the load on the front end. Queues or systems where a request is sent by the front end to some forwarding bots that pass the message randomly and mark it when passing and when a marked request is returned to the front end only then it's processed.

All this allow users to request appropriate actions and do-its while that code is loaded in memory.

Pieces are loading once the user takes an action. A further action is making a transaction of the blockchain with a memo posted. This is for more complex operation than just viewing or reading an image distributed as small blocks.

Blocks being small and many allow parts of images to run even without the whole image being loaded. Small pieces are loaded in one of several gluing orders depending on the request and the image can be navigated as "logically proximate" pieces are loaded before "distant" pieces relative the do-it are loaded.

Maybe the use is just simply viewing, zoomed in, some detail of an enormous canvas, and panning and zooming in and out.

In general this is asking to compute something, which the front end then posts, or in the special case merely displays, or adding to the image.

Let's consider this again. The system is self timed, results that must be posted are posted when they are done. Not earlier. And not later. Order is not predetermined. The user then searches for them. On the chain. Code as text can be added: glued to the original image by the right glue text in the memo, for example. Something is missing.

Yes: to prevent abuse by somebody later gluing something harmful, post and their links are signed. Another user cannot fake certain links which only another user, such as the original poster can make. Which is already true on the Steem blockchain. Lovely.

The original poster must then post a gluing post, linking to whoever added code as text to a graph and has their own name in their memo headers and signed their own name.

All this can be automated on a sufficiently powerful computing system. The bot can pass to systems living on the front end server, which can do some work, then pass back to the bot.

Only limit is that if you need a long continuous section of code, you must wait longer.

Because small pieces are loaded. Probably would work best with some variant of Smalltalk. Hmmm.

Would work on any blockchain were transactions are sufficiently low cost and fast.

Both on STEEM and EOS. Which brings us to the next point.

 

— 〈  2  〉—

I'm liking STEEM and SMTs more than EOS at the moment.

Never thought I would say that. But it seems, and I could be wrong, Tom and Dan have possibly recreated the possibility of arbitration for literally every action in retrospect!?! If so, then expect to see the equivalent of strategic "lawsuits" done by less scrupulous actors to get a piece of other users's stake as the next step in flag battles on EOS. It may be that Steem flag battles have been prevented on EOS at the cost of frivolous and strategic arbitration battles. Which is worse?

There's a reason why centralized legal systems are breaking down ... ! What was the point of adding the equivalent onto a blockchain ... ? And then arbitration means posts are not really archived. Steem posts can be flagged; and some may be hidden. But they cannot be easily deleted or edited. For better or worse. Arbitration and vested interests brings up a whole level of mess and risk. Code as law is safer because it has useful side effects such as genuine free archiving. The whole point of blockchain is that it cannot be edited easily. Even if an arbitrator says it must.

What it seems to me is the best feature of Steem is that it's the digital equivalent of paper; once somebody like Heinlein printed the concept of a water bed in a novel, it's prior art that cannot be easily and conveniently rid off by prospective manufacturers who'd like to patent the water bed. Either they have to secretly pull off burning millions of distributed pages of text, proving they were not the first to create such things and disclose them, or they cannot patent the water bed. They did not patent the water bed.

But the internet is malleable. It's not like ink on paper. This means pieces can easily modified if desired. That's good and convenient — creates some excellent use cases.

The internet is malleable. It's not like ink on paper. Pieces can easily modified if desired. That's bad and inconvenient. Eliminates some excellent use cases.

Who wants to say anything about the excluded middle?

Something like Steem on a blockchain where code is law has the nice property that it has lower transaction costs than ink and paper — but it mostly replaces and improves on ink and paper.

I would like to see the arbitration stuff and Ricardian contract more limited than it is; because it's not worth sacrificing freedom of speech that comes from permanent archiving, especially where vested interests will eventually arise and work against it, to make a platform a little more convenient to use and a little more valuable. Risk that past blocks can easily be changed anytime in the future somewhat eliminates the beautiful paperlike nature of decentralized blockchains. And suppose somebody publishes somethings that is true ... and completely contrary to the interests of arbiters? For example competing technology for another blockchain. Can that be deleted on EOS and tokens removed from the publishing account if somebody requests arbitration ... ? There's your Goedel argument.

What it the best case is that Tom and Dan will think about this some more and retain the simple and pure benefits of Steem some other way than simply recreating the bureaucracy of governments on a blockchain. Governments already exist. Do not reinvent the wheel. Especially if the system being reinvented is completely broken and never worked in the first place? That whole worthless maze of arbitration combined with stake and interest has been commented on and found entirely and easily gameable by Wright Mills, Lewis Mumford, William Burroughs, Mancur Olsen, and others, and systems to which their devastating arguments apply are unproductive and counterproductive or soon become unproductive and counterproductive.

@eftnow comments: ``Yup — the last thing we need is recreating governments. Surely, what we are trying to move away from with all this.''

Exactly.

Tom and Dan realize that ... Surely ... Or maybe not.

We can hope that, if they don't realize it now, they'll realize this soon enough ...

Correct: the whose point of blockchains having the-code-is-the-law, with small leeway be consensus forking, is to avoid nonconsensus operations like arbitration, and all the costs and risks associated with that. Legal proceedings are too costly (and risk is a cost). Paradoxically to have a system where all have law there must be no legal system at all.

Imagine having a running lawsuit with a much larger stake; they will just start as in the broader world two or three strategic but frivolous lawsuits against you ... and you may yet lose some of them ... because you cannot fight all of them ... so you settle or lose your main lawsuit ... or win ... but lose anyway.

Rule of law does not exist for most people in a system where arbitration has cost ... and it always has cost ... risk ... and there are significantly different stakes.

It's difficult to win even when correct against a large stake that seeks arbitration in its favor ... and risky for a large stake to remain on the system ... where thousands of frivolous arbitrations are initiated against it ... because most will lose but a few will win and there is a large stake to receive a cut off.

Harold Morowitz once wrote that for all practical purposes (FAPP) most persons in our system don't have rule of law anyway because they can't afford rule of law, it's FAPP and the pretense of rule of law plus at the same time the dependence of the system on it means the system simply does not work.

Dan's great original idea with Steem was that you make a low transaction cost system with little risk the foundation of a social system so that everybody has access to the law by eliminating what is costly and risky from the system ... government. ... Which is always permanently captured by vested interests ... There's always a pure dominant strategy.

Requiring strict consensus for changes left the system yet gameable, obviously, but all the same, it's much less gameable than any legal system, must less gameable than really any system of government.

There opens up, worst case scenario, a market for cross chain posting, say posting from EOS to ETH or BCH or STEEM to make permanent some documents. But that creates a massive transaction cost for those who use the blockchain for its useful property of archiving.

Let's wait for somebody, however, to ruin that too, by opening arbitration against somebody else for permanently archiving something from the EOS chain they would rather was not permanently archived and the archiver having their EOS stake confiscated. ``There is nothing new in the world'' goes one book.

I'll analyze what it means for a blockchain to allow later transactions to modify earlier transactions. See some problems.

Will write up a model later.

 

— 〈  3  〉—

Rather than focusing on the bad let's focus on the good.

There's a way anybody can make their own subtokens on a token, somewhat differently than SMTs, the official variant.

All you really need are seal and unseal operations which must typically performed by PKC; but on a single system with shared memory, such as a blockchain, where every actor capable of transacting is glued to the others via PKC, that just means a simple locksmith object to encapsulate things in a clever way, not a further complex layer of PKC.

I repeat: everyone is already as if on a single large system. On single system ram. Glued together by the underlying seal and unseal operations of the underlying decentralized blockchain. In this case Steem.

Various parts of the locksmith object are shared and other parts encapsulated in turn in various independent actors (MIL87). Lo! you have seal and unseal. And you can make a subtoken that lives inside the underlying token. Anybody with the underlying token and participants can create a consensus subtoken.

Safety of the locksmith would increases as more different and independent users go and use it and each encapsulates a piece and transactions must pass through their actions. The rest is something like steemauto. And you have something like SMTs but not SMTs.

©2018 tibra.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License  . . .   . . .   . . .    Text and images: @tibra. @communicate on minds.com