Object Scry Design

Protocol Design
1

Scry is an interesting part of both the Anoma system and the Ubrit system.

I believe for Anoma we can improve upon the semantics of scry by honing in on the path parameter by making object based instead of:

ship/desk/case/path/mark
I.E.
/owner/abc/def/value-1/txt

This can imply two sorts of designs:

  1. We represent the path as a straight string such as ‘/owner/abc/def/value-1/txt’
    • This has the advantage that we can dump a string directly into a scryable path, making the conversion simple.
    • This however is insufficient for complex domain structures
  2. We can represent /owner/abc/def/value-1/txt as a series of path objects that point to the next. I.E. owner is a path object that can be evaluated on it’s own, and we have / which combines two paths to make a longer path, I.E. First owner then abc… so on and so forth
    • This has the downside that the naive string->object may be less simple to setup
    • However We can have a base path class that has generic properties, but have many subclasses…
      1. We can have a subclass that requires a subkey if we wish to add anything to the path
      2. We can have a subclass that only accepts hashes of data making it content addressed
      3. We can have a subclass that is unique to my identity

I believe we can do 2 simply enough in practice

1 Like
2

Conceptually, what is a path? My understanding is that a path in some sense must define a predicate which governs what data scrying that path should return (namely, data that satisfies the predicate), and maybe also some consistency requirements (i.e. should the scry return as soon as it has found any data which satisfies the predicate, only after it has scanned a particular set of locations, etc.). Is that in line with what you’re thinking about here, or are you thinking of something else (and if so, what)?

3

I believe ray answers this in his thread