2025-07-08
hi there, back again with another blog post. i didn't die, i didn't quit, i'm just not done with anything.
i haven't even changed the major vision, if anything i'm more set than i was a couple years ago. i've had little time to work on it, life has been busy and i've been researching because i was disatisfied with the results of some of my earlier proof-of-concepts.
unfortunately, 3d printing as a business has been a failure for the company and so we've backed away from offering this service-- there just aren't that many local people interested in printing 3d models that won't buy their own 3d printer or go to the library, bug a friend, etc. in a similar vein, i've had issues finding a market for software contracting in the local area. i'm not prepared to push contracting to be very big or taking projects outside the local area, but i'm not quite ready to stop offering contract work in general. we'll basically stop investing in 3d printing as a service, there will be some hardware work that could use 3d printed cases/parts-- the printers may still be useful for the company, but not as a service publicized and offered. for contracting, we'll offer light aws/backend/sre/software work when people are looking for it but we won't be pushing this as a major service for now. back to research, maybe publishing some software/games/services, maybe working on some embedded projects to demo but not quite ready for anything outside proof-of-concept or demo/internal use.
recently, i really dug into the roc language and find it to be fascinating. i think this will fit what i've been looking for. i want to run other people's code. i could run containers, lua, build a command language to use in a message stream, wasm, etc. but these all have their own issues. roc lets me set the exact capabilities users can do. i'll still probably throw it in in a container in an isolated environment, but it can't just do anything.
the language is very new, it will likely change underneath but the basic idea is make a c shared library and then dynamically link it at runtime. in the short term, we can roc build and deploy it as a separate process or container. later on, we can dynamically load user code in-process maybe.
need to build out kubernetes gateway publish an ip and use this to run services. deploy nats to the cluster, deploy postgres to the cluster (drbd/linstor?), deploy some sort of s3-type thing, libsql, maybe run some redis.
platform to connect to nats/postgres/libsql, provide virtual screen, chat, player queue, gamepad/user-io, access hashed objects, upload new objects to permanent storage, run wasm, get/put into nats stream, cron-scheduler, allow one game to provide a screen to multiple users, allow one game to provide multiple screens and assign users to a given screen, allow multiple rooms to connect into a single room merging their users according to the original host's code, ssh/web/binaryStream/localGui standard options.
provide a main.roc with all required dependencies in the same directory or subdirectories, max _ mb. Expect a Lib package at ./Lib and a platform at ./Platform. metadata listing which platform to prefer, which platforms known work/broke, which functions are used. build dockerfile with dir, platform and lib files are readonly, on-launch container pulls it's own id from env var connects to services, launches user code. dual-core with a time limit and maybe a memory limit. ideally apps can return frames at 60hz, but for epaper could be 0.2hz or for very large rooms with many users it could be 1-10hz
using zig or rust for platform code, likely new code for rest of services in same language. can link/use some existing go code but not sure if it will really be helpful. some embedded stuff might use some c/arduino code. want a single room interface that can be used across multiple platforms. gui/web may be most scalable because clients can do some work. ssh may be expensive/difficult. how to update a single screen pixel without sending the entire screen buffer? how to reduce bandwidth to stream 100+ users? RLE? for gui can send command, for ssh.. not the same. there's buffers and it's not simple. that was advantage of bubbletea go stuff it handles that for you. i'm not sure how performant that code is. maybe go can be used for ssh server stuff only? or maybe using ratatui/russh or rolling something myself? need to better understand when to use each language. app users of the platform can allow their users to provide wasm bytecode so they get user-code too.
still need a good way to store huge amounts of graph data, still idly thinking of everything as an entity including links and no technical reason you can't link to a link or link to self etc. geoNDimension namespace, global-chosen namespace, random-id namespace, hash-id namespace, an item will have rbac, edits/deletes append new objects to graph which will have new id-- items may end up with 'original id' and 'current id' in random and global-chosen.