edeykholt
commented
2 weeks ago See refactoring proposal at https://github.com/WebOfTrust/polaris-web/discussions/31
Open edeykholt opened 7 months ago
edeykholt
commented
2 weeks ago See refactoring proposal at https://github.com/WebOfTrust/polaris-web/discussions/31
Great progress on the extension! Issue #155 prompted my braincells to think of this issue. On the interfaces between webpage and service-worker, please consider adding interface and/or message versions to help deal with future compatibility evolution, as follows:
1) The website should be able to know whether the installed extension is at or greater than an expected product release semver version. (See https://github.com/WebOfTrust/signify-browser-extension/blob/945a7a6e49a17a1b4be2634fb9af8721668d113a/src/pages/content/index.tsx#L14). With this, the webpage owner could essentially force a user to install a later extension version, if warranted.
2) In the future, extension implementers may support different optional feature sets. In the same place as above, the service-worker could advertise which sub-protocols it supports, e.g. authenticate-with-AID, authenticate-with-credential, sign-document, sign-payment-request, .... Then, these sub-protocols might each also have versions. I expect there are examples of this around Ethereum wallet EIPs, including Veramo, although they aparantly handle this via plug-ins. Veramo.io website might hold some examples, such as https://veramo.io/docs/api/remote-server.apischemarouteroptions/#apischemarouteroptions-interface. This way, two difference extensions might work for some integration behaviors, but only one extension works for a particular behavior required by the website, allowing the website to provide user feedback for an optional feature.
3) The service-worker should be able to know if the website is sending it conformant messages and implied behaviors. (See https://github.com/WebOfTrust/signify-browser-extension/blob/945a7a6e49a17a1b4be2634fb9af8721668d113a/src/pages/content/index.tsx#L21) In the current design, this could be dealt with in the future by: a) adding more type and subtype values if/as needed, or by b) making room for a version property of the sending webpage, either on whatever is the initial message interaction with the extension, or on every sendMessage call. With this, the service-worker and extension pages could provide meaningful feedback to the user (or log entries) when the website is interacting in an outdated or unsupported manner. Btw, it appears like the current service-worker message handler currently quietly ignores unrecognized messages (https://github.com/WebOfTrust/signify-browser-extension/blob/945a7a6e49a17a1b4be2634fb9af8721668d113a/src/pages/content/index.tsx#L107), where logging there might improve the speed of resolving integration issues for new features.