Hivevoice Updates: Encrypted blockchain invoice storage and QR code support

in HiveDevs7 days ago

A couple of days ago I released my free invoicing app for Hive called Hivevoice. It allows you to create invoices and get paid in HIVE or HBD.

The initial release relied on SQLite as the database which contained the invoices and invoice items. Which worked fine, but Hive is an amazing blockchain in that it supports all types of data ranging from custom JSON operations to transfer memos (that can also contain JSON), comments and posts. So I switched it to store the invoices as encrypted post data instead.

You can see an example of an invoice I created here.

image.png

It's an encrypted post only visible by the person who sent the invoice and the recipient of said invoice. I leverage a custom tag that I check for when I query Hive for invoices and it works beautifully.

This means SQLite is more of a cache of sorts now and Hive is the single source of truth for invoices. Which means the app itself won't really hold onto anything and everything remains secure and private.

Leading on from this was a feature I wanted from the beginning: QR codes. Allowing users to share payment QR codes containing HIVE/HBD payment information, invoice sharing using QR codes for invoice links and finally QR codes for Hive account addresses for easy mobile wallet scanning.

image.png

I'm also currently working on putting this up somewhere and allowing you to use it without having to worry about self-hosting. That has taken a beackseat to polishing the open source code first, but it's coming.

The source code is on GitHub here with detailed instructions for running it yourself: https://github.com/Vheissu/hivevoice

Sort:  

Awesome idea and I really like that you prioritize open-source over hosting :) I would recommend not using posts. They take too much space and disturb feeds. You could store the invoice head data in a custom json and all positions in each their own custom json. All encrypted with the memo key of the recipient. Custom jsons are way better to handle when it comes to long running systems and they do not bloat the comments entity of our blockchain with unnecessary (empty) data

Edit: if the system is ready to use I can collaborate creating a mobile app in flutter :)

That's really helpful feedback, thank you. I didn't feel good about using posts, but it seemed like the highest level of storage. Multiple custom json ops is actually a better idea. I never even thought about that.

Looking forward for you progress with that!