IRC channel logs
2023-04-15.log
back to list of logs
<shaungilchrist>is there a way to move an actor from one vat to another or do you live and die in the vat you are spawned in? <RandyFarmer[m]>What would the use case for that be, shaungilchrist ? One could create a handoff protocol between actors across vats at the app-level, but what would actor migration actually mean? What about messages that are already being routed to a specific vat? <RandyFarmer[m]>Mirgrate unum? When I worked on Unums back in the ol' days, that's what we had Presences for - each vat had a presence. If you wanted to change governance policies, you'd handle that in the presences. <RandyFarmer[m]>I'm probably way too far off in my oldschool thinking, so don't mind me no nevermind - but I'm still interested in what "actor migration across vats" is... <Zarutian_iPad>basically, each presence can become the authorative one as I understand it <RandyFarmer[m]>That's having the Unum decide what's what across it's presences in different vats. <shaungilchrist>Honestly thinking about a player moving between rooms in a MUD and then that crossed with what I had been learning about vats in spritely. <juliana[m]>If my understanding of unum and presences is correct (keeping in mind that you can't tell people anything), wouldn't that be a case of creating a new presence (and presumably destroying the old one at some point in the GC cycle)? assuming each room is represented by a single vat, which doesn't necessarily have to be the case <juliana[m]>in actor/vat terms, what I suggested was that you would create a new actor in the new room vat, then let the old actor be garbage collected at some point. but there's not really any need to do that because you can use actors that aren't in the same vat with relative ease. I suppose it might be useful to create a local proxy to resolve promises from remote actors so you don't have to worry about doing that manually? there's still no <shaungilchrist>right I was just thinking about MUDs and my brain was like "what if each room was a vat and the player moved betwixt" and thus the question. Thanks for the quick answer! <juliana[m]>way and have multiple vats in a single process). but doing so at the granularity of a room probably isn't necessary <juliana[m]>you're welcome! I'll stop talking now. I just had coffee which was probably a bad idea so now my brain is going very fast <juliana[m]>this is the first I'm hearing of it, but given that it was invented to described the actor model, it's unsurprising there seem to be similarities <vvvvmvr[m]>i have to reread the unum page again because it was interesting but i didn't quite grok it <juliana[m]>oh, also - folks here might be interested to know that the Megaman Batle Network Legacy Collection was released today. I mention it because the vision of cyberspace it profers in the eponymous battle network entranced me because it reminded me of an earlier description of one possible cyberspace put forward by this company called Electric Communities. here's hoping we can still make something like it a reality - although maybe without all <juliana[m]>the villains seeking to destroy the world, yeah? XD <flatwhatson>presence in a MUD room is interesting, it seems difficult to prevent a player from inhabiting multiple rooms simultaneously in a distributed dungeon <flatwhatson>maybe if the rooms did a hand-off of your presence? that kind of models the doors/directions/portals from a room too <flatwhatson>it would mean you could get "lost in space" if you're inhabiting a room which gets disconnected <flatwhatson>i guess a respawn mechanice solves part of that. and maybe you could find your "corpse" and retrieve your gear if that room comes back online <flatwhatson>hopefully not, but we need to be able to verify/prove the good behaviour of an object <flatwhatson>a character's respawner/liveness state could be kept on their machine, if we could ensure that it didn't cheat and maintained a single live instance <flatwhatson>maybe just trust them, and rely on activity monitoring to identify & exile cheaters <flatwhatson>ie. nodes monitor the activity of their peers for weirdness <flatwhatson>think about a tabletop D&D game where someone is lying about their HP. an astute DM will get sus quickly. <RandyFarmer[m]>We solved problems like these all the time - for values of "trust" that match the risk. <flatwhatson>a reputation system, and reputation-gated zones, are already MUD mechanics, but somewhat solve this too <RandyFarmer[m]>Each "region/context" are potentially hosted on different processes on different machines. Just like the original Habitat. <RandyFarmer[m]>We used Elko when we re-coded the Habitat server for the neohabitat project. In that case I had to create a "bridge" to keep the session with the c64 open during region transitions. <RandyFarmer[m]>Elko has an unum-like object model - even though it uses conventional messaging. <RandyFarmer[m]>NeoHabitat's bridge replaces "client foo" in those diagrams, and introduces a seperate persistent connection to the emulated 64client. <juliana[m]>what do you mean when you say conventional messaging? 1-to-1 messaging between objects without the various broadcast mechanisms of the unum pattern? <flatwhatson>it seems like director is a point of centralization there? i'd like to build something which avoids that, or at least allows multiple directors to exist <flatwhatson>each client would just be another peer in the network, with the ability to spawn any object (rooms, characters, items, proxies, etc.) and interact with other nodes <flatwhatson>spawn any object *locally*, and advertise it to other nodes, but if their machine goes offline so do their objects <flatwhatson>we ship a standard codebase, which implement protocols for "being a character" or "being a room", but you could hack up whatever and spawn it on your node <flatwhatson>very likely flawed as the basis for a "fair" game, but maybe a fun experimental platform <flatwhatson>there would be a main trusted node(s) with well-regulated behavior, but someone could invite you into their creepy self-hosted dungeon :) <RandyFarmer[m]>Watch for the EC Habitats open sourcing happening later this year. Until then, watch this video of it's demo back in '97. Coming again soon. <RandyFarmer[m]><flatwhatson> "it seems like director is a..." <- Elko has multiple directors support. It's left off that diagram for simplicity. Please, if you're interested, dig deeper. 
