I’ve been evaluating a lot of the p2p DApp technologies out there, and Holochain looks by far the most promising and exciting! I’m currently developing a Personal Finance app for couples, and because of the private nature of the data (all your bank transactions, investments, assets) I want it to be a desktop/mobile app that uses a p2p database to store the data. I have a lot of experience building Cloud apps, so I want to be able to achieve the same things with a great user experience using a decentralised approach.
We’re building it in Electronjs/Reactjs for now using a SQLlite backend while we figure out the right p2p framework to plug in later. I have a bunch of general questions on the project/community in general I want to ask before we commit (I’m self-funding this project, so I can’t afford to go down the wrong path backing a technology that isn’t mature or hasn’t got enough traction) and also “how to/can it” questions which I’ll start with:
For V1 will store a list of users bank accounts (either manually uploaded from bank statements or synced using Plaid) but later on needs to be able to store investments, assets and other financial data to provide a holistic view across the household finances
Needs to store the user’s data completely privately, however they need to be able to share data with their spouse or an advisor (i.e. Accountant) for specific bank accounts, and ideally also choosing from what date they share data from (i.e. I want to share my Wells Fargo Current Account transactions with my wife starting from 01/01/15 when we were married)
We need to be able to query the data quickly to build reports such as a report that shows spending for each category by month between a start and end date, something we can do currently using a relational SQLite database
It has to be a great, easy user experience like a user can get on any cloud based app in terms of installation, signup etc. They shouldn’t need to know or care about the p2p aspects (although we believe it will be a selling point to users that their data is private).
We need a way to link subscription billing for the app on a per account (household) level, ideally using a Credit Card and not some new tokens a user has to put in a wallet as I’ve seen on other projects
We need to be able to syncronise data with centralised APIs such as Plaid, Stripe (for payment) but also currencies, stock market/crypto price data etc.
So far in my research, it looks like most of this is covered, and using entry links we essentially have a Graph database we can query for users which could have an account, with linked bank accounts with linked transactions, but:
I don’t understand how the private sharing works from the docs/forum so far - is there a detailed guide on how to build an app with our use case of storing and sharing private user data?
To do the SQL type queries we’re doing for reports to ‘groupby’ and ‘sum’ by month/category its not clear how that would work? Do you create a Zome that queries all the transactions for that period then iterates through them all to get to the report?
I can’t find anything on the user experience a user would get using a Holochain app. Is there a live one I can try to see how signup/login looks like? How customisable is login/signup? Can we provide our own UI/signup flow for that?
If a user loses their password, I assume there’s absolutely no way for them to recover their account/data because of the way you generate the private key? If so, any ideas how to ensure less technical or sophisticated users aren’t forever locked out of their account? Also what does the password strength look like? I assume it has to be high to create a strong private key?
How do you design an account model like we need using Holochain? (Users create a household account, and invite their spouse/advisor into it to view bank data that’s been shared and household wide reports - also thinking business accounts down the line so users may belong to several accounts in future)
How do we integrate billing into our app using Credit Cards/Stripe and ensure the user can’t access the app for the paid account if their license/subscription has been cancelled? (We may also do freemium with paid pro features and free forever app too)
What is the best practice way to interface with 3rd party APIs like Plaid or Stripe? Can our app use a central API to get that data and just store the data pulled from them at rest on Holochain? Should we call the APIs from a Zome (but then lose control over billing/API keys being used across lots of agents)?
A household will have 10k’s of transactions over time, on the one hand that is small by Cloud standards, but how performant will it be on Holochain with lots of users storing that data on Holo?
How do we store file data such as invoice/receipt images/files attached to transactions? Do we store it centrally on our own cloud storage encrypted using the user’s private key and put a url link to it on the transaction entity or do you support p2p storage for larger files too on Holo (or plan to)?
That’s the main questions top of mind right now
In terms of other general/community questions, its clear to me that a community is forming around this, but its very very early and Holochain is still Alpha software, so we’d be taking a risk jumping on this. My questions are:
Is there a sense of size for the community and its growth so far? How many startups/people are building real apps out there on this?
When does Holochain expect a production ready version of the platform to be available?
We need Mac, Windows and Linux support - I see Window’s isn’t available right now. When will it be?
How does the core Holochain team get funding? I saw there was an ICO, but once that money runs out, how will the core team continue to get funding to continue working on this full time, or even more importantly, grow the team as Holochain grows to ensure it continues maturing and is supported?
To be clear, I understand this is still a very early project, and I am happy to take some calculated risks if this project can meet our requirements, and help develop around any gaps if the gaps aren’t too wide currently.
I appreciate there’s a lot here, and happy to jump on a call with anyone if its easier. Either way, I appreciate any help on these questions in advance!
Hi, I’m by no means an expert here, and am just getting oriented myself. However, since no one has responded, I thought I would jump in here and give you some answers, to the best of my knowledge. Anyone who knows better, please jump in and correct me.
There has recently been a big rewrite of Holochain’s core systems, which has resulted in a massive performance increase. However, much existing documentation is now obsolete. This should change as the software matures.
Right now Holochain is pretty low level, and a lot of the tools for data handling aren’t there yet. It’s basically a graph database. Right now, I see you as having basically two options. You can build incremental data-flow views into the app, or you can use store entire copies of the data (or deltas for updates) in the chain. You could then run queries locally. Since financial data is not large, this is very feasible for your use case. However, right now you would definitely have to roll your own tooling here.
This is very flexible. You can implement a login any way that makes sense, and there’s not a lot of limitations here. Basically you need an identifier that maps to a public key, and a passphrase to decrypt the corresponding private key
I don’t think there’s a good solution here, at least at the moment. Any centralized password reset mechanism may actually violate Holochain’s Cryptographic Autonomy License.
Users could create different “pseudonyms” for different purposes by creating new public-private keypairs. Alternatively, they could use the same key-pair to participate in different accounts. Holochain is very flexible in this regard.
You could use Stripe, but you would need to implement this yourself outside of the Holochain system. Probably you would need to set up a license system on the front-end.
I’m not sure there’s a good solution for this. Would Plaid allow you to generate a bunch of API keys tied to your account? That way you could create one for each user, and revoke them in if they’re abused.
Holochain should handle this fine. It’s designed to scale linearly with users.
Holochain should be able to handle images and small files just fine. I think the current limit is 16 MB without manual sharding.
On the community questions:
Not sure about this.
It’s unclear. Holochain is a new technology, and there’s quite a bit of R&D and experimentation involved. The team is discovering new approaches as they go, so there’s no fixed timetable.
Not sure, but Windows support will definitely come. Also, mobile support is also on the roadmap.
The core team is funded through a HoloFuel ICO. They are developing a mutual credit currency on top of Holochain that will allow for distributed hosting and cloud services. They plan to take a 1% transaction fee, which they will use to fund Holochain development. Long term, they also want to fund core libraries and apps as well, and shift to a cooperative business model.
Ultimately, I don’t think Holochain is ideal for your project right now. You need something that is mature and proven in production apps. Financial data is sensitive, and Holochain has not gone through a security audit yet. Additionally, the need to use Plaid and credit card subscriptions means that the decentralization benefits will be significantly curtailed. Hopefully, this equations will change in the near future.
Thanks Zach! Appreciate you taking a stab at helping after I didn’t get any reply.
I agree with your overall advice that Holochain isn’t a great fit right now based on its maturity. One thing I didn’t mention is we don’t expect to launch the app until later in 2021 as its a small team and we’re not in a major rush. In terms of timescales I was hoping to get a functional version in Q1, and then pick a DApp technology then (as all the contenders are immature right now) and then look to launch it in Q2/Q3.
So would be really helpful to hear from the core team on what the timelines they are working towards are to get to maturity and address any gaps in the platform. If things are moving fast, maybe those timescales will be OK?
I’m also happy to take a calculated risk on a new technology like this as TBH there isn’t any viable alternative I’ve found without building something from scratch ourselves to do something similar and keep user data decentralised. But of course, key word is calculated, we don’t want data compromised because of maturity issues or design errors if we’re using the technology for something it wasn’t intended.
Regarding 2 - we were discussing something similar - where we store the data locally in SQLite and use Holochain (or similar) just to keep all the users/devices in sync, so may look into that approach. However it feels like an area we could get bugs vs. using the GraphQL “database” for Holochain directly.
Re. 4, I expected that would be the case, I think this is a usability issue for all decentralised technologies and no ones solved the key management issue yet.
I agree that using centralised payment/APIs will be counter to building a fully decentralised app, but I think if we’re going to build good user experiences on decentralised apps, this may need to be what we need to do in the short term to bridge new users starting on DApps vs. giving them a steep learning curve to figure out how to pay for it without a Credit Card, and syncing bank data will need to go through a centralised API because of bank regulations too. In my head at least I’m comfortable with the compromise between taking both approaches - a centralised API for sync/billing but all the user’s data stored “at rest” on the decentralised database.
Anyway, thanks again, if anyone on the core team has anything to add that would be awesome to clarify some of the areas Zach wasn’t sure on and timelines!
Actually, in the mid to long term I think Holochain could be used to build an effective free competitor to Plaid. The biggest problem with Plaid is you have to give them your banking credentials, which they need to store in plain text. (This is assuming your bank doesn’t have a proper API.)
With Holochain, one could create a community for building and maintaining bank scraping recipes. Users could then use those recipes to access data, which would be presented through a nice Zome API. The user would keep their bank credentials in Holochain’s secure local store, and their computer could automatically scrape their bank website periodically, and store the data on their private source chain.
Hi, someone pinged me about this message and I’m glad they did. This sounds like a really exciting app, and I wish it were already built because I’d probably love to use it! Hope the following is helpful…
You can implement privacy a few different ways based on your needs:
Data that’s private to the individual – this gets stored as private entries on their own ledger (‘source chain’). Others request that information by making an RPC to that person’s device. This is the ultimate in privacy and should be used for things like bank logins. The risk with this is that it suffers from availability problems: if the person’s device is turned off, others can’t access their information. And if they ever drop it in the kitchen sink… good bye data.
Data that’s private to the group – in your case, the couple. If you try to join an app’s network space (DHT), nobody will talk to you unless you first produce a ‘membrane proof’ (such as an invite code) and they validate it. Once this happens, you’re a full member and can access all public data. (Note: normally it’s one DHT per app, but you can ‘fork’ an app’s code – say, by changing a UUID in its manifest file – and create a new private space with the same business logic. So each couple would have their own DHT.) It’s still not terribly resilient, because the redundancy is just you and your spouse’s devices – plus maybe a Holo host, which could be a paid, value-added backup service. (Note that the host can access the public data, so your privacy would only be as good as the hosting device’s owner’s promise when they signed a contract with Holo.) Accountants wouldn’t be invited into this space; they’d talk to you and your spouse via a single big global shared space.
Data hidden in plain sight, or public-but-encrypted data. In this scenario, everyone would be part of one big network and they’d publish all of their private data into the ‘crowd cloud’. This is the ultimate in resilience, but of course there’s the issue of couples’ encryption keys getting into the wrong hands.
With a graph database, you don’t have to do expensive joins, but that’s because you have to materialise relationships into links at write time. There are different ways you could do this. Links can have content describing the nature of the relation; it’s called a link tag. You could store something like "2020-01" in the link tag and then ask for just those links. Alternatively, you could create that materialised query an ‘anchor’ (just a plain old raw string that lives on the DHT) from which you could hang all the links that point to ledger entries. The group by would just be a fold() over the retrieved links, no matter how you retrieve them.
Querying on multiple filters at once would get a little more complicated. You could bake multiple commonly paired filters into a tag/anchor, e.g,. "2020-10/#groceries", or you could do two queries and perform an intersection on them.
That’s an area where Holochain is still pretty immature, but I’ll give you a preview of what we’re working on: HCInstall is meant to provide a user-friendly install process for Holochain apps, like an app store experience. But you’re also free to bundle up the Holochain conductor, the app’s DNA (the Holochainy bit), and your Electron UI in one installer – I imagine we or someone in the dev community will create some tooling for that.
That’s right; if they lose the password to the keystore, they won’t be able to unlock it. We’re planning to handle various loss/recovery scenarios with an app called DeepKey – basically decentralised PKI. What it might look like for a couples-based app is:
you and your partner give each other the authority to approve a new key to represent you
when you lose your key you…
generate a new one
get your partner to sign off on it, thus recognising it as a replacement for your old one
recover your old ledger from a backup and write a new ID entry to it
There’s plenty of room for app developers to create good UX around this process, and I think there are plans on our end to create some basic UX patterns as API calls that can be targeted by the UI.
The keystore will also generate a recovery seed that can be turned into a 24-word mnemonic, but I’ve heard that everyday users find that to be terrible UX.
As for password strength, I’m not sure. The private key pair is generated from cryptographically strong entropy (from a RNG); the password is just used as entropy for generating a symmetric encryption key for the at-rest private key data. So it should be difficult-to-impossible to forge private keys using a weak password.
At least I think that’s how it works
One interesting idea that I’ve been chewing on is to have your business be one of the authorities who can sign off on a new public key – with some development of the idea, this might allow you to emulate centralised password reset UX without compromising the Cryptographic Autonomy License.
That’s a fun question, cuz IMO it’s one of the most compelling advantages of agent-centric peer-to-peer stuff like Holochain. Once you get past all the weird stuff, you discover that it’s got a lot of parallels with the real world. Each individual is their own entity, and they talk with each other and give each other permission to access their stuff. That’s it. The software simply mirrors this pattern, with devices acting as agents for the individuals who own them.
How you implement this depends on which of the three privacy models you choose. In the first model, everyone belongs to one shared space, and couples grant each other and accountants permission to make RPC calls to their running app instance by handing them a capability token. For partners, this would look like “the bearer of this token, identified by public key XXX, can call any of my functions and ask for any of my data.” For accountants, this might look like “the bearer of this token, identified by public key YYY, can call the get_statement function” (and the grantor can always delete the grant from their own ledger to cancel those privileges).
In the second model, where couples own their own mini-network, it’d look similar. But the couple wouldn’t invite the accountant into the mini-network; they’d all belong to one big network where no data is stored. The accountant calls the individual’s get_statement function, along with capability token, and the individual’s ‘public’ half of the app forwards that call to the ‘private’ half of their app, if that makes sense.
In the third model, I suppose the couples could give the encryption key to the accountant, but that’d give them forever access. It could be argued that, once the accountant has the data, they could always print it out or take a screenshot or copy/paste it anyway, so maybe that’s not a problem. You’d probably want to rotate the key regularly though, so the accountant doesn’t have access to all your future data. One advantage to this is that you could give people selective access to individual records, or a date range.
This is easiest with options 1 and 3, where everyone belongs to one network. In this scenario, enforce ‘paid up’ status in two places:
First, you sign the new member’s ‘membrane proof’ which proves they signed up for a subscription plan.
Second, you produce proof of payment every subsequent month, and subscribers write this entry to their own ledgers.
The way you enforce subscription proofs is with validation callbacks. Whenever you publish a piece of data to the DHT, the peers responsible for storing it will reject it if it doesn’t pass the validation function. The validation function could look like “a ledger entry’s timestamp must < my most recent subscription proof’s timestamp”. That doesn’t prevent read access to the app’s functions, but it could provide an opportunity for freemium choices. E.g., “I can write ledger entries on the free tier but I can only write retirement asset holdings on the paid tier”.
It’d be more tricky with the “private mini-DHT” option. I’d have to chew on that one!
As for integration, that’d happen elsewhere – probably through the UI talking to your centralised services, either via node-to-node messaging through the app’s network or through the web.
I’d say API calls out to infrastructure managed by you – you don’t want to be giving out Stripe API tokens to every single person. Again, this call could be done on the Holochain side, to your node on the app’s network, or on the UI side, to a web service that you run.
I don’t know, and it’s early days re: optimisation, but so far things are looking pretty fast. Here are some things to think about:
Each node stores their own data locally, which can be queried and iterated over (right now, the query tools are pretty basic, so that means you’d need to map/reduce/filter in memory). So for your own stuff it doesn’t require a network call. And for getting your spouse’s data in option 1 (all data is private to the individual) that’s only a single network call.
In option 2, the mini-DHT example, you’d tweak your redundancy setting so that partner store all of each other’s stuff locally. This would prevent making a network call for a query too.
In option 3, the public encrypted data example, each individual holds stranger’s data, but they only have to hold a little bit of it. It’s up to you, but maybe you want a redundancy factor of 5, so that means you only have to store ~5× what you produce if you’re an average user. Here, you would have to make multiple network calls as you traverse the graph.
There’s no reason you can’t store blobs right on a Holochain DHT, but if you’re using option 3, you probably want to chunk them and distribute them to a number of nodes so nobody’s saddled with a 2GB holiday video. FWIU there’s a group of devs working on a file-sharing app whose code could be used as a basis for this sort of thing!
The number of startups actively building is small but intense – right now there are a core of really dedicated devs who are betting on Holochain and in active development on their Holochain-based prototypes. These are the ones that come to mind:
RedGrid is connecting IoT and Holochain to build the Internet of Energy. Great feedback from them on migrating to the new version.
hummHive is a secure, radical way to create and share content.
Junto is a distributed, human-centered social media platform supported by its community.
Acorn is a virtual whiteboard for collaborative goal planning. Migration almost done, I believe.
H-Wiki gives groups the power to fully own and control their knowledge base and data. I don’t know what their status re: migration is.
Bhive is a local, digital sharing economy owned by its members.
Kizuna is a peer-to-peer messaging app that is secure and serverless.
CRISPR is an ultra simple power tool to remix, combine, and share Holochain apps.
Holo-REA is a toolkit for building open economic networks (transparent supply chains, local marketplaces, co-ops, etc). Currently migrating and finding the new SDK much more pleasant to use.
Some of these are startups, some are open-source projects, and one of them is a civic service app. What excites me about them is they seem really dedicated to sharing knowledge and code.
I’m not great at timelines; as an engineer they always felt like fortune-telling to me. As a business owner, you need some strategic foresight though. I think we might be publishing an updated roadmap soon? @dcatki can you speak to this?
When we start pumping out releases of the new version, end-user binaries will be available for Windows, though not necessarily immediately. We’ll focus first on macOS and Linux devs (Windows devs can just use WSL2 + Ubuntu), then end users. Most of the WIndows issues were with a C++ crypto lib that we’re no longer using, I think.
Beyond the ICO, we’re seeking grants. But the bulk of the long-term funding is supposed to come from the Holo hosting business, as @zdb mentioned.
@zdb thank you so much for catching this question and providing such great answers. I also like your idea of a catalogue of bank scraping recipes on Holochain
@drazzig this is a bit of a brain dump, so ASK ME ANYTHING about what I wrote here.