Which source will be considered as invalid? The same order as merging sources today?

My naive thought was just to act as if an invalid configuration was loaded in this case - so if we're starting up initially, we'd exit with an error code, and if we got into this state with a change after already being in a running state, the change would have no effect and an error would be logged with every update until the error is corrected.

We could prepare for different configurable merge strategies, with initially implementing a fail-fast strategy, or use the current merge strategy (last one wins).

Same comments as in #1610 (comment)

If we really want to stay with simple syntax, we should consider using something new, like flagSetSelector, instead of selector.

flagd is only one implementation of the proto/API - the selector selects flag sets with this proposal, but another implementation could use the selector to select something else (maybe it could even be an expression), so I'm hesitant to explicitly bind it to the flag-set concept.

We could also think about not introducing flagSets, but instead make selectors explicit.
E.g., something like this:

{
  "$schema": "https://flagd.dev/schema/v1/selectors.json",
  "selectors": {
    "my-project-1": {
      "metadata": {
        ...
      },
      "flags": {
        "my-flag-1": {
          "metadata": {
            ...
          },
          ...
        },
        ...
      },
      "$evaluators": {
        ...
      }
    },
    "my-project-2": {
      ...
    }
  }
}

With this, we'd keep our flagd vocabulary.

I think this is another problem. IMO the storage needs to be refactored because it mixes the interface and the in-memory impl, which makes the in-memory storage the only possible storage to use at the point.

The semantics of selector will also change, and the change happens mostly on the server (source) side, so the clients can have unexpected results with the same config.

This is true, I will add that.

https://github.com/open-feature/flagd/pull/1634/files#r2116303357

But it could also be done in a non-breaking way.
Flagd could still treat the source value as flagSetId/selector if the file content adheres to the v0/flags schema

True, so this becomes a question of tech debt and code complexity.

Reading through this ADR and thinking about it it seems to me that this is quite specific to the implementation of the flagd Sync server but the decisions here will impact the interface that the provider needs to use. The challenge here is that there will be other Sync server implementations.

Thus, I would strongly suggest we start from the provider side. What is the intended developer and product experience for consumption of flags using flagd providers? If we believe that some sort of "flags namespace / flags set" concept is needed, then we should design the provider interface that makes it a first class citizen. Then, Sync API implementations will have a good spec and each can figure out how to support that.

We could still keep the selector() field, but we should probably define some rules for the semantics of it. Or perhaps, we should create a schema for it that has some fields as required and then some mechanism for custom extensions? Or, we could create additional methods in the provider, like flagSetSelector().

WDYT?

But it could also be done in a non-breaking way.
Flagd could still treat the source value as flagSetId/selector if the file content adheres to the v0/flags schema

We could also think about not introducing flagSets, but instead make selectors explicit.
E.g., something like this:

{
  "$schema": "https://flagd.dev/schema/v1/selectors.json",
  "selectors": {
    "my-project-1": {
      "metadata": {
        ...
      },
      "flags": {
        "my-flag-1": {
          "metadata": {
            ...
          },
          ...
        },
        ...
      },
      "$evaluators": {
        ...
      }
    },
    "my-project-2": {
      ...
    }
  }
}

With this, we'd keep our flagd vocabulary.

@tangenti could you outline some of your other ideas? I'm interested in your proposals here (specifically 1. and 2.).

For our internal teams' specific purposes, we need some way of logically restricting/scoping the flags a particular client can evaluate, assuming all flags are coming from a single source. I'm open to other suggestions.

Question: Would this selector be set to my-project-1 if someone were to only want to evaluate the flags under the flag set of my-project-1 in the example above which calls out the new schema structure?

Exactly.