@VeeSilverball@cryptodon.lol avatar

VeeSilverball

@VeeSilverball@cryptodon.lol

Come play pinball with me. Metaverse pinball advocate, occasional artist. http://veesilverball.tez.page

This profile is from a federated server and may be incomplete. Browse more on the original instance.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

The conversation must distinguish between data and information. There are many ways to create data that is non-informative, and much of the data being collected and generated is exactly that: it exists in a world of "garbage in garbage out". But the parts we care about and are presumed to have exchange value are generally informative. "Owning" has a great deal to do with the narrative of the information and who is ascribed agency, credit, blame or responsibility in the narrative.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

The latest with - decision tables:

https://en.wikipedia.org/wiki/Decision_table

This is a way of adding some logic on-chain that can help ensure a complete specification the first time. The primary limitation of them as a spec tool is in the description of the constraints and outputs themselves.

But I toyed with them tonight mostly because they help with stateful interface design. An incomplete table can be presented as a menu of choices, or used to inject default values.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

It's increasingly ambiguous what exactly the project is aiming to accomplish, but I'm trying to make it more focused on "what kinds of things do I want to put on-chain and how do I want to get there." And one of the big priorities is that what is on-chain should indicate truth. Therefore encoding various "forms of truth" makes some sense.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

I think I might have the interface design I am happy with, at least as a personal API. Stack machine internally, but just as a way to log and replay the concurrent actions. Python dict input externally, which can use the union operators added since 3.9 for convenient building. Verifier method for building interactive interfaces: send unfinished dict to it and it returns info.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

I still have to sketch some details but after waffling around in bikesheddy language stuff I realized that I could iterate by literally copying my existing tests and examples into a journal by hand and "feeling" what was complex about it, syntactically, automatically condensing what I felt was relevant into the notes.

After this I'll probably do a trivial application or two to see how well it works.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

Copying by hand has become the best thing I ever did for my architecture-senses. It gets me through a lot of hard thinking when I lack rubber ducks to reach out to.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

Now that has become more of a front-end thing for me, I went ahead and wrote a mockup CLI that gives helpful prompts to fill in form information, then logs the result.

> open-wallet <walletname>
ok.
> upload-file <filename> <fee>
ok.

Or

> upload-file
ok. filename?
> myfile
ok. fee?
> 100
tx ready.

Or

> upload-file fee 100
ok. filename?
> myfile
tx ready.

So the interaction layer can take orders in multiple ways.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

Reviewing the personal finance journals; almost nothing happened last year. Coding, art went in a meandering path. Things may spark up again in the Year of the Dragon.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

I've figured out how I am doing the async elements: in Forths there are "immediate", "compile", and "runtime(execute)" versions of each word. If I tag words as being "logged", then, when executed, Iog their stack result, I have a mechanism to replay those calls and therefore implement pause/resume.

This is dependent on those calls only needing to persist stack state. If those words mutate state elsewhere, the model breaks. But that can be baked in by disallowing it from logexec state.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

This also presents a model for capabilities in that logexec can only see the things you've prepared it to see: it should be a new interpreter. So if you use it for uploads, you have to prepare it with content by either writing it into a generated program, or storing it to a special "passthrough" wordlist. Likewise if you were to download and run code through a logexec, it would only see a sandbox...and it's possible to present "the result of running this program" to the user before it's used.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

I'd be quite cautious about enabling that as a "run external code" feature, but I can see it being useful to test out just for personal stuff: "what happens if I run this and all transactions succeed?"

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

I've made a successful download with (after breaking on this for a few days). My only encoding error was running MsgPack twice and ending up with an additional three mystery bytes. I've added a "you are not serious" check at encode time to prevent that in the future.

Next things: do some more tests of varied size with multiple pages, pointer structures. Then start to iterate over the library and examples I've built until I can use it for personal projects.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

The pointer structures work too. It took a minute to work through "making test data with an appropriate amount of transactions to testnet". So, large files are possible in as of today.

But this means there's just one last thing to work through before it becomes iterative polish: making a stub pointer and initiating the file download from scoped keys.

From there I am just going to be building some UX for myself for a while.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

I think my next iteration on the code will take the form of "make a code generator" as a way of cutting through boilerplate. I realized that I'm making classes and methods that aren't strictly necessary, and the way in which I'd like to produce the result is actually by defining some syntax - a project that is easier to work through in terms of "build a string" vs "build a compiler".

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

Actually, I might go the route of two customized stack machines. One for Symbol API calls. The other for wallet operations. The rationale for that being that this method will produce the shortest syntax, and let me encapsulate the gajillion async http calls.

I am just not happy with how this API works as-is, and it's mostly because of Python.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

With the introduction of the stack machines I see a sketch of an in-wallet security model using capability tokens. Something to look at later down the road - it's not really my realm of expertise.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

What I just put together: a micro Forth over Python, with the complete compile-interpret-immediate wordset, and stack manipulation words.

What I need to design now: How much processing I'm doing on the raw JSON inside and outside of the stack machine.

Because this could be "I navigate JSON with stack words..." or it could be "I design words and primitives for each type of structure".

I suspect I want to go "chunky" and wrap the code I've already built for myself, then destructure it.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

Thoughts on how can be helpful in doing structured queries:

  1. Download the MsgPack document data and load it into SQLite as a cache.
  2. Run a solver(customizable) on the data to generate derivative tables.
  3. End-user runs a SQL query

The consumer of HXYM is assumed here to be consuming the library code, and writing a personal app. But the solver can automate a lot of the grunt work for parsing the documents and therefore commoditize production of simple reports.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

I've started with testnet. After all the preliminary approaches where I simulated the on-chain actions offline, I've got a pretty clear path to just implement back-to-front as a series of short Python scripts adapting Symbol's examples to build up the hyperxym library code. The first pass will do it in a minimal way similar to the example, and then I can run back through each script for an iteration 2 and 3 that generalizes.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

Status of : Went from JS to Haxe, then finally settled on just targeting Python.

Document format remains MsgPack based. Dogfooding this by building wallet tooling around it.

File upload format revised probably for last time into "header + MsgPack doc" or "header + list-of-pointers as MsgPack doc". That will go to testnet hopefully this month.

Emphasis is currently on programming for myself first through the wallet tooling, uploader code, etc., and building up libraries.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

At every turn with this project my first assumptions, vs what's possible to do more simply, have consistently been challenged. A lot of reduced bookkeeping falls out of always having log-structured data available.

For example, I thought resuming uploads would be hard, but then I realized that any partial is already there on-chain, either in the unconfirmed or confirmed listing, and should have an identical signature, making it easy to find.

The apps I'm planning have gradually shrunk down too.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

One of the biggest issues I faced at the start was the document format, because I was still thinking in terms of web browsers. But now I've pulled that back to "just add a little bit to a general-purpose data xfer format" and it's like, boom, I can start writing things in a more targeted way for a personal app, and it doesn't create issues down the line because the core primitives will remain the same.

VeeSilverball, to random
@VeeSilverball@cryptodon.lol avatar

Hmm. I am now thinking that maybe I should do one last iteration on document format to build over MsgPack instead of my custom cell thing.

The upshot is that it makes the documents more like JSON, but with less of a size/text-encoding constraint. I can still specify Symbol types as "ext" values. And MsgPack is already implemented everywhere. It's a good container.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

While doing this work it became obvious that I should revert from the linked-list strategy to a FAT structure, because FAT is more robust to failure. This is something I wasn't able to catch because I was doing a lot of design outside of testnet.

However, I can continue with the use of MsgPack for this, and that adds some easing:

RAW. <MsgPack document>
or
PTR. <MsgPack document containing tx pointers>

If the pointer deref also starts with PTR., the downloader expands and continues.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

Some cycle detection and fork-bomb type attacks will need to be tested for. Otherwise it's pretty transparent as a way to contain documents with structured prims, links, and binary data. It hits the "light filesize" goal, and the original code needed is small, and mostly builds on previously tested and documented methods.

The remaining design is just a matter of plucking out all the stuff that deserves an ext type in MsgPack.

VeeSilverball,
@VeeSilverball@cryptodon.lol avatar

Well, I say "remaining", but I've pushed aside the lack of an application-layer HXYM spec. Still, having the protocol available is a substantial improvement over "doing whatever" with byte buffers. It'll feel like doing things the Web2 way, more-or-less, with a bit of friction around whether to attach more fields to a mosaic, or to apply indirection.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • anitta
  • thenastyranch
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • ngwrru68w68
  • megavids
  • magazineikmin
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • provamag3
  • tester
  • Leos
  • JUstTest
  • All magazines
    •