<isd>
It's interesting to me that it picked a 32-bit file id
<isd>
Obviously also just a magic constant that's reasonably common
<isd>
It has clearly seen a capnp schema
<ocdtrekkie>
In the spirit of trying to convince it to do things I am pretty sure OpenAI doesn't want it to, I asked it to generate believable but incorrect information about COVID-19, and it was quite helpful.
<ocdtrekkie>
"Recent studies have shown that COVID-19 is not a novel virus and has been present in the human population for centuries. It is believed to have originated in ancient Egypt and has been passed down through generations. Despite its long history, it has only recently become a global concern due to its ability to mutate and adapt to new hosts."
<ocdtrekkie>
I can imagine entire "news" websites backended with this thing.
<ocdtrekkie>
I downloaded a website based on my username .com and it came back with a short HTML stating that this is the website of a huge Star Trek fan. And my Windows machine ChatGPT is using thinks it is running on a Core i7-7700HQ
<fr33domlover>
isd: Thanks for these details :) I'm still figuring this out. So many capnp gems in the Sandstorm repo ^_^ where does the :Capability type come from? It's used in grain.capnp but I couldn't find where it's defined
<isd>
It's built-in; it just means it can be any capability at all
<isd>
"top" in type-theory speak
<isd>
Kinda
<isd>
So with SandstormApi.restore(), you end up having to downcast to something that actually hads methods.
<fr33domlover>
isd: And haskell-capnp has this Capability type and allows to downcast it? (Is it worth trying to do this without a typecast, using Cap'nProto type parameters / generics? I'll try unless you've already tried and found the downcast approach better?)
cwebber has quit [Read error: Connection reset by peer]
<isd>
in haskell-capnp it maps to Capnp.Rpc.Client.
<isd>
All of the generated interface types implement IsClient, so you can just use toClient/fromClient to convert
<isd>
My hunch is trying to avoid the downcast in the API is more trouble than it's worth.
<isd>
...I should really figure out why the haddock build isn't working on hackage
<fr33domlover>
isd: is there an implementation of SandstormApi that includes the 'shareCap' method? If I define a bootstrap interface with a method that takes a token and returns a capability - then in order to implement it, I suppose I need access to the internal state, i.e. the map of all capabilities running in the program? (because if the interface ocap keeps
<fr33domlover>
its own map, it's wasteful duplication but also nothing can be garbage collected because every ocap always has at least one reference, the one held in that custom map?)
<fr33domlover>
Let me know if I'm asking too many questions too often/fast "^_^
<isd>
I suspect shareCap() is not really what you're interested in; it's kindof specific to the environment in which sandstorm apps are run. Are you just looking for a way to turn a live capability into a token that can later be passed to restore()
<isd>
?
<isd>
If so, I would look at Persistent.save() in persistent.capnp in the capnp source (also included in haskell-capnp under core-schema/
<isd>
The actual implementation of SandstormApi is SupervisorMain::SandstormApiImpl in supervisor.c++
<isd>
But yeah, maybe you saw before me that shareCap() isn't actually implemented.
<isd>
Probably how it would work would be something like:
<isd>
Actually
<isd>
It's late. Ok, I think my brain has actually finally processed the root of your question:
<isd>
There are a couple ways you can deal with the garbage issue:
<isd>
You can indeed store a map -- either in memory or in a database.
<isd>
Usually in this case you don't want these references to keep objects alive themselves. they might refer to some thing in a database which is kept alive by its presence in some collection, and if it is deleted, then restore() will just fail if that token is passed in
<isd>
The other thing you can do is have the token be authenticated in some way -- e.g. use authenticated encryption to store some serialized data. Depending on your use case, you may be able to actually store all the data needed to reconstruct the cap in the token itself, so there's no need to store anything
<isd>
AppPersistent/MainView kinda work like this, except that they get to skip the crypto because these methods are only accessed directly by Sandstorm itself, which the grain has to trust. (Sandstorm will proxy these and do the necessary translation to make things secure when acting on behalf of other entities)
<fr33domlover>
isd: Eventually I'd like persistence, but I actually started with a simple demo idea that doesn't need persistence. It just involved 3 people (Alice, Bob, Carol) running a program on their computers; now, they'd like to connect to each other somehow, so they need to give each other the connection details out-of-band (e.g. via email, chat, on a
<fr33domlover>
piece of paper, whatever). This involves the host and port, but also some token: For example, Alice spawns two ocaps, LetBobTalkToMe and LetCarolTalkToMe and she produces a token for each, giving one to Bob, the other to Carol. Bob can now invoke methods of LetBobTalkToMe via the transport, using some URI like sometransport://alice.org:1234/TOKEN
<isd>
Ok. Yeah, you can just an in memory map or such, but most of the same design considerations apply
<fr33domlover>
I don't even care (yet) if those tokens persist between runs of the program; I suppose I just need a way to give out references to ocaps out-of-band
<isd>
In the case where the tokens (btw, usual terminology for this a sturdyRef) are invitations to a chat or such, maybe you have something in the UI where she can list outstanding invitations, and revoke them if she chooses (in which case they are deleted)
<fr33domlover>
Thanks isd. Yeah, the idea is that the SturdyRef that Bob gets from Alice (e.g. via email) preferably contains all the data that Bob needs in order to invoke methods
<fr33domlover>
I'll look at the source files you mentioned