Introduction of the @vereign/lib-seal

@alexey.lunin @zdravko hey guys.

This discussion is a follow-up of the

Let me start directly from the painful points in the current situation with iframe, @vereign/vframe, and @vereign/light-utils

Drawbacks of the current libraries architecture

  • @vereign/light-utils is heavy and 95% of it’s functionality used by iframe and web-verification-app only.
  • @vereign/vframe and iframe needs to use shared code of public API errors (MimeVerificationError, SealAPIError, StatusAPIError). That’s the reason of having them sticked in a single repo.
  • There’s certainly confusion between iframe and @vereign/vframe during the discussions.
  • If a third-party integrator wants to read seals from emails and load iframes, he/she needs to install both @vereign/light-utils and @vereign/vframe which is really inconvenient.

Proposed solution

So, after some thinking I came up with the idea of aggregating existing functionality into a lightweight integration library called @vereign/lib-seal which is going to expose:

  • IframeService - to load iframe APIs
  • SealService - to extract seals from MIME
  • List of public API errors

With this optimization, Integrators (Chrome Extension and Outlook Add-in) will be able to sufficiently cover the verification routine at their side using only a single library. And pretty much the same goes for the signing routine.

What’s going to happen to the old libs

  • @vereign/vframe - gets removed
  • @vereign/light-utils - preferably it should be used only by Web Verification App and Iframe. Chrome Extension and Outlook Add-In will be able to work without it.

List of dependents for @vereign/lib-seal

  • Chrome Extension and Outlook Add-in. Using the whole API of the library.
  • iframe - uses Public API errors only
  • @vereign/mime-normalizer - needs only SealService in tests
1 Like

I’m ok with the proposed solution.

I’m ok with this solution