##Edit: Community vote has passed.
Thanks for Voting!
NEM Apostille – A Blockchain Based Notary, Proof-of-Existence, and Auditing Service
Community Funding
This project is being proposed to be funded with 5 million XEM from the Community Fund, to pay for bounties to the engineers/designers, operation costs of maintaining servers, as well as other expenses that might arise during a one year time period. At this point it is an open-source project with code released for the NEM community and 3rd party developers benefits. It is currently being designed and planned as a non-profit venture.
Team Members
Jeff – Project Manager and Designer
Rev – Web Service Engineer
QM – Wallet Service Engineer
Goal
To build a Factom/PoE like service on top of NEM that can 1) prove that a certain version of a digitized file existed at a certain time, and 2) that follows the process development and evolution of that document, and 3) serves as a method for auditing the history of said documents.
Possible Use Cases of NEM Apostille
Securing time stamps and fingerprints of important documents to prove that a certain version of those documents existed at a certain time, making back dating and editing impossible. This has a wide possibility of uses including asset exchanges of all kinds, security applications, patents, record systems, publishing, and more.
What does he name “NEM Apostille” mean?
The idea of an apostille was popularized during the Hague Convention as a notary stamp for international certifications. The convention has 110 nations participating. NEM Apostille takes the concept to the next level with making a notary system that anybody can use anywhere for any type of document not based on political authorities but on math and science.
User Experience for Web Service Free Version
A user can register an account on a web portal.
Once a user has made a user profile they can then upload a digital file; that file is hashed making a fingerprint of the document, the hash is then signed and then included in the blockchain. This transaction acts as a NEM Apostille notary.
When submitting the document during the hashing process they can choose to tag the document with a metadata name. A new account is generated for each of these metadata tags. A tag is just simply generating a new account and naming it with a label, not very different than what NEM does when a new account is created in NCC and labeled. (But this might need to be in a different location, not the address book file. More like an Apostille address/tag book that is separate from the normal address book. Same structure, but a different place.) We are proposing that account labels/tags are only known locally. This in theory is used to track the progress of that document over time. So each new updated version of that document will have that specific tag/label/account the hash is sent to. The receiving account will basically be logging a history of hashes that represents the file changing over time. When typing in a tag for an account, a suggest list of previously used tags by that person will auto-suggest.
A separate log history is made that logs the file’s name as it was uploaded, the hash of the document, and all the transaction details for its posting on the chain, as well as with the receiver address and the tag it represents.
A proposed email or log history entry would look like this the following:
File Name: Jabo38 cool solar panel project.txt
File Hash: 6c4520d2e4b41267b2be9ad129117058af9578b0a7e912ab5… (these hashes are truncated in this proposal for reader’s ease.)
Hash Signature: ntya:a0f6884f41d5ac6f019ac10402143b7cab8acc32795efa29e96d4a…
Receiving Account: nbzmqo-7zpbyn-bdur7f-75maka-2s3dhd-cifg77-5n3d
Receiving Account Tag: Solar Panel Poject 2016
Transaction Hash: 96dbd555a2a15b0cfdb960b1b3384f4d5a1e2ce1672dc5abc7fcb41917552881
Transaction Time Stamp: 2016-03-19 08:21:16
Later on, they might update this file and want to save a hash of a new version. Said transaction might look like this.
File Name: jabo38 cool solar panel project version b 3/29.txt
File Hash: 7530477efe6a35c79ccdfa5daff5d8bcbfe49845b2917b10b8748…
Hash Signature: ntya:d9fb77fa5edbee5e2d3f40728361dbbaa3d639002726ec3d1ece2d23c…
Receiving Account: nbzmqo-7zpbyn-bdur7f-75maka-2s3dhd-cifg77-5n3d
Receiving Account Tag: Solar Panel Poject 2016
Transaction Hash: 24f0db5400585339705aa8ac929774bf6b7330810c03bc2a0ca4038ac41aacff
Transaction Time Stamp: 2016-03-29 09:27:45
And now the file can be seen to be changing over time.
For this free non-profit version, a person will get so many free notaries to the chain (possibly 5-20 depending on funding; funding that will be sought outside of the realm of this proposal.). After they use those free notaries, then instead of automatically making a notary in the chain for them, the website instead gives them a QR which they then scan from their mobile app. All information needed is preloaded, they then only need scan and press send. (They could also be given info to manually copy and paste if they didn’t have a mobile app).
Additional Option Being Considered: It might be possible that the person wants a copy of the file included in an email receipt, essentially using the email service provider as their cloud storage provider too. If so and in that case, they should be able to check a box. It would be nice for them to have all the files and notary information paired together in a place where they can easily find it.*
Another option might be that when a file is hashed and processed, then the original file and a receipt of the transaction are zipped together and can be downloaded directly.*
Additional Option Being Considered: It would also be interesting if the website had a mobile version so that people could just take a pic of a document or other said item, have it hashed and a compressed version of that pic and receipt sent to their email.*
Additional Option Being Considered: A system of publishing the account label/tags on the blockchain so they can be known not just locally, but also globally.*
*These optional configurations need to be built and tested to see if they are the best option for the platform.
Web Service Mockup
(Audit and History sections of website can draw inspiration from the Lightwallet example below. Actual Apostille website WILL look different. This is only a concept.)
User Experience for Lightwallet Notary System
A fork of the lightwallet will have its own independent and fully functioning notary system.
A person gets a wallet, account, and funds on their own (the NEM faucet can help fund initial tests). Once they have a funded account they can navigate to the Operations Panel. One of the options will be to Create/Review/Audit Notary. Clicking on that takes them to an Apostille Panel. As with the website, they can upload a file, it is hashed, the hash signed, a new account is created that is paired with a new tag or a previously created tagged/account is selected. The hash is sent to that account creating the notary and a log is made in the user’s notary history that logs all the data of file, hash, signature, tag, and transaction.
Lightwallet Mockups
(Actual Apostille service in the wallet WILL look different. This is only a concept.)
Following and Auditing of a File or System of Files User Experience
An account/tag is entered and a file or set of files is uploaded and the two are referenced to find matches between files and blockchain hashes referencing selected documents. A report is given verifying that uploaded document or versions of document existed at a specific point in time.
Additional Option for Web Service and/or Wallet
Possibly the option of uploading a text into a text box might be possible, in which a txt file is created for a person to download and save locally on their computer. The metadata of that file/hash/transaction is possibly made in a second file and the two are zipped together or some other system is made.*
*These optional configurations need to be built and tested to see if they are the best option for the platform.
Critical Criteria for Consideration
Amount Requested: 5 Million XEM is being requested.
Active Members: Active members participating are Rev, QM, and Jabo38, each of which has been involved in many NEM related projects.
Stakes in the Game: This is a non-profit project and will be given freely to the NEM community. The stakes in the game are that Rev, QM, and Jabo38 are already invested in NEM technology and would like to see it grow.
Milestones:
Milestone 1: A working website OR light wallet add-on that is able to hash, tag, and upload said hash to the blockchain. Requested amount 1.5 million XEM. To be finished by the end of May 2016.
Milestone 2: Version 1 Complete. A working website AND light wallet add-on will both be able to hash, tag, sign, and upload that signature to the blockchain. Auditing services and history review is added to both platforms. Requested amount 2 million XEM. To be finished by the end of June 2016.
Milestone 3: A continued development and maintenance of both the webservice and lightwallet with integration of option features, updates, and redesigns based on feedback. Requested amount 1.5 million XEM. To be finished by the end of December 2016.
Project Details and Summary Discussed above, but more details will be given on the forum or to the core team for review upon vote.
Company: This project is an open-source non-profit project and at each milestone payment, code will be posted on Github.
Real Identity: Jabo38 as project manager will be revealing his identity during the project applications process to the Core Team reviewing the proposal.
I also hope that this can be forked into the main Lightwallet, or just become the main lightwallet but ultimately Gimre will have to consider that and how it fits into the greater plans.
