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:
Requirements:
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.
Hi @pauldaoust - I’ve been coming back to this post regularly for the past few months, just want to acknowledge that this was super helpful and a lot to digest even if I was silent! I’ve been following the YouTube video channel too and watching developer updates, I have to say some of the abstractions are a little hard to get my head around, and it feels like the framework is moving very fast so hard to keep up with it right now too. However I see a lot of potential on this project and really hope it can work for our needs. We’ve been building the app as an Electron/desktop app in the mean time, as I’m assuming the UI/UX will be the same regardless of the P2P framework behind it, so we’re still some way from having to make a call on this.
One thing I saw in a recent video mentioned by your team is you’re apparently working on SQLite integration? What does that exactly mean? Our app is using SQLite for the “desktop only” MVP, and we like the SQL capabilities to be able to quickly build reports and edit transactions - will Holochain be providing some way for an agent to have its own SQLite to store and sync data on the network between agents and we can use SQL to query instead of the graph database?
With regards to above:
I kind of like the Data Hidden in Plain sight approach because of its resiliency, having data dependent on (most likely) 1 or 2 devices in a private group for a couple sounds like a lot of user issues over time. I think if the encryption is strong, ideally quantum-computing proof in case in future one of those computers come along, and they don’t directly manage their private keys (perhaps using the Deepkey solution you mentioned) then the risk is someone gets their password and can see all their data, but then how is that different from someone getting their password on a Cloud service and seeing all their data? Do you think Holochain could support MFA for extra security on login too? I like the idea of cycling keys too over time to protect future data if someone gets their keys at a point in time too.
Deepkey sounds a lot like multi-sig wallets, where you can nominate another user to reset your keys if you lose them. I really like that model, so would be on board with that approach, with our company potentially being another trusted authority to help users reset their password and recover their account.
I’ve been thinking about payment subscriptions, and I think there will be a free version that provides the core accounts/transactions of the app, and paid features for investments. With a P2P app, it feels like the bigger we can make the network, the stronger/more resilient it is, so getting as many users as possible onto a free version makes sense, and as a developer the cost of adding new users vs. a Cloud solution would be low to 0 as we’re not hosing the data/APIs (other than the bank sync APIs which unfortunately need to be centralised via Plaid for now)
Finally, how is Windows support looking? That’s going to be a key one for us!
Sounds great – the most important part will always be your core offering and how well you deliver that with good UX. That’s something you can iterate on before you marry yourself to this or that stack.
I think you’re pretty correct about the UX being similar regardless of the P2P stack you choose; they all revolve around self-created identities and peer-replicated data streams, really. I think there will be subtle differences, especially with group membership / replication models – Holochain works on the idea of ‘discrete groups, each with their own shared data store and criteria for membership’, while Secure Scuttlebutt is more like ‘indistinct group boundaries, friend-to-friend replication’ and Hypercore is ‘I replicate the feeds of the people I’m interested in’.
This really just shows up at the low level; we’re finding our current key/value store (LMDB) to be great for fast key-based lookups but slow for querying (and impossible to create indexes with). That has an impact on Holochain’s ability to efficiently gossip data around the DHT in ways I honestly don’t understand. The switch to SQLite may have benefits down the road re: ad-hoc querying of local or shared data, but I wouldn’t necessarily count on it; no to-do list items have been sketched out in that regard. You’d still want to look at ways to create filtering/grouping indexes using the graph database features of Holochain’s DHT. I’m really hoping we can create some drop-in libraries that give this to you for free, abstracting away the graphy nature of the underlying data.
Yeah, a private network for a couple is great for security; not so great for resilience and availability. My big concern here is that you wouldn’t be able to build queryable indexes on the DHT when everything is encrypted. Maybe the best choice would be to use Holochain as a replication engine only for local SQLite instances. Then you have the benefit of SQLite’s querying and the benefit of Holochain’s serverless redundancy:
sequenceDiagram
participant Alice app
participant Alice Holochain
participant DHT
participant Bob Holochain
participant Bob app
Alice app->>Alice Holochain: newTransaction($142.53 grocery store)
Alice Holochain->>DHT: (encrypted transaction 5)
Bob app->>Bob Holochain: sync()
Bob Holochain->>DHT: Any new data from Alice?
DHT->>Bob Holochain: (encrypted transaction 5)
Bob Holochain->>Bob app: newTransaction($142.53 grocery store)
Bob app->>Bob app: query(grocery store), display up-to-date result set
here I collapse both UI and local SQLite database into ‘app’. Hope this sequence diagram makes sense; the important thing to note is that each source chain entry is actually an action – an action to create/update/delete a transaction, account, etc. So the source chain is just a record of state changes, not a table that you can query.
In order for this to work in a peer-to-peer system where there isn’t a ‘master’ database, the actions have to ‘commute’; that is, if Bob and Alice both work independently and then apply each other’s most recent actions to their own database, there needs to be some way of preventing conflicts. The simplest strategy is “just accumulate records, never delete or edit” – which works out well for accounting, where you’re never supposed to delete/edit stuff anyway. And an account balance is just all the transaction amounts added together – and addition is commutative.
When you want to offer modifying/deleting transactions and accounts as a feature, which some accounting apps do, it gets a bit trickier. For example, if Alice and Bob are both synced up, then Alice deletes a transaction on her device and Bob updates it, who wins? The delete or the update? Maybe you always favour deletes; maybe you always favour the one with the earlier timestamp (and hope that Alice and Bob’s system clocks are close to each other). Maybe your UI offers manual conflict resolution. It’s all about offering the best UX for the humans who use your app.
There’s a body of research into conflict-free replicated data types (CRDTs), which are meant for your use case – two people updating independent copies of a shared database and syncing up with each other. You’ll probably want to look into CmRDTs, because (a) they’re simpler to understand and implement, and (b) while they have a challenge (“The communications infrastructure must therefore ensure that all operations on a replica are delivered to the other replicas, without duplication, but in any order”) Holochain takes care of that challenge for you.
I’m sorry; I realise this is probably a lot of new stuff to chew on. The reason I’m dumping all this information on you is that I feel really passionate about projects like yours: everyday apps that leverage the advantages of the cloud while liberating us from the vulnerability that comes from relying on centralised infrastructure.
One note about identity: while it’s true that people don’t directly manage their keys in a UX sense, those keys are under their direct control because they live on their devices. DeepKey allows Bob to designate Alice as an authority to recognise his attempts to create new keys (either for new devices or because he lost an old device key) – and hopefully the complexities of this will be hidden behind a nice UX.
There is a password, however, and it’s the seed for a decryption key that unlocks the keystore file that contains all your keys. So in that sense you’ve already got sort of a multifactor authentication – something you know (password) and something you have (keystore file). I’m trying to think of where MFA could fit in – maybe the keystore app could support (T)OTP codes, which would offer that protection to all Holochain apps, though it wouldn’t protect you if someone stole your keystore file and tried brute-forcing the password. (There are other protections for that that we’ll implement, like a key derivation function that slows down brute-forcing.)
Maybe you could do MFA at the UI level. I could see that being useful for a couple things:
If Alice has Bob’s OTP seed and vice versa, Alice’s copy of the app could use them to ensure that Bob really was the one who made those last twenty edits.
At the Holochain level, each attempt to sync or write could be accompanied by an OTP challenge, although that could get tedious for the user.
The app could check the OTP code before decrypting the encrypted local SQLite database.
Yes, I love that idea. It offers the convenience of password recovery while still letting users retain control over their own keys.
Sounds like a good business model – when your marginal cost of customer acquisition is 0, why not scale as much as you can? (well, I guess there’s customer support technicians to think about too)
That one’s on pause right now, because we’re doubling down on all the blockers for getting Holochain working with the Holo hosting network. But we’re not dropping it as a must-have; don’t worry!
Hi Paul - once again want to acknowledge and thankyou for the very detailed response! The diagram makes sense (especially as a visual person) so really appreciate it - the concept was also something we were thinking about as well, just using a P2P framework to sync data vs. looking up data, and use the local SQLite DB for the actual storage & query. Appreciate the additional links to CRDTs as that is also something we’ve been talking about too for this area.
Thanks for the other ideas on MFA and providing some update on windows support too! I will continue to follow and keep thinking about this and follow up on this thread if anything else comes up during our investigations!
