In this highly competetive market we're currently more focused on things that we can do better like on-premises and embedding/API.
DocuSeal doesn't require any significant initial costs to be built - and then it comes only to our ability to build a great product to come over the competitors.
Regarding the compliance we're focused on simple eIDAS signatures for the EU and also we follow the UETA and the ESIGN Act.
When comparing to Iframe our JS-based solution better adopts to the existing page layout due to the fact that it embeds into the existing page DOM (when iframe lives in it's own DOM which brings many limitations). Also it loads much faster than any equivalent iframe solution
Hi everyone, my name is Alex, and I'm the CTO and Founder at DocuSeal – an open-source alternative to DocuSign.
Recently, we launched DocuSeal Cloud, which is available in both the US and EU regions. Our goal is to create a developer-friendly document signing infrastructure, similar to how Stripe has revolutionized the payment infrastructure. The HTML API described in this blog post is the first step of this initiative. You can find more information about the developer tools at DocuSeal here: https://www.docuseal.co/integration.
Looking for some feedback and would be happy to answer any questions.
I mostly agree with the author. After working a couple of years with React client render and API a pure server render seems to be a way more productive. For my recent OSS project (https://github.com/docusealco/docuseal) I use server render everywhere except of the 2 most complex/dynamic UI parts (drag&drop form builder and the signing form). I think just figuring out which approach fits best for which part of the software is the most important thing, doing both SSR and CSR in a single project is completely fine when done right.
Currently the documents are signed with PKCS#1 signature, signed documents can be verified at https://demo.docuseal.co/settings/esign (to ensure that they were produced by the tool and not altered/forged by some third party). Additionally I'm planning to add a merkle-based log of documents to ensure that documents were not altered by the party that is self-hosting the tool.
When self-hosting it it's possible use merkle tree to ensure the documents integrity (similar to how git works with its commit hashes).
So to forge one document it will require to change all document hashes after the disputed document making it impossible to cheat by the organization that is self-hosting it. This will be added into the project soon.
Alternatively I'm thinking about adding a third party AWS QLDB integration - QLDB allows to maintain an immutable, cryptographically verifiable log of data changes.
I think that's a valid point - and actually in their terms of services say that they are not responsible for the signer authenticity.
Here is a summary from their TOS:
"DocuSign provides tools and features that help to establish the authenticity of a signer, such as email verification, access code, SMS verification, phone verification, and knowledge-based authentication. However, it's important to note that while these tools can enhance the security and authenticity of the signing process, DocuSign itself does not guarantee the authenticity of the signers. The responsibility of ensuring the identity of the other party lies with the user"
It's hard to say at this point if something like Let's Encrypt can exist in this space - but I'm for sure going to continue offering a free Cloud SaaS option with a generous set of features for document signing.
I'd love to chat to explore more about the potential non-profit solution - please feel free to drop me a line at [email protected]
Thanks for the feedback! All your UI suggestions/fixes make sense and will definitely be brought into the the tool soon! Also I like the idea of using some 'fake' legal document for the demo.
Regarding the iframe - i've been thinking about creating an npm package for better integration with the host app - but maybe giving an option to use iframe should be available as well for companies that don't have developers to implement a better integration with the npm package.
can you please elaborate which use-cases? - maybe that's something that actually can be possible by splitting some parts of the project into MIT licensed dependencies?
It's possible to use local storage or Aws s3, Azure, Google Cloud to store files.
When storing locally it makes all the documents 100% owned by you - but in some cases companies might want to bring a third party files storages to ensure the integrity of the documents.
But as was mentioned before in the comments - maybe bringing AWS QLDB as a third party to ensure the consistency of data with a local files storages is the best option. This way all documents can be logged with a third party so they can't be altered - while to content of the documents won't be shared with any third party.