While Private Invoice is still a work in progress I wanted to come back and take a second to introduce what Private Invoice is, what the concepts are around it, and direction of the project.
What is Private Invoice?
Private Invoice is a self-hosted invoice management system. You can set up your own Private Invoice instance and exchange invoices with other Private Invoice instances. Instances are able to create contacts via a handshake that takes place using Verifiable Presentations using the Traceability-API.
Right now payments for each instance are handled using Ethereum. The prototype phase is using a internal ganache instance to be able to easily test interactions between members who have registered. A wider proof of concept might be done with the Ethereum test net. But right now an actual implementation for exchanging funds might be done with something like Stripe.
What is the concept of Private Invoice?
The concept of Private Invoice was to take the concepts of web3 and put them into a practical package that would be easy to adopt. Rather than having a centralized monolith applicationation, individuals and organizations would be able to create and manage their own instances and their own funds.
This approach asks the question of how do you establish trust between parties, and how do you create an environment where organizations can be confident they get paid?
To be honest, I don't have an answer for the second option. I'm not sure if it means having some kind of opt-in Escrow service, or relying on smart contracts to ensure that contracts are fullfilled. But the first issue is addressed by decentralized identifiers and verifiable credentials.
Decentralized identifiers allow for individuals and organizations to create their own identifier which they can build reputation around. With privateinvoice.io, I already have some amount of reputation from writing blog posts, and making pull requests on Github. I can use that as an identifier to use a public/private key pair to be able to sign verifiable credentials based on that reputation.
With respect to verifiable credentials, the claims in the data are signed, so both parties can share the same copy of a document and prove that is signed by a specific party, and that the claims inside the credential have not been modified.
What is the direction of the Project?
The current direction of the project is currently coming out of the proof of concept / prototype phase. We have three instances:
And have we have confirmed that we create accounts on one, and exchange invoices with another instance. As well as do payments using the same ganache instance.
The next step will be to continue to lock down the back-end. Making the code simplier. Refining the documentation around the API. Adding more conditions to the test postman collection. And finding ways to write Jest tests to test the functionality of the modules in the application.
The other issue is to address the data integrity proof performance issue. Right now when using the data integrity proof, it takes a long time to sign verifiable credentials, send presentations, and verify credentials. It means that the first invoice send takes a long time to send. While the P2P approach gets around this issue by not pushing the performance bottleneck into a centralized service, it's still something to be addressed. And I'm currently thinking that an alternative version of signing the data directly, and not the converted RDF representation of data would be a better way to address this issue.
