somery

It's great that such communities exist, but I personally prefer Discord

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.

Hi everyone, Alex here, one of the co-founders of DocuSeal.

We're using Ruby on Rails and Vue to build DocuSeal and it really helps us to stay lean and ship features fast while being bootstrapped.

Here is a short list of what the tool can do:

- Automatic eSignatures

- Multiple submitters

- 10 document form field types

- Emails via SMTP

- AWS S3, GCP, Azure Cloud files storage

- Open large files up to 500MB

I'm happy to answer any questions!

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

The solution utilizes a native web elements (aka web components) browser API for easier embedding into websites: https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...

Basically instead of using JS snippet for mounting the UI - we're using a custom web element so it can be embedded just with HTML tag without JS.

Hi, it's Alex from DocuSeal.

Recently we released a new embedded JS api for document signing at DocuSeal. Instead of doing it via iframe we decided to provide a JS-based solution.

Here are some benefits over iframe:

- faster load speed

- easy to customize

- optimized on different screen sizes

Also there is a React components library which also works with SSR Next.js https://github.com/docusealco/docuseal-react

Looking for some feedback and would be happy to answer any questions.

Thanks! :)

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.

Self-hosted Docuseal also sends emails to the signers - you just need to add your SMTP configs to send emails.

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.

Yep, support for SMS verification will be added eventually with ability to bring own Twilio credentials when self-hosting it.

That's a good idea! will definitely add this feature to the project

Thanks, please feel free to open an issue with your suggestion to improve the tool at https://github.com/docusealco/docuseal/issues

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.

https://en.wikipedia.org/wiki/Merkle_tree

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.

thanks, i think that's an interesting space to explore. there were many comments regarding the 'consistency' of the data/documents so solving this 'trust' issue especially when selfhosting it is really important

>A self-hosted digital signature system isn't worth anything in court; the other parties will simply reject the authenticity of any data held within it and the amount you'd have to spend to get that data into evidence would probably pay for several centuries of DocuSign's enterprise edition.

When self-hosting it - you can integrate it with AWS s3 Azure or Google Cloud files storage - those are the trustworthy third parties that provide the entire history of logs to ensure that the documents were not altered and signed at specific date/time with the specific content.

So bringing cloud storage providers as a thirdparty when self-hosting will bring enough evidences to the court to defend the signed documents.

When self-hosting it - it's up for the company that is using the tool hosted on-premises to ensure that all their specific requirements are met - i think DocuSeal provides enough features to make this happen.

AWS S3 to store documents can be integrated with DocuSeal to ensure the documents integrity - AWS services have their own logs that can't be altered and so can be used as a source of trust.

And to ensure that the document was signed by a real person companies can include photo attachments into the documents signing process (this could be a photo of an ID card or a selfie)

That's interesting that you ended up developing an in-house document e-signing feature for your product. I'm curious, would it be possible for you to choose a self-hosted and open-source solution like Docuseal, integrated with your product to outsource the complexity and speed up the development? (if such an option existed back then?)

When selfhosting it - it's possible to connect AWS S3 to store the documents - AWS with S3 logs could be used as a source of trust to ensure the documents are not altered.

The emails are automatically sent to the recipients after you submit the modal window to add them (there should be 'SENT' status displayed next to their emails)

Regarding the form issue - it looks like some js client side bug - i'll try to investigate this.

can you please elaborate what exactly from docsend you'd love to see available in docuseal?