Remote Data Encoder

[Spikhalskiy]

Provide a framework for serving and consuming data encoding via HTTP across all our SDKs.

1. Frees users to write their encryption code in whichever of our SDK-supported languages they prefer.
2. Allows users to restrict access to their encryption keys or KMS API usage to only the remote decoder process rather than developer workstations.
3. Allows tctl to encode payloads for tctl workflow start. Note: This will not work for any encoders which require workflow context. Fixing this is outside the scope of the MVP

Remote_Data_Encoder_protocol.pdf

GoSDK reference implementation: https://github.com/temporalio/sdk-go/pull/717 https://github.com/temporalio/sdk-go/pull/733

[robholland]

Please note protocol update (Payloads vs Payload): https://github.com/temporalio/sdk-go/pull/733

[robholland]

The linked PDF is correct and matches https://github.com/temporalio/sdk-go/pull/733

[robholland]

Go and TS SDKs both have nice APIs for this now, would be great to get this in Java too.

[Spikhalskiy]

It's not really our preferred or advised method to do that. It's more of a workaround if the standard approach to data converters is not applicable in extreme scenarios. It should be done at some moment, but I don't see a big need until there is a specific ask. Is a particular client and use case asking for it in Java SDK?

[robholland]

This is not for extreme scenarios at all, it's a requirement for anyone who is using encryption (or similar use cases) and wants to be able to see the plaintext in the Web UI or tctl output.

[Spikhalskiy]

The majority of users should stick to the standard data converters approach for a variety of reasons as long as they could. And security is one of them.

[StevenLangbroek]

Hey! Temporal Cloud customer here, we'd love for the Java SDK to have parity with the other SDKs in this specific area.