I asked Kagi summarizer this question:

Imagine you built a chat system in this Parallel Reality, with the elements of a time-ordered sequence of messages that can have paragraphs and images created and posted by multiple users, all linked. how would hosting of each element of that be handled?

And, I have to say, Kagi "gets it":

In the Parallel Reality computing system described, the hosting and linking of the elements in a chat system would be handled as follows:

• Messages : Each message would be a 3D world object, composed of linked paragraphs and images. These message objects would be hosted symmetrically across the devices of the users participating in the chat.
• Paragraphs and Images : The individual paragraphs and images within each message would also be 3D world objects, linked to the message object. These atomic content elements could be hosted on any of the user devices participating in the chat, or even on separate servers.
• Linking : All of these chat elements - messages, paragraphs, images - would be linked together using the advanced 3D linking system of the Parallel Reality. This allows users to seamlessly navigate, reference, and interact with the chat content, regardless of where the individual elements are hosted.
• Permissions : Each user would have control over the read and write permissions for the world objects they have hosted on their local device. This allows for fine-grained control over who can access and modify the chat content.
• Synchronization : The Parallel Reality operating system would handle the synchronization of the chat content across all participating devices, ensuring a seamless and consistent experience for all users.

In summary, the decentralized and linked nature of the Parallel Reality allows for a chat system where the individual elements are hosted flexibly across the user devices and servers, while still providing a cohesive and interactive experience through the advanced 3D linking capabilities.

Some random thoughts. If your only representation for data is a byte string, then things work out ok, unless you want first class functions, coz now your function definitions have to be expressed in assembly packed into memory and I guess that would have to be your source code.

Even jsut sticking to classic data like JSON and pointers, the byte representation flattens what is intuitively logically hierarchical.

the cycle problem you mention is the mismatch between flat memory and a heirarchical logical representation that permits cycles. There is no 1-1 mapping between a DAG and a flat representation, but there are 1-n where the ambiguity is where you break the pointers.

At work we use pickle and later upgraded to dill for serializing runtime graphs. For python it seems like a super hard problem given dynamic function definitions and the interpretability but I guess you have closed off some of that if its a compiled language.

In case anyone is unaware, Datalog is a restricted form of Prolog for database querying. It’s been seriously, production-ready implemented in one commercial database (Datomic) and one in-progress open source database (CozoDB).

I am convinced that much of the sort of problem we’re concerned with here could be addressed by implementing most of nearly all programs in Datalog.

I released this calculang "environment" and it's code to GitLab:

next-calculang-gallery.netlify.app The readme on GitLab has more info on what this is trying to be (and not be).

In a new example you can check the logic for a calculang Fizz Buzz 🙂