[Tracker] SDK 4.0 - Breaking changes

[XavierChanth]

I opened this ticket as a place to get ahead of the curve in terms of the next round of breaking changes.

The following comes to mind for this list: Renaming AtKey will cause a breaking change, but for the benefit of making the tech easier to understand. With that, we could rename at_client_mobile to at_client_flutter, and potentially other things that we think could be made clearer.

In addition, I'm nearly certain that there are other potential changes that I am not aware of, and it would be useful to list those here as well. Then, when the time comes to actually make the breaking changes, we will have a checklist ready to ensure that we don't miss anything on release.

Other things:

• Encryption algorithms (specifically RSA)
  • How soon do we need to migrate?
  • Not imminent, but it is easier to migrate while there are less atSigns to migrate.
  • Better solution would be to migrate servers, give clients ability to handle ECC and RSA.
  • ECC 25519 seems like the likely replacement, what about constrained environments?
  • Need to find libraries for this, specifically need solid support on MCUs
• Implementation details that are leaked into the SDK (e.g. hive)
  • Mostly naming, client may have a few leaks but nothing major
  • Server has more leaks but less of an issue
  • Need to handle migrations if we change persistence solutions
  • Could also opt to maintain hive if we can fit it into capacity
  • Does not necessarily need to be a breaking change depending on how we handle it
  • The problem with hive is that we are tied to files and NFS
  • The solution is not as simple as swapping 1 k-v store for another
  • Other considerations about scalability arise
• Various deprecations throughout the codebase

  
  ### Tasks

• [ ] Remove deprecated variables in at_commons and republish

[gkc]

Thanks for creating this ticket Xavier! It's definitely time to get serious about a version 4

Re the renaming of AtKey specifically: we should consider introducing a non-breaking change much sooner by changing AtKey's implementation so that it delegates everything to a new class (likely named AtRecord), and then deprecating AtKey. We could then fully remove AtKey in a version 4

[XavierChanth]

If we want to migrate our signatures to records, this would be a good time to do it!

[gkc]

See also https://github.com/atsign-foundation/at_client_sdk/issues/1113

[XavierChanth]

I want to consider removing KeyStreams in 4.0.0, my original intent for them doesn't really make sense given the work with AtCollections. I will need to take a closer look to confirm that they truly have no use-cases, but I believe that to be the case.

[XavierChanth]

@gkc I know we originally discussed renaming AtKey to AtID, but all of our SDKs use the term AtKey now... it's worth bringing this topic up again.

[gkc]

Discussion & decision from architecture call:

• we will keep the existing code class names
• we will strive to use the words record, identifier, metadata and value in documentation and not refer to code names unless required eg in developer docs