[Feature Request] .NET SDK mechanism to share of client context from backend to frontend

[nosider]

Is your feature request related to a problem? Please describe.

After much searching, I could not find a way to share a client context from backend part of the application to the frontend.

The problem:
We have a backend and frontend, as one would, with the backend using a client eval key, while frontend using server eval key. As the application grows and client context gets more parts added to it, we need a mechanism to ensure that the client context between frontend and backend is kept identical so that feature resolution works the same way across both layers of the application.

We considered using middleware to stuff the client context related info into a response, allowing the info to flow from the backend to the frontend, but found that the .NET SDK does not seem to have anything in IClientContext that exposes a deterministic value (string?) that can be reconstituted into a client context on the frontend (React). In-fact, other than using dirty reflection hacks, neither the BaseClientContext nor its implementers publicly expose the underlying attributes that make up a client context. This would still require custom code to then reconstitute the client context on the frontend.

Describe the solution you'd like
It would be great if there was a mechanism to allow sharing of client context between disconnected systems (such as backend to frontend, or a reverse-proxy to api service or backand to android-client). This would then allow a single "source of truth" for a feature client context that could then be disseminated across various services in need of it to check feature toggle status.

Some ideas
Looking at the code in BaseClientContext, the various key-value-pairs for the client context are stored in a protected _attributes dictionary. One could amend the IClientContext interface to expose a string representation of the dictionary (maybe via json serialisation?) that could then be opaquely provided to anything that needs it.

To note:
If the approach is to be fully supported by FeatureHub, it would then need to be (eventually) supported by all the SDKs that FeatureHub kindly offers, so as to allow any permutations of various SDKs used across any number of layers in a distributed application. (i.e. Ract frontend, + .net backend or Android Java frontend and NodeJS backend or etc...). This may become a non-trivial undertaking, with all SDKs having to support the process of deterministically packaging the client context into something portable (string?) and then also supporting unpacking into a fully fledged client context as well.

Describe alternatives you've considered
I realise we could have both the frontend and backend implement separate logic to construct the client context the exact same way, but it means there are two places for the same thing (not DRY) and more chances for human error as things evolve over time. It would be awesome if this mechanism existed out of the box, meaning less bespoke workarounds.

P.S. Happy to add any info that I may have forgotten to provide, and I may have been blind and missed an already provided approach for what is described, in which case I apologise in advance.