3 ms·

Hi there! Yes, the transaction log stuff is of interest to me, and ties in with the "Questie" stuff (the one listed as inspired by the causeway debugger). Not

Hi there! Yes, the transaction log stuff is of interest to me, and ties in with the "Questie" stuff (the one listed as inspired by the causeway debugger). Not quite on the front burner yet, but it'll have to be to make our lives easier. Goblins already supports distributed (acyclic) GC! And yes ocap security does tie in nicely. In a sense ocaps make this really easy... if you think about an ACL approach the user has to point at the object they have access to and the object has to point back, but since ocaps are based on "having references to objects", in general GC locally can just be the very GC that the native runtime provides. Across runtimes (in the distributed code), distributed GC likewise falls out easier, though the algorithm doesn't know how to handle cycles when Alice on machine A points at Bob on machine B which points at Alice on machine A again. So you have to manually cycle break in those cases, but they're relatively rare. Amazingly, Electric Communities Habitat had distributed cyclic garbage collection, which just blows my mind: http://erights.org/history/original-e/dgc/ http://erights.org/history/original-e/dgc/ But that requires special cooperation to traverse the object graph held by the runtime's garbage collector, which we don't have access to in Racket (or most languages) unfortunately. It would really be cool to see that tech revived somewhere though. Hope that answered your question somewhat!

alexisread 6y ago
Thanks for the response! With the DGC, yes it makes sense that, given a local GC, you'd be better off extending it. There's a paper https://concurrency.ch/Content/publications/Blaeser_Component_Operating_System_PLOS_2007.pdf https://concurrency.ch/Content/publications/Blaeser_Componen... which details an RAII + message queue solution for managed memory without GC. The idea there is that provided your message API is well defined, you can determine the queue size in advance, and thus deterministically manage the memory (ie. object lifetime). I'm mentioning it here, as if capabilities and RPC are added to the mix, you can treat remote objects as part of the memory DAG - RPC calls are just another message on the queue (capabilities here act as a root trace as if you have a message on the queue, you can trace back to the root) and the object can be removed when the queue is zero. In addition, as per Rust, we should be able to lean on the compiler somewhat, to do some static cycle analysis. I don't think you can get away from having a cycle checker at high level, but with a transaction log + managed memory + functional code it should make a cycle checker easier to write. Lastly, I was thinking about the DAAS space - all of this distributed stuff will require authentication (authN) and authorization (authZ). I think primarily this comes down to IBS (Id Based Signatures) for authN, and then storing encryption secrets to access resources in a distributed hash tree (https://wmcode.nl/dh3/dh3_paper_v0-5.pdf https://wmcode.nl/dh3/dh3_paper_v0-5.pdf), but any thoughts on how to secure items without POW (proof of work)? Effectively the DHT is a POS (proof of stake) as you define who owns the resources by attaching an access hash to the secret.

alexisread 6y ago

Thanks for the response! With the DGC, yes it makes sense that, given a local GC, you'd be better off extending it. There's a paper https://concurrency.ch/Content/publications/Blaeser_Component_Operating_System_PLOS_2007.pdf https://concurrency.ch/Content/publications/Blaeser_Componen... which details an RAII + message queue solution for managed memory without GC. The idea there is that provided your message API is well defined, you can determine the queue size in advance, and thus deterministically manage the memory (ie. object lifetime). I'm mentioning it here, as if capabilities and RPC are added to the mix, you can treat remote objects as part of the memory DAG - RPC calls are just another message on the queue (capabilities here act as a root trace as if you have a message on the queue, you can trace back to the root) and the object can be removed when the queue is zero. In addition, as per Rust, we should be able to lean on the compiler somewhat, to do some static cycle analysis. I don't think you can get away from having a cycle checker at high level, but with a transaction log + managed memory + functional code it should make a cycle checker easier to write. Lastly, I was thinking about the DAAS space - all of this distributed stuff will require authentication (authN) and authorization (authZ). I think primarily this comes down to IBS (Id Based Signatures) for authN, and then storing encryption secrets to access resources in a distributed hash tree (https://wmcode.nl/dh3/dh3_paper_v0-5.pdf https://wmcode.nl/dh3/dh3_paper_v0-5.pdf), but any thoughts on how to secure items without POW (proof of work)? Effectively the DHT is a POS (proof of stake) as you define who owns the resources by attaching an access hash to the secret.