Mastodawn

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

/via nu.federati.net/notice/3374985
> From Carl Sassenrath, the creator of #Rebol ( www.rebol.com/ ), which was the inspiration for #JSON ( www.json.org/json-en.html ), comes the #ASON data format and the related #Altscript ( altscript.com/ ) language.

>> ASON is what JSON was supposed to be. It provides an extended set of data-types written in a natural way, the concept of symbols (variables), a cleaner leaner syntax, machine-independent executable expressions, and lightning-fast parsting input to your favorite programming language.> Well, nothing is available for download yet, but he’s announcing that it is coming.‌@lnxw48a1

LinuxWalt (@lnxw48a1) {3EB165E0-5BB1-45D2-9E7D-93B31821F864} ([email protected])'s status on Monday, 09-Aug-2021 06:37:52 UTC

Federati Nu: Federated N-series GNU Social

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛Aug 12, 2021

Re: mastodon.social/@natecull/1067…

@natecull The reason I brought up Rebol was because of this #AltScript / #ASON link that @lnxw48a1 posted the other day.

nu.federati.net/notice/3374985

LIBRANET.de | Search

@clacke

ooh, ASON. Looks interesting! Anything has to be better than JSON!

@clacke @natecull actually, this reminds me. Nate: you would probably really like the project that inspired the PORDT approach I want to use for data replication over welkin terms:
https://replicated.cc/

Replicated Object Notation — RON

Interesting project! I can't say I love its native serialization format. But that's okay. I guess people can use JSON instead.

I keep going on about syntaxes and serialization formats because _we spend so much of our digital lives inside them_ that we should probably try to make them more pleasant than they currently are.

@natecull @clacke instead I want to not spend time working directly in serialization formats. preserve structure in your editing environments. use those that are appropriate for the semantics of data you operate on, and compose them in the same way you compose that data.

@natecull @clacke the serialization format it uses is very deliberately designed to save space on the causal data/hashes it includes.
ultimately, the approach I've described differs from this only in that since welkin is a proof system you don't have to have a preset set of primitive merge functions and corresponding datatypes, you can share new datatypes around as replicated structure and use those as merges on new causal data. so everything can be replicated frictionlessly.

I do like the idea of some kind of differential object being the core abstraction. It's something I was thinking about years ago, but wasn't sure how we could encode it in a lossless manner over object-like structures (and I might still not be satisfied).

This project smells quite strongly of Bitcoin which worries me, but doesn't necessarily damn it.

@natecull @clacke it's not a cryptocurrency project, and it's explicitly anti-append-only-log type things, since you can just... not store certain causal data if it's not relevant to things you don't care about. there are a lot of cryptographic primitives and distributed systems ideas that have been developed in cryptocurrency spaces that I've ended up incorporating, but this actually happens to not be one of them. I share your distaste for bitcoin, though.

@natecull @clacke (and distaste for blockchains in general. developing computational systems to enshrine scarcity in informational realms is like one of the most evil things I can think of)

@natecull @clacke oops, *not relevant to things you care about
i.e. this is all about taking views on a notional global data structure

What I was wondering years ago was whether what RON calls a "state frame" could be literally the same structure as what RON calls a "change frame".

I am still quite interested in whether this could be possible.

@natecull @clacke they are the same. this is why PORDTs suck. unfortunately, the RON documentation is absolute garbage. you can merge over anything as long as your operation invariants are preserved (associative, commutative, idempotent)

@natecull @clacke oops. this is not what I meant to say at all. this is why PORDTs are *great*. the "suck" was meant to go in the following sentence.
what a grave error

Something like RON does seem like quite a good step forward. A simple composable cryptographically-based "change to key/value object" operation. We can reduce a lot of duplication and complexity with something like that.

@natecull @clacke we can reduce a lot of complexity with this indeed. and if implemented with the right tools with the ability to formally verify the right invariants, it can be generalized to all persistent data replication.

I hope that keys could be arbitrary (immutable) objects rather than strings, but I'm guessing maybe not if they're following JSON semantics for objects.

@natecull @clacke well, in my case the entire welkin type system carries over so your replicated datatypes can be generic and stuff. RON definitely isn't perfect, just inspiration.

https://replicated.cc/uuids/

RON's UUIDs seem quite well thought out!

UUIDs — RON

@natecull @clacke they are!

@natecull @clacke http://archagon.net/blog/2018/03/24/data-laced-with-history/ here's a wonderful nightmare of a blog post that I discovered ages ago when I was aching for something better than conventional CRDTs. I found RON through this blog post and, by extension, what I was looking for.

Data Laced with History: Causal Trees & Operational CRDTs

An in-depth exploration of a new class of expressive, performant, and intuitive CRDTs, together with macOS and iOS sample code.

@natecull @clacke "A change_frame could be an op, a patch or a complete state."
it's made explicit right here
the state_frame is just like, the "accumulator" in a way. but it can be the same data structure

@natecull @clacke it's basically a fold

Emacsen Aug 12, 2021

@clacke

At that point you might as well look at something compact and also handles records like Preserves, and specifically the Syrup format.

clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛Aug 12, 2021

github.com/ocapn/syrup#pseudo-…
preserves.gitlab.io/preserves/

@emacsen I like it! Like netstrings with some extra flair. It has the same parser-friendly-yet-human-friendly aesthetic.

Not the most googlable name, but easy enough if you can guess that there's a Racket or Python package for it.

GitHub - ocapn/syrup: Syrup is a simple binary way of preserving data on the wire, with perhaps a few extra calories.

Syrup is a simple binary way of preserving data on the wire, with perhaps a few extra calories. - GitHub - ocapn/syrup: Syrup is a simple binary way of preserving data on the wire, with perhaps a f...