Endo Pet Daemon Spikes

[tgrecojs]

This page contains excerpts posted by @kriskowal within the Endo Contributors Matrix Chat

Endo Pet Daemon Development

• In a conversation with @kriskowal and @tgrecojs we began exploring the question of what are the next steps for Pet Daemon development and I want to share some of those thoughts more broadly in case others are interested in spiking out from the core in various directions.
• [ ] libp2p bridge
  1. This has dependencies on some core development, like the reification of Powers, so the libp2p plugin could do endo~.inbox()~.powers('petname') and use the resulting powers as the local “bootstrap” object for a CapTP connection to the remote party. (All of the bridges need that, including the bridge to web extensions.)
  2. Some design work remains open for that since “connections” probably need to be modeled as a pubsub topic. You get the latest remote reference and updates when the connection is interrupted (e.g., tab closed, reopened later)
• [ ] we can experiment with ways to bridge a web page, and we need at least one of these to work in order to host Endo’s own permission management UI.
  1. There are at least three workable designs for this, probably more. That probably means moar plugins.
  2. The design I’d like to pursue first is an Endo API like endo~.open(frontendPetName, backendPetName, givenPetName), where the frontend pet name corresponds to an Endo bundle to run in a web page and backend is the powers object to give the frontend. This would cause the Endo HTTP server to virtual host a new UUID (and capture a formula for the UUID) such that UUID.endo.localhost:PORT would serve up a single index.html file with a bootstrap script. The script would establish a WebSocket CapTP connection to the Endo Daemon, and get an object it can use to obtain the backend reference and the frontend bundle, then execute the frontend bundle, granting it access to the backend powers.
  3. The endo open command would also incidentally use the open package to open the resulting web app in a browser. We can use open to bring Endo tabs to the foreground, as in to respond to permission requests. I think dapp developers will enjoy not having to create pages that instruct the user to go look at their wallet.
• [ ] ipfs bridge
  1. Endo needs to have its own content address store, because its storage is private (more on that later), but a plugin that lets get content out of IPFS and pin content to IPFS, we’d be in a cool new world. This would be a need building block for a number of things.
• [ ] Endo’s content address store is currently very minimum viable.
  1. It’s just a key-value store. It doesn’t do file system trees. That’s not a problem for the web front end idea above, because it just needs to store a bundle and bundles use zip to model the file system. But, it would be quite nice to move up a layer and do git or ipfs style storage. Maybe we can trick IPFS into do this for us, using an isolate ipfs node, or reach into ipfs APIs, or whatever. In any case, this would unlock more options for Endo frontends. We could do a version endo~.open from above that takes the pet name for a CID instead of the pet name of a bundle and just host an arbitrary web app.
• [ ] @kumavis did an experiment that shows that we can get a React app to run under Endo. It would be good to prove that out with the endo~.open idea above. We’d bundle a React app, endow it with window and document.
• [ ] Permission management app.
  1. This would just need parity with the endo inbox, endo resolve, and endo reject CLI commands in a graphical frontend and would give us a beachhead for an ocap REPL, ocap chat, pet name management, endo task management.
• [ ] Pet name work.
  1. I haven’t written petname reverse lookup yet. That’d be an API that takes a reference and tells you your own pet name for that reference. That gives us a beachhead for edge name resolution. We want to eventually be able identify references the user has not named and provide a list of the names their peers have recommended for that reference (their edge names). Communicating edge names is also under-explored.
  2. That probably looks like peer.~send(messages, petNames, edgeNames) and is related to the the permission management REPL/chat idea above.
  3. Chatting something like
     1. @kumavis Would you like to play a @game:chess1? 
  4. would emit something like:
     1. endo~.peer('kumavis').~send(['', 'Would you like to play a ', '?'], ['chess1'], ['game']).
• [ ] Attenuated file system API. @dckc has a number of sketches laying around, particularly in bundle-source, for a file system API that supports gradual attenuation from a whole file system, narrowing to a chroot, narrowing to a read-only handle on a single file. With such a facility, Endo would be able to ask the user much more focused questions about permissions.