On 2020-07-28 at 18:22 -0700, Ayoub Misherghi via Gnupg-users wrote: > Before that happens. I am coding a prototype right now that is not going > to be inadequate; but all this will help me arrive at a better > understanding, help demonstrate basic ideas and hopefully prepare me and > others for the production of a better specifications, better action and > better product.
Please do not take offense at this, but I think you are way off-track with how you are exploring solutions. I suspect a good solution should go through a different venue. This includes the diode proposal in the thread. It works for limited use cases such as the voting system, but I don't think it could serve well for «Client programs access server(s) for real-time encryption or decryption». However, at this point I think the real problem has not been specified properly, and so we lack enough information to properly think what you might need. And I think you are way earlier than a prototype phase. In fact, it can be detrimental in that it can be leading the proposing solutions on one way, while there could be a better one (plus the cost of preparing a useless prototype). You should have at least a rough idea on what the design will involve before preparing a prototype.* * Actually, on a system you will find *several* designs. It's fine to code a prototype of the UI with little knowledge on how the backend will be designed, it might be enough to know the basic that there will be a username and password, and code from that to start exploring how to integrate it with the rest of $ENVIRONMENT. OTOH, if that small premise happens to be wrong (let's say there are no user and password fields, it's all passwordless authentication based on SAML single-sign-on at a different portal, to whom the users authenticate using FIDO keys) that prototype would be of no use. Regards _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
