TL;DR: we need to remove support for M-strkeys (SEP23) from all the SDKs. If the SDK you are maintaining still doesn't have support for SEP23, you can ignore this message.
We have already reverted support for SEP23 in the Go SDK and the Javascript SDK. You can use those PRs as reference to do the same in your SDK.
SEP23 is still a draft and may not be promoted to final. Adding support for it means that users may end up storing M-strkeys, which can create a lot of problems if SEP23 ends up not being implemented. We are sorry we didn't identify this earlier.
We implemented support for SEP23 prematurely due as part of the Protocol 13 effort. As part of the Protocol 13 effort we implemented initial support for CAP27.
Again, we are truly sorry we asked the community to implement support for it and later remove it. We apologize for the inconvenience.
The SDKs shouldn't generate or accept M-strkeys (e.g. "MCAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITKNOG").
We encourage removing any code generating or parsing M-keys to avoid confusions (the code can later be recovered for VCS if need be).
Once that is done, the SDK may still need to deal with translations between strkey and MuxedAccount XDR representations without using M-strkeys.
We will drop the memo id of MuxedAccounts and use G-strkeys:
- Whenever the XDR representation of a
MuxedAccountneeds to be transformed to a strkey, it will first be transformed to anAccountID(dropping the memo id if needed) and then it will transformated normally into a G-strkey. - Whenever a strkey needs to be transformed to the XDR representation of a
MuxedAccountonly G-strkeys will be accepted, the