User interaction messages

Protocol Design Specs v2
1

The v2 specs must define user interaction messages which can be sent and received “externally” to and from a node implementation. Many of these may simply proxy internal implementations, but we should probably define a distinct interface. For example, this will likely include:

  • transaction submission and status information
  • state reads, including indexed state reads
  • node status queries (storage, compute, peers, etc.)
  • publish/subscribe to specific topics:
    • should these be P2P topics directly?
    • or should there be a more abstract interface here?

cc @mariari Is this in line with what you were thinking about?

2

Many of these may simply proxy internal implementations, but we should probably define a distinct interface

why?

3

Because then we can change internal implementation details without changing the client-facing interface. Hard to say whether this is specifically necessary without discussing the specific messages though.

4

hrm. I don’t see any particular reason to bother with this now if the interface is going to be a direct copy anyway—if we later want to change an aspect of some internal interface while keeping compatibility for the external interface, then we can decide how to slice things up at that point?

5

That’s fair. Let’s see what the specifics look like. Also pinging @mariari who might have thoughts here.