Aisland Docsig

[poseidon-aisland]

Project Abstract

Aisland Docusign allows to e-sign documents, exchange easily and store permanently on chain as legal proof.

Grant level

• [x ] Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• [x ] I have read the application guidelines.
• [ x] Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• [x ] The software delivered for this grant will be released under an open-source license specified in the application.
• [x ] The initial PR contains only one commit (squash and force-push if needed).
• [x ] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[Noc2]

Thanks for the application. I have one initial question and to double check: So you are only storing the hashes of the document on-chain, and you use mariadb for the rest, correct? In some cases, you say the documents are stored on the blockchain, which I guess isn't the case. Are you considering using a decentralized storage solution as an alternative for the db? Also, it looks to me like you already implemented: "Substrate module: pallet-docusign" or are you planning to integrate additional features as part of the first milestone?

[poseidon-aisland]

Many thanks for the fast answer, probably we have not been clear in the project description, in the paragraph "Project Details" we describeb the current MVP that is available in source code and live demo. In the paragraph:
"Details of the Proposal", we described the feature that we wish to add. At the line 88 you will find the answer to the storage question:
"4) Documents Storage - We will optionally store on-chain the signed contracts. We wish to give immutability of whole document even if it's little bit more expensive. Actually the MVP is storing only the hash of the document and keeping the document in the server storage. The pallet will be modified to accept the storage of an encrypted binary blob with some limitations in size to be configured in the pallet itself.
We will add 2 functions to the current pallet: newBlob(id,documentdata), deleteBlob(id)"
Shall I try to clarify better the differences from the MVP and the project proposal?

[poseidon-aisland]

Frankly we don't like too much IPFS since someone have to keep the pinning active. We are more inspired from ordinals/bitcoins that are storing everything on chain for low cost.

[poseidon-aisland]

In the first Milestone there are the new functions to store the documents on chain

[poseidon-aisland]

shall we change something in the PR?

[Noc2]

I'm sorry for not getting back to you sooner. Yes, please feel free to update the application.

[poseidon-aisland]

No problem, we would not change anything really, but if you think that Web3 likes to use Crust or IPFS we can change accordingly. Looking forward to your input.

[Noc2]

Many thanks for the fast answer, probably we have not been clear in the project description, in the paragraph "Project Details" we describeb the current MVP that is available in source code and live demo. In the paragraph: "Details of the Proposal", we described the feature that we wish to add. At the line 88 you will find the answer to the storage question: "4) Documents Storage - We will optionally store on-chain the signed contracts. We wish to give immutability of whole document even if it's little bit more expensive. Actually the MVP is storing only the hash of the document and keeping the document in the server storage. The pallet will be modified to accept the storage of an encrypted binary blob with some limitations in size to be configured in the pallet itself. We will add 2 functions to the current pallet: newBlob(id,documentdata), deleteBlob(id)" Shall I try to clarify better the differences from the MVP and the project proposal?

Feel free to clarify this a little bit in the application. You don't need to update the storage solution.

[poseidon-aisland]

we have improved the project description as suggested.

[Noc2]

Thanks for the update. I'm happy to go ahead with it and share it with the rest of the team.

[takahser]

@poseidon-aisland I have a few questions regarding your proposal:

• Did you confirm that that's not problematic regarding copyright infringements?

  The blockhain side is based on a custom pallet named docusign.

• Is there a specific reason you're using vanillajs rather than a modern single page framework like react, vue or angular for implementing the web ui?

  The Dapp is built on HTML,CSS and vanilla javascript for the client side.

• Is Aisland Dao a registered legal entity?

  Registered Legal Entity: Aisland Dao

[poseidon-aisland]

@poseidon-aisland I have a few questions regarding your proposal:

• Did you confirm that that's not problematic regarding copyright infringements?

  The blockhain side is based on a custom pallet named docusign.

We were expecting the question:), we see the "legal problems" as "legal opportunities".
Docusign is the name of the biggest company in the field of document e-signing. The company is owned from Microsoft and has available an army of lawyers scanning the internet in search of "job". The level of harassment is so high that every time you create a service with something reminding a signature and a document they will make a legal action.
Recently they took in court "Sign-a-Doc", similar to their name? No, but hiring top lawyers with the risk to pay their expenses scares any contender, right? So they always win.
At the side of acting as a bully, do they have the legal right to block he usage in any form of the words signature and document? We don't think they are right.
We don't use any brand, logo or design similar to their service, we wish to use 2 words existing since thousand of years and that no one can claim as their own. We could change the name to something different like docsign, signdoc but considering the past, the move will not avoid legal actions from their side.
We are ready to legally challenge Docusign and create a precedent in benefit of the WEB3 and any Dao willing to establish in the international waters.

• Is there a specific reason you're using vanillajs rather than a modern single page framework like react, vue or angular for implementing the web ui?

  The Dapp is built on HTML,CSS and vanilla javascript for the client side.

Thanks for asking, we considered to use React instead of Vanilla Javascript for this project and this is the outcome of our internal discussions:

1. React has been created and currently maintained from META. A good Web3 project should start from reducing the dependency on big corporations. Like Web3 Foundation is using Matrix for standard communication, Whatsapp,telegram,messenger were easier and widespread, at the same time you decided to stay away.
2. React creates a lot of boiler plate that we don't need for this project.
3. Javascript is lighter and faster since interact directly with the real DOM. Reacts keep a virtual DOM to update the real one and check continously for changes.
   Vanilla JS is faster than any other frameworks. It renders the UI thirty times faster than React JS. In Vanilla, the handling of the UI state is simple and bi-directional.
4. We can always use in the future React components with the current code base . In effect even Facebook had many parts written in vanilla Javascript and slowly moved to React.js.
   Based on those above points, we decided to write the UI using vanilla Javascript.

• Is Aisland Dao a registered legal entity?

  Registered Legal Entity: Aisland Dao

We apologize for so much troubles and explanations we are giving back. Our answer means that AISLAND is a DAO registered on the blockchain. I assume your question is, "are you registered under some centralized authority?" No, since Aisland is the decentralisation of real life in the high sea, it does not make sense to register a company under some different country.
Shall we change the statement in the application?

[semuelle]

it does not make sense to register a company under some different country.

Upon approval of a milestone, we require an invoice containing a name, postal address and VAT ID if applicable. Will you be able to provide these?

[poseidon-aisland]

it does not make sense to register a company under some different country.

Upon approval of a milestone, we require an invoice containing a name, postal address and VAT ID if applicable. Will you be able to provide these?

We can make invoice from our software house registered in UAE.

[Noc2]

@poseidon-aisland: Not sure if you are allowed to use the name Docusign. You might want to look into this and give your project a different name.

[dsm-w3f]

@poseidon-aisland thank you for the application. Besides the location and name problems, I think the application is interesting and the price charged is fair. My willingness is to approve, I'm just waiting for the final adjustments in the application.

[takahser]

@poseidon-aisland sorry for the delay here. Your preference for VanillaJS seems largely predicated on comparisons with React. However, other single-page application frameworks (e.g. Angular, Vue, etc.) could serve as viable alternatives to VanillaJS. I believe leveraging such a framework could result in a more maintainable codebase. In my experience, writing comprehensive applications in VanillaJS often imposes significant maintenance challenges. While you mentioned performance as a factor independent of React, IMO it's not a relevant concern for a web UI application. At least I can't think of any current real-world scenario where a React (or similar framework) app was performing poorly due to framework limitations on any widely used device but feel free to convince me otherwise. :)
Finally, I advocate for using TypeScript over JavaScript to improve code maintainability and avoid errors regarding types, property access, null pointers, etc.
Regarding the other issues (naming, entity) I agree with the overall sentiment that it'd be better to change them.

[poseidon-aisland]

@poseidon-aisland: Not sure if you are allowed to use the name Docusign. You might want to look into this and give your project a different name.

We renamed the project DocSig in the whole source code base and documentation.
DoCSig is not registered asa brand anywhere and on google we have found only "AMA DocSIG is the American Marketing Association's special interest group " which is not related to document signing.

[poseidon-aisland]

@poseidon-aisland sorry for the delay here. Your preference for VanillaJS seems largely predicated on comparisons with React. However, other single-page application frameworks (e.g. Angular, Vue, etc.) could serve as viable alternatives to VanillaJS. I believe leveraging such a framework could result in a more maintainable codebase. In my experience, writing comprehensive applications in VanillaJS often imposes significant maintenance challenges. While you mentioned performance as a factor independent of React, IMO it's not a relevant concern for a web UI application. At least I can't think of any current real-world scenario where a React (or similar framework) app was performing poorly due to framework limitations on any widely used device but feel free to convince me otherwise. :) Finally, I advocate for using TypeScript over JavaScript to improve code maintainability and avoid errors regarding types, property access, null pointers, etc. Regarding the other issues (naming, entity) I agree with the overall sentiment that it'd be better to change them.

We have renamed the project and updated the legal entity.
Regarding the frameworks, our choices are mainly influenced from my mentor who worked in cyber security for 40 years.
Reducing the dependency from "free" frameworks built and maintained from big corporation is quite a dogma.
It's surely possible to make software in Javascript/html/css easy to mantain, when well documented and organised.

Typescript is maintained from Microft, React from Meta, Angular from Google, Vue may be the one independent,.
By the way rewriting the current code base on Vue, would extends the scope and the cost of the project.
Frankly, we don't want to nullify the work already done because it will cost more than the requested grant.

[takahser]

We have renamed the project and updated the legal entity.

Thanks, LGTM now.

Regarding the frameworks, our choices are mainly influenced from my mentor who worked in cyber security for 40 years. Reducing the dependency from "free" frameworks built and maintained from big corporation is quite a dogma. It's surely possible to make software in Javascript/html/css easy to mantain, when well documented and organised.

I agree that this can be a problem, but usually the trade-off for this little risk is made in most frontend projects. Although these frameworks are maintained by big corps, they usually still have open source licenses. Hence there's a lot of transparency that greatly mitigates the risk. Personally I think it's possible to write maintainable web applications in vanillajs but it's much more difficult than when using a suitable framework. Also, good user experience is usually much easier achieved when using them. From looking at your PoC I see quite some problems in this regards - it's rather difficult to use (see also my inline comment). If you really want to go this way, I'd like to see some past vanillajs web applications that your team has written in the past.

By the way rewriting the current code base on Vue, would extends the scope and the cost of the project. Frankly, we don't want to nullify the work already done because it will cost more than the requested grant.

I understand that it might come with some additional costs. Hiking them to $10k (+~10%) wouldn't be a problem I think.

[takahser]

I tested it but after initially signing it with the doc creator account I wasn't able to sign it with a counterparty account:

As you can see the status is Waiting here. If I now copy the link:

...and paste it in a different browser session to try to sign it it won't work. Instead I get an error when viewing it.

[poseidon-aisland]

thanks for reporting the issue. We have pushed a set of changes that should have fixed the issue above.

[poseidon-aisland]

We have renamed the project and updated the legal entity.

Thanks, LGTM now.

Regarding the frameworks, our choices are mainly influenced from my mentor who worked in cyber security for 40 years. Reducing the dependency from "free" frameworks built and maintained from big corporation is quite a dogma. It's surely possible to make software in Javascript/html/css easy to mantain, when well documented and organised.

I agree that this can be a problem, but usually the trade-off for this little risk is made in most frontend projects. Although these frameworks are maintained by big corps, they usually still have open source licenses. Hence there's a lot of transparency that greatly mitigates the risk. Personally I think it's possible to write maintainable web applications in vanillajs but it's much more difficult than when using a suitable framework. Also, good user experience is usually much easier achieved when using them. From looking at your PoC I see quite some problems in this regards - it's rather difficult to use (see also my inline comment). If you really want to go this way, I'd like to see some past vanillajs web applications that your team has written in the past.

By the way rewriting the current code base on Vue, would extends the scope and the cost of the project. Frankly, we don't want to nullify the work already done because it will cost more than the requested grant.

I understand that it might come with some additional costs. Hiking them to $10k (+~10%) wouldn't be a problem I think.
To be realistic, the rewriting with Vue will take 3-4 weeks for 1 senior FTE. A 2/3 of weeks to do the job and 1 week for fine tuning.
In reality, we use an UI framework: Bootstrap:)

In terms of other works done you can take a look to:
https://github.com/aisland-dao/dex
It was between the winners of an Hackaton:
https://dorahacks.io/hackathon/decreasing-frictions-in-defi/results

There is instead a quite big code base, more than 100K lines of code between servers side and ui:
https://openmarket.ae
The repo is private, here a screenshot:

Just for fun, let me share a movie script, nothing real:

The big tech Evil Corp controls social networks, search engines and any kind of cloud services. A group of people stays outside their influence pushing for the decentralisation for all the stuff the Evil Corp is doing.
These strange people call themselves white hats, hackers, web3 developers.
So, the Ceo of Evil Corp designs a methodology to control them:

1. Creation of cool frameworks for the developers;
2. Offering of cool cloud services, so developers do not need to know how to install a web server or a database, Evil Corp will do it.
3. The frameworks shall use a lot of dependencies, some developers with fake names and controlled from Evil corp will manage some of them.
4. Every time Evil Corp wishes to tap info from the Dapps,Evil corp will inject some code in the version in use and will deploy it in a few minutes all over the world, thanks to free CDN services.
5. If someone will notice it, it will be the fault of a hacker, a CVS will be open and ready for the next round....
6. Don’ forget to give free DDOS protection so even the TLS certificates are controlled from Evil Corp.
   This is the start…..

[takahser]

@poseidon-aisland thanks for your reply.

About the DEX repo you shared, I'm confused why you have a react directory while all your relevant code seems to be vanilla js/html:

The UX is arguably not very good but I understand that it's a hackathon project, so the standards are naturally much lower.

When it comes to the marketplace you shared, I'm not convinced about the UX and performance:

These kinds of problems can at least partially be solved by using one of these frameworks. For this reason I'm not convinced about your argument that performance is why you're using vanillajs. Hence, I decided not to approve it as long as you're not using one of the widely-used singlepage app frameworks.

[poseidon-aisland]

@poseidon-aisland thanks for your reply.
These kinds of problems can at least partially be solved by using one of these frameworks. For this reason I'm not >convinced about your argument that performance is why you're using vanillajs. Hence, I decided not to approve it as long >as you're not using one of the widely-used singlepage app frameworks.

Thanks for the patient and efforts in the analysis of our work, you did not like the movie script clearly :)
On dex.aisland.io there is a single react component because it was a requirement from the hackaton the usage of a specific wallet interface. The mixing is not an uncommon situation in existing projects that start to use react components.

Regarding the performance analysis, I cannot understand the origin of that report, by the way running the google service https://pagespeed.web.dev in comparison between https://amazon.com and https://openmarket.ae the result is very different and declares openmarket as the winner ( I am really surprised :) )
amazon_analysis.pdf
openmarket_analisys.pdf
"God Save the Javascript" :)

[takahser]

@poseidon-aisland I ran it on Google's PageSpeed Insights as well and the results were similar:

[poseidon-aisland]

good now try desktop and make the same against www.amazon.com which is for sure the reference for a market place.

[poseidon-aisland]

All the suggestions that you see in the tools are the same for both vanilla javascript or any framework that transpiles in javascript. If you wish faster loading you have to use less an lighter images. By the way just to resume the reasons for using Vanilla Javascript against frameworks:

1. Security
2. Speed
3. no meaningful differences for maintenance or development.

[poseidon-aisland]

As you see speed insight gives different results on amazon.com every time you run.Ssometimes openmarket is better and sometimes is a little bit lower. By the way considering that Amazon has an army of developers and openmarket had only our small team, you cannot deny that is a very good result and the test on the main page is not really so meaningful in term of performance.

[semuelle]

Are you familiar with Svelte, @poseidon-aisland? Might be interesting.

[takahser]

@poseidon-aisland

Speed
If you wish faster loading you have to use less an lighter images.

I agree that that's a major factor indeed. However, docsig doesn't seem to rely much on images (unlike your store). Hence, performance becomes less of a problem, correct?

Security

In case you refer to the CDNs you mentioned in your movie script: Nobody forces you to use CDNs, even when using one of these frameworks. If the devs managing the frameworks are infiltrated by evil corp, to stay at your script, I think as long as it's open source, there is public scrutiny and I'd like to assume that enough (white hat) eyeballs rest on these code bases. If that assumption is true, I think it's a fair assumption to make that if something fishy was pushed to the affiliated repos >=1 of the white hats would notice and complain about it.
Regarding React specifically, afaik they had some exotic open-source license with a patent in the past, but it seems as they've moved to a standard MIT License in the meantime.

no meaningful differences for maintenance or development

I strongly disagree - with vanillajs the codebase would usually be less structured and more repetitive, affecting maintainability. Also, the reusability is affected since most devs don't use vanillajs for writing single-page apps.

[github-actions]

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at [email protected] and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

[poseidon-aisland]

Are you familiar with Svelte, @poseidon-aisland? Might be interesting.

No, but I've checked after your messages and seems quite cool and maintained from a good group of contributors.

[poseidon-aisland]

@poseidon-aisland

Speed
If you wish faster loading you have to use less an lighter images.

I agree that that's a major factor indeed. However, docsig doesn't seem to rely much on images (unlike your store). Hence, performance becomes less of a problem, correct?

Right:)

Security

In case you refer to the CDNs you mentioned in your movie script: Nobody forces you to use CDNs, even when using one of these frameworks. If the devs managing the frameworks are infiltrated by evil corp, to stay at your script, I think as long as it's open source, there is public scrutiny and I'd like to assume that enough (white hat) eyeballs rest on these code bases. If that assumption is true, I think it's a fair assumption to make that if something fishy was pushed to the affiliated repos >=1 of the white hats would notice and complain about it. Regarding React specifically, afaik they had some exotic open-source license with a patent in the past, but it seems as they've moved to a standard MIT License in the meantime.

On this part please take a look to:
https://www.cvedetails.com
and you will see how many open source projects had security bugs even for years.
The reason is because reviewing source code line by line is time expensive and boring. Only expert developers well paid can do it. On the other side there are 1000 different methods to make a coding error that creates a back door. Even polkadot.js has so many dependencies that you cannot really be sure how safe it is.

no meaningful differences for maintenance or development

I strongly disagree - with vanillajs the codebase would usually be less structured and more repetitive, affecting maintainability. Also, the reusability is affected since most devs don't use vanillajs for writing single-page apps.

You should use functions and/ior modules to organise well your code and reuse in the whole project or different projects. At the end the world of npmjs is based on this modularity.
In terms of developers with knowledge of javascript, 17.4 million in 2022 are quite a lot and it's the most popular language:
Most popular languages

[takahser]

and you will see how many open source projects had security bugs even for years.

Sure, but you're writing open source code as well and it's most likely subject to less scrutiny than the big SPA web frameworks that is used by millions of developers. :)

In terms of developers with knowledge of javascript, 17.4 million in 2022 are quite a lot and it's the most popular language

you're comparing a language (js) with frameworks that are written in that very language here...
but anyway, I'd still recommend you use the framework/library of your choice, no matter if one of the big 3 or svelte, ember.js, backbone.js or another alternative

[poseidon-aisland]

Thanks for the recommendation, we will consider some additional UI framework whenever useful and not reducing the security. At the first sight, Svelte seems cool. I sincerely appreciated the fair exchange of opinions and yours are respectable.