rework introduction to be simpler

Signed-off-by: Thomas Poignant <[email protected]>

website/src/pages/specification/20241027-flagsets.md

@@ -20,47 +20,19 @@ Description: Flag sets are a way to group flags together.
 
 ## Context
 
-GO Feature Flag is supporting both flag evaluation for client and server-side.  
-While the server side evaluations are evaluating flags 1 by 1, the client-side providers are evaluating flags in bulk.
-The main reason why client are evaluating flags in bulk is because in the client-side the evaluation context is not changing
-for every evaluation, so in order to limit the number of requests to the relay proxy, we are evaluating flags in bulk and keeping
-them in memory inside the different client providers _(`web`, `iOS` and `android`)_ for OpenFeature.
-
-### Sequence diagram of a client-side evaluation
-
-```mermaid
-sequenceDiagram
-    participant app as Application
-    participant Client as Openfeature SDK
-    participant Provider as GO Feature Flag Provider
-    participant RelayProxy
-    app->>Client: SetContext(myEvaluationCtx)
-    Client->>Provider: init()
-    Provider->>RelayProxy: call /ofrep/v1/evaluate/flags
-    RelayProxy-->>Provider: return all evaluation responses
-    Provider->>Provider: Cache evaluation responses
-    Provider-->>Client: 
-    Client -->> app: 
-
-    app->>Client: getBooleanValue(...)
-    Client->>Provider: resolveBooleanValue(...)
-    Provider-->>Client: evaluation response from cache for the flag
-    Client -->> app: flag value
-```
-:::note
-For simplicity, we are not showing the cache mechanism in the sequence diagram, and how the cache is updated in case of flag configuration changes.
-:::
+As of today, GO Feature Flag is evaluating flag differently for client and server evaluations.
 
-### Why introducing flag sets?
+- In the **client-side**, we are evaluating the flags in bulk, and we are keeping the evaluation responses in memory for the duration of the application.
+- In the **server-side**, we are evaluating the flags 1 by 1, and we are not keeping the evaluation responses in memory _(except if a cache is configured)_.
 
-As of today, in the client-side paradigm, we are evaluating all the flags available in GO Feature Flag based on the received evaluation context.
-This means that we are evaluating all the flags available in the project, but in some cases, we might want to evaluate only a subset of the flags.
+In both cases having a flag set could be beneficial, for **performance reasons**, but also for **organization reasons**. 
 
-**When do we want to use flag sets?**
+### When do we want to use flag sets?
 - We have multiple teams using the same GO Feature Flag instance, and we want to separate the flags evaluated by each team.
 - We have different platforms using GO Feature Flag, and we want to limit which flags are evaluated by each platform.
 - We want to give access to a list of flags to a specific user group.
 - We want to allow 2 flags with the same name if they are used by different teams or platforms.
+- We have a lot of flags, and we want to evaluate only a subset of them for a specific context _(e.g. on my ios application)_.
 
 **For all those points, as of today the only way to achieve this is to run multiple instances of GO Feature Flag, which is not ideal.**