`FQME`: fully qualified market endpoint, (or f#$% me) the thing no suit could imagine..

[goodboy]

This is a major design decision that seems to have not been solved yet by any other platform (which is frankly baffling):

what does a fully qualified market addressing scheme look like?

---

technical jargon/terminology

Here are 2 options (please add more) for the acronym which describes the url-like address:

• fqme: fully qualified market endpoint <-- prolly what we're going with 🏄🏼
• fqsn: fully qualified symbol name
• fqmn: fully qualified market name (my preference i think?)
• fqan: .. auction name
• fqma: .. market address ...

---

Syntax, labelling and semantics:

There are generally 2 ordering schemes we're thinking are best, both somewhat based on tree-like hierarchical design of DNS and more generally on URL style syntax.

resolver op char:

• . seems like the most obvious but i think we should be open to :
• are there any better chars that are less susceptible to the parsers of shells and other copy/paste from/to envs that will likely be used for passing around the address strings?

current hierarchy-label order:

• <marketpairname>.<venue>.<suffix(es) with metadata>.brokerbackendname>
  • eg. mnqusd.cme.20230317.ib
  • this obviously becomes more confusing/cumbersome with option market addresses and any other or future added derivs market meta-info.

preferred non-reverse hierarchy syntax:

• ib.cme.mnqusd.20230317.<further option mkt address labels>
• <broker>.<venue>.<underlying market pair>.<expiry info label (derivs only)>.<strike price info (opts only)>.<more?>

I personally much prefer this second (order) style due to it looking more like attribute access* and will make a UI representation in the search results tree orient from left-to-right exactly the same as scoped search results:

ib
|_ cme
     |_ mnqusd
         |_20230317  (expiry price)
             |_1200c

which also makes showing the specificity of the market graphically somewhat intuitive?

---

Previous work, research, and lead-up to this:

From our original MVP PR https://github.com/pikers/piker/pull/295:

Basically the idea here is for all client-ish code (aka programs/actors that ask the provider agnostic layers in the stack for data) should be able to tell which backend / venue / derivative each data feed/flow is from by an explicit string key of the current form ....

I have thoughts that we should actually change this to be more like an "attr lookup" (like how the web should have done urls, but marketting peeps ruined it etc. etc.):

<broker>.<venue>.<instrumentname>.<suffixwithmetadata>

Existing standards:

• there is already an existing convention for option market labels like "YHOO150416C00030000"

Probably more we'll add..

[wygud]

I think its mostly arbitrary so my advice would be to just pick something and make it the standard. For me, 3 of those would be automatic in almost all use cases. If I had to pick an order it would be the direction of the decision tree in the most frequent use case. so probs this: mnqusd->1200c->20230317(automatic selection to most recent contract)->cme(aggregate feed or "smart")->ib(depends on use case but would have a default broker for each use case)

[goodboy]

Linking #489 since we'll be addressing a couple initial decision on this topic there 🏄🏼