IRC channel logs
2023-05-13.log
back to list of logs
<Zarutian_iPad>which means (with love.js maybe) that same file can be used if one puts it together in such a way <fr33domlover>Are Spritely/Goblins actors tied to a network location? And is there a plan/vision/intention for having them not be tied to location? <fr33domlover>By location I mean actors switching between machines/domains/IPs but remaining being themselves and with the same private key that identifies them <fr33domlover>ACTION is implementing an actor system and wanting to align the vision! Imagining a system where each location/server has a directory matching public keys to locations, and all method invocations go through that system to determine actor's network location, and there's a system where actors can atomically move from machine A to machine B iff <fr33domlover>ACTION there's mutual consent, and then broadcast a location update to let the network know <dthompson>fr33domlover: actors are addressed by their identity, not their location, so they are not tied to any specific location. <dthompson>or rather, *machines* are addressed by their identity <dthompson>a reference to a specific actor could provide a hint as to where the machine could be found. <fr33domlover>dthompson: Are those identities represented as public keys? Or just long random strings/numbers? And does an actor reference contain (internally?) both the actor's identity and a (hint for) location? <dthompson>fr33domlover: the references I'm familiar with in goblins use public keys. <dthompson>the amount of information that a reference needs to be useful depends on the communication medium. for example, goblins currently only supports talking over tor hidden services. a .onion address is both the identity *and* the location, so no further hint is necessary to access the service. <dthompson>let's say there was a reference that relied on dns, though. that would require a hint so the peer knows what hostname to resolve to find the machine. <Zarutian_iPad>that is assuming a connection oriented captp like E has but not on connection-less like Waterken has <Zarutian_iPad>but pretty much the same issue of getting the messages destined for actors to them <dthompson>just speaking from what I know about how goblins currently works <dthompson>things are very much in flux but right now our shareable actor references are URIs in this form: ocapn://identity.protocol/s/actor-id?hint1=val1&hint2=val2&... <dthompson>the hint stuff is actually new and not in the main branch. <dthompson>I am *not* a lead on the captp implementation, so this is just what I've learned through osmosis. :) <dthompson>I don't know anyone else's captp-like system. only goblins. <fr33domlover>Interesting. In the Tor case, the network part happens entirely outside the actor system, on a lower layer. I wonder if TCP/HTTP/DNS based communication with support for transparent relocation could/should be implemented the same way, or would it be better on *top* rather than below the actor system (because them relocation could be controlled <fr33domlover>using actor methods; Tor doesn't need that because its anonimization/routing/etc. logic is self-contained) <dthompson>in goblins we call the different communication mediums "netlayers". captp works over any properly implemented netlayer. right now we have an onion netlayer, but we are also working on a more basic netlayer that just uses tcp sockets. <isd>It occurs to me: I don't think there's any fundamental difficulty in turning the way promise resolution works into a generalized redirect mechanism, that you could invoke (1) after having handled some methods, and (2) for multiple hops <isd>There is one wrinkle, which is that it is sometimes useful to know when a promise is "done" resolving, which would be a bit murky if you can resolve it more at any time.