Mixin zome and utility libraries for RESTful APIs and URI resolvers

There was an excellent conversation started by @guillemcordoba in another thread about URI-based addressing for entries kept in zome storage APIs. In here, @pauldaoust floated the idea of an RPC-based URI scheme, which I agreed at the time was a pragmatic and sensible way of addressing the problem.

I’ve been thinking about this a bit more and I’ve realised a protocol scheme that follows the RPC API structures is probably a bad design decision.

The reason is just that RPC was a poor choice to represent distributed addressable data in the first place. It’s too flexible. An interface that can expose any arbitrary function to the caller is not an interface that conforms to representations of stateful data.

That’s what we’re really talking about here- the need for a REpresentational State Transfer protocol on Holochain. It ties into something I tried to do early on that couldn’t be implemented: turning Holochain into a Solid pod.

The reason you can’t do this yet is that Solid follows the REST model using standard HTTP verbs, and the Holochain conductor only allows you to POST through a JSONRPC interface. This is the same limitation- Holochain doesn’t have a built-in standards-compliant model for representing data structures and means of accessing them.

So I would advocate a two-stage process for this:

  1. Create a “RESTful” zome trait that zomes wanting to conform to such data models can implement; and implement a URI resolver zome & lib which is compatible with these traits. This solution is actually fine and seems “Holochain native” in that it’s an app-layer implementation, and that it considers the conductor JSONRPC interface to be the “native” Holochain protocol, which it is.
  2. Push this functionality into core and expose standard HTTP verbs using zome trait bindings, such that RESTful HTTP APIs can be built on Holochain more easily. In effect this would allow you to skip the use of an intermediary webserver (or UI and the HOLO hosting network) in order to expose the data to the wider web in a standards-compliant way, which was a possibility we spoke of in the other thread.

Going ahead with this would mean building 3 complementary components:

  • A set of hc_zome_restful_api crates, which provide the zome traits for use in zomes wishing to expose REST interfaces to record data and/or possible framework/implementation details
  • hc_zome_rest_resolver, which can be mixed in to zomes wishing to interact with RESTfully conforming bridged zomes in order to read records from them
  • @holochain/hc-restful-resolver or similar as a JS-native front-end library that can be used to resolve holochain URIs against any hc_zome_restful_api; basically the UI-layer version of hc_zome_rest_resolver

Would like to keep this discussion going and get more input on this framing of the problem and solution design… please ping any others you feel should be involved (:

1 Like

A pub or a pod?

Sorry- pod! Corrected.

Wanted to add some additional context to this thread in regard to URI protocol formats. This is pulled from a distillation of some early spec work I saw buried in a HackMD from either @zippy or @pauldaoust or @artbrock or someone… anyway—

In Holochain the URI format is likely to be holo:${AGENT_PUBKEY}@${DNA_HASH}/${ENTRY_HASH}, maybe use of anchor suffixes for link tag names in order to support traversals of the underlying data graph.

You can think of DNA_HASH as a network identifier, ENTRY_HASH as a content-addressable resource ID. Including AGENT_PUBKEY@ in the address indicates retrieving a record from a private hashchain rather than public DHT space… there will probably also be space for a capability token in there at some point (…${AGENT_PUBKEY:ACCESS_TOKEN@DNA_HASH…) because this is the access control mechanism Holochain apps use to expose private user data to other parties. You can use the same URI scheme to identify users as well… doesn’t necessarily have to be the case but I think that pairing user & network IDs is probably important in Holochain’s context (ie. the minimum necessary identifying info for a user is holo://${AGENT_PUBKEY}@${DNA_HASH}).

How does this articulation track these days? (:slight_smile: