in Context, `userId` might be a bit overly specific

[moredip]

In some controlled rollout scenarios, cohorting is done by something other than user. For example, if you're canary releasing a new caching layer you might choose to turn it on for a subset of servers. So calling the hash input userId might be a bit confusing. Not sure what a better name is thought 🙃

[beeme1mr]

The context type in this example is too simple. It should contain some agreed upon properties but accept arbitrary properties as well.

[patricioe]

Another idea, although a bit longer, can be targetingKey, or targetingId.

[toddbaert]

I see value in using the language of "targeting" for this as @patricioe suggests. Here's my reasoning:

• "Targeting" is already used by most vendors in setting up rules, so it's not foreign terminology.
• It doesn't overlap with "user", and so avoids lots of collisions and confusion, both lexical and logical.
• It's seems to address @moredip 's initial concern here that the subject of a request or call might not be a "user" in the human sense.

We could shorten it with the term targetKey or targetId.

cc @beeme1mr

[toddbaert]

We have opened a spec issue for context: open-feature/spec#43, I'll close this and we can move the discussion there.

[weyert]

I would suggest distinctId as in distinct identifier, for e.g. user, group, company etc