There will be a process that looks for any object with a framecode observable. When it sees one, it looks in Stash (our shared network folder) for a folder whose name is that framecode id (an 8 digit hex string). Then for every file in that folder, it will publish an observable on the object whose value is the data of that file.

This way you can easily create e.g. video coasters or music coasters by printing a new framecode and then dropping the mp4 etc. in the appropriate folder. The research gallery could associate stickers/foamcores with documentation on the project.

You can also create program coasters similarly, this time dropping lua files in the folder. A separate process looks for coasters that are activated (e.g. with a go stone) and then runs any observables that have "process" in the name, or some similar convention.

That's the gist, we can adjust the details. For example we might not want to couple the framecode recognizer so tightly, or at least allow other ways for objects to get associated to folders.

The above system provides a bridge between Realtalk and the virtual file system. It means you can edit files on your laptop (using any editor) and the Realtalk world will update live. Also, you can wish for a file to exist in Realtalk and the file system will change appropriately. The file system, like physical reality, is just a container for state. It is helpful for me to imagine the file system as a physical hard drive, a piece of physical reality, that you can observe and effect. This squares nicely with the conceptual underpinnings of Realtalk.