SDK v3

[rwalworth]

The topic of v3 SDKs has been coming up a bit more frequently than usual, so I figured it'd be a good idea to have a public place to talk about what might be included in a v3 SDK. This can include brand new ideas that would be hard to implement in our current v2 SDKs, or breaking changes/refactors to current APIs that would make for a better developer experience. All ideas should be placed in this discussion so that they can be tracked.

[ivaylonikolov7]

• feat: update module resolution to node16 hiero-sdk-js#3027 - currently we have some deprecated flags in the tsconfig.json that I would like to update. this could be a breaking change for some users
• download automatically addressbook when setting up the client
• remove react-native-get-random-values. This would require a change in the clients that use the expo project
• Migrate internal cryptography utils to Noble libraries for consistency and cross-platform support hiero-sdk-js#3054 - this one requires a breaking change because changing the dependencies would change the return type of some function
• we would like to upgrade the major version of the proto package because currently it returns a single 700 kb file that with all the transactions in it. This makes the web bundle very heavy

[venilinvasilev]

I would propose to make the Client initialization in the JS SDK asynchronous, this would require as to make some internal changes to make sure client is initialized with latest network state.

[hendrikebbers]

In the Java SDK everything is currently in 1 package. We should change that and provide some kind of structure

[0xivanov]

The problem with having multiple packages is that we cannot utilise package private modifier. For example, in AccountId we have toProtobuf method, which is package private and is used in many files.
It makes sense AccountId to go into /account package, but we'd have to make it's methods public in order to expose it to other packages and I don't like losing the encapsulation that we have.
cc @naydenovn

[naydenovn]

I support Ivan’s opinion here. We have tried to introduce a packaging strategy in the java sdk, however any modifications of the current structure would mean that we will need to change access modifiers in the whole project and exposing private methods that don’t necessarily need to be exposed. So the decision we have to make here is basically to introduce packaging and compromise with the encapsulation or keep things the way they are now.
I would suggest we stick with current implementation as it better complies with good code practices.

[0xivanov]

For Go I'd like to update to the most recent stable release of the language - go1.24.4 at the time

[0xivanov]

Maybe we should bring up a old discussion about making PrivateKey.generate generating ECDSA keys by default.
Also if we should do something about methods like key from bytes/string etc.

[0xivanov]

Maybe we should make a list of deprecated functions for each SDK that we would like to remove.

[0xivanov]

I would personally deprecate all flows as well in favour of batch transactions.

[ivaylonikolov7]

We could face some pushback from the community, and it might not be received positively. I’m not sure I’m in favor of that.

[jbair06]

I have noticed some issues going between the Java SDK and the JS SDK that would be nice to get fixed in v3. And some user quality of life type changes. Specifically:

1. Encoding transactions should always result in the same bytes. I imagine this has been the topic of conversation a number of times, but wanted to make sure it made it into this thread. I was able to get the same bytes once I altered a few lines in the JS SDK. The sdk does not ignore default values for int, string, boolean, etc. like the Java sdk does.
2. Signing transaction across SDKs. IF we can't guarantee that bytes are the same, then another issue arises. I can't sign a transaction in multiple SDKs and collate all signatures. I discovered this issue can be circumvented as long as one SDK is used to create the original transaction and signs it before encoding. Then other SDKs (JS and Java at least) will see it is frozen and not attempt to recreate the body bytes. If encoding is deterministic across languages, this isn't an issue.
3. Removing signatures. JS SDK has already worked in a fix to allow signatures to be removed from a transaction. This was needed to help support the multi-sign use case. If many keys are needed to sign a transaction, the transaction may become too large. This results in the need to remove 'extra' signatures to ensure the transaction is successful, if desired. This could be helpful in other languages (and perhaps redesigned with this intention in mind in JS SDK as well).
4. Adding signatures. Like above, it would be great to easily add signatures back into a transaction. JS SDK allows this if we use a SigMap or similar, but Java, for example, does not allow it if there are more than one transactions internally. If there are more than one internal transactions, remove should allow removing the entire 'signature' from all internal transactions for a give public key and add should allow the reverse.
5. Unfreeze. There is the case where a transaction was frozen manually, or signed, and it needs to be unfrozen in order to make a change (in the case of signed, signatures could be removed then the transaction can be unfrozen). I know this sounds odd, but I've come across a situation or two where it would be helpful.
6. Copy transaction. Some helper functions like copy would be awesome, where it does a deep copy, or perhaps a copy of everything but signatures (and freeze status). Though, like the unfreeze, this would mostly be helpful because of the other above difficulties.
7. Internal validations. When adding signatures, I'm not away of any check that the public key and signature bytes belong to the transaction body bytes before the signature is added. Adding signatures is very limited, currently, anyway.
8. Helper methods. Simple things like 'transaction size' to show the current out-the-door size of a transaction to ensure it isn't over limit. Implemented in JS SDK, I do believe.

I'm sure I'll think of more. I suspect these are more surface level enhancements than anticipated for this thread, but they are on my wish list!