Identity Contexts

[dabeeeenster]

It would be extremely useful to be able to provide multiple identities to Flagsmith as different contexts and then get the flags for different contexts in the SDK based on the use case in question.

Use Cases

• Switching organisation in a multi tenancy application. Additional context would be organisation. Traits could be subscription_level, number_of_seats.
• Changing device type (e.g. from Web Browser to mobile app). Additional context would be device_type. Traits could be has_notifications, low_bandwidth_mode.
• Changing role type in an app (e.g. if it was a Powerpoint style app, going from author to viewer). Additional context would be user_role. Traits could be allow_fullscreen, can_edit.

Example Code

flagsmith.init({
    environmentID: 'NowEDzKzNJXZVTVanLVdMQ',
    contexts: [
        {
            // This is the default context and so doesnt require a type
            "id": "kyle",
            "traits" : {
                "dark_mode": True
            }
        },
        {
            "type" : "organisation",
            "id" : "2g892a8qy0av97nqf13",
            "traits" : {
                "name": "Flagsmith",
                "plan": "scale-up",            
            }
        }
    ],
    onChange: (oldFlags, params) => {
        // No context provided - gets the first context passed into the SDK
        if (flagsmith.hasFeature('checkout-v2')) {
        }

        // Context provided, so get the flags for that context
        if (flagsmith.hasFeature('checkout-v2', 'organisation')) {
        }
    },
});

Server Side Changes

Two options:

1. Identities would receive a new column, context which is the name of the context. Identities that are not associated with a context remain the same, with NULL as the context value.
2. Context is stored at the Trait level. So something like:
   • Trait key e.g. plan
   • Trait value e.g. scale-up
   • Optional Trait context. e.g. organisation

Getting flags now allows the SDK to receive N sets of flags, for each context provided. So effectively the Flag engine would need to run N times for each context provided. This would be done in a single request/response.

Remaining Questions

Are contexts stored within the Identity, or shared amongst Identities based on a common Key?

For example. Two Identities are part of the same Organisation. The SDK declares an organisation context which is the same data for each Identity. Do the two Identities 'share' this same piece of data or not? This could be dangerous if one Identity modifies the Trait data.

Do Contexts need an ID to be provided?

How would the % split/mutlivariate flag engine work for contexts?

We could combine the Identity key with the context name/string and use that as the seed?

[kyle-ssg]

In addition to above, a lot of the use-cases for this would be an on demand switching of contexts. E.g. if we used this on a organisation / project switching level.

To accomplish this, for client-side SDKs we'd want to be able to also get additional contexts at the time they are used.

e.g.

await flagsmith.getContext("orgId", {organisation:"orgId"})

[dabeeeenster]

How we would go about persisting this Trait data without a big architectural change? If we added a context column to the Trait table maybe that would not be too painful. This could default to null for the default context, or the string value of the context if provided.

[dabeeeenster]

Not sure how we would 'seed' the % split/multivariate engine here. With regular Identities we get a unique key from the database which we use to seed the % split (basically). With identity contexts we don't have this, so we would need to generate something that is reproducable across SDKs.

Suggest just grabbing all the trait keys and values, concatenating them together, SHA256 hashing that string and then using that as the seed?

[melv-n]

Could we enforce each context to have its own key/id of sorts? Then that could be used for calculating enrollment in splits.

[dabeeeenster]

Hmm yes that's interesting. It could be enforced for each context, but you could make up a key by using the ID and namespacing it with the context. I guess it would be more flexible to allow people to provide an ID, but if one doesnt exist to fall back on something like <context_name>.<identity id> or similar

[melv-n]

I think another actor (LaunchDarkly) did a similar transformation, starting with only "users" and adding Contexts to it later. Their initial "user" seems similar to Flagsmith today, where it was different from other "contexts" and eventually they made "user" a fullworthy context of its own. So everything is a context, even the user. I thought that made quite a bit of sense, and may or may not be a journey FS takes in the future.

[h-no]

I think this is in-line with what we're trying to achieve in my comment here: #430 (comment)
In my comment we tried to work with tags as this is provided by the API today. However, having a context for the identity feels like what we're really trying to achieve.
We have our own authenticated REST API that our apps use, from which we respond with feature flags for the different resources. These resources could be different contexts? So in our apps API we could have GET /systems/<UUID>/flags which could translate to something like GET /api/v1/identities/?identifier=system-<UUID> but with the addition of providing the context for this identity to your API. Is that something we could achieve with your idea here?

[dabeeeenster]

What does the taxonomy/hierarchy of the different identities you are using look like?

Generally the idea with contexts is that you'd have one single Identity schema, but the idea being that you can provide a hierarchy of data within that Identity and then evalaute flags based on different parts of this schema. So you would'd need to have multiple "types" of Identity at all.

[h-no]

We have an organization (which we set flags for), the organization is the root-level node. In an organization there can be many systems (which we set flags for) and a system contains hardware devices and other resources. Users can have different roles on different sub-trees in the hierarchy. A typical use-case is that we want to enable a trial license for an organization, or preview features on a "pilot organization". Also some features need to be set on a per-system basis and does not make sense to the organization as a whole. We haven't had the need to set a feature flag for a user yet, rather on a resource so that all users with access to that resource gets the same experience.

[dabeeeenster]

I think generally with contexts you would have the User at the root of the hierarchy as per the json example at the top of this discussion.

[melv-n]

A user's "organisation" context may also change during the session if the user belongs to multiple organisations, for example when they "Switch Organisation" in the UI. Will that be supported, or will it be a 1:1 relationship? Where from Flagsmith's POV a user has/belongs to no organisation, or 1, but not multiple?

[dabeeeenster]

Ah I see now. Yes, so for identity contexts, you would most likely store multiple organisations as contexts with their own unique id.

[deepforest]

Without going into much details, IMO this approach is very limited, because contexts are tend to be more dynamic overall, and here you suggest creating static contexts. What if I want to use the 'organisation' context but also adding additional traits dynamically, which might be differ between calls?
In general, you can do exactly the same by storing aside the context objects in a dictionary or so and provide them when needed.

I think maybe what you want to have is the ability to send array of contexts instead of one:
flagsmith.hasFeature('checkout-v2', [organisation, user ...]))

Note that organisation and user are regular vars/objects, where organisation can be pre-defined as const or so, and user is created on the fly.