I have been learning about how DWN would operate on different platforms, and on talking with @moe realising that it may be instructive to think of the most constrained platform as a thought experiment to see what can be done to make a reasonable user experience for apps that use DWN.
Currently that platform seems to be iOS (Android I am sure has some restrictions, but usually more freedom but a lot of this may apply there as well).
The most obvious constraint is the DWN being highly available, but there are ways to address that. The less obvious one that @moe was talking about is how any kind of user experience works with a wallet containing the private key. There are limitations that basically make inter-app communication not practical on ios (as is my understanding anyway), which in the degenerate case means each app has its own DWN and wallet etc - obviously not ideal.
Some thoughts on this:
1password and other similar apps work via share-sheet type integrations offering their “secrets” and services as needed by 3rd party apps. This is not quite the same as a wallet as (at least in case of 1password) its more like a fancy automatic copy and paste, but it is an interesting idea to have a DWN/Wallet type app that is supporting DWeb apps.
There is the Passkey system which certainly helps with the signing of things, but its downside is that each interaction requires user approval (rightly so).
For payment and “coarse” type transactions on the DWeb, this is probably ok, but say if one was building a chat app - then this wouldn’t be ideal.
Just thought I would open some discussion here (I think @moe was going to try some experiements).
Some links relevant to the above:
There are limitations that basically make inter-app communication not practical on ios
ELI5 request - What use-cases are hindered as a result of this? How does this impact a user?
great question @nburgess . so the type of user-experience we’re looking to avoid looks something like this.
Let’s assume we have a messaging app, Dignal (aka decentralized signal. horrible name btw). Each message is signed using a key associated to the sender’s DID. that key is stored in your DWeb Wallet (aka Identity Wallet) which is a separate app.
So, every time you type up a message and press send (step 1), it’d automatically switch to your DWeb Wallet App and prompt you to sign the message you want to send (step 2). After pressing the yes icon, you’d have to manually switch back to Dignal and the message would be sent (step 3)
If that was the “Dignal” user experience, i’d personally say “welp. maybe centralization is not so bad after all”
I think the primary question ends up boiling down to: What facilities / mechanisms do we have available to us to improve the UX of using the private keys associated to a DID across multiple apps?
There’s 2-3 approaches @csuwildcat and I have talked about in passing that i’m going to set some time aside to write up and post here.
separately, we have the question of “well, where are these messages actually getting stored?”
- Locally on my phone within Dignal?
- Locally on my phone within my DWeb Wallet?
- On my highly available cloud DWN?
- Some combination of the above 3 options?
@moe I think this mobile limitation kind of requires the use of application-specific keys that roll up to a single DID document. So you’d do the ‘connect my ID wallet’ step once, which …
- generate a new in new app, send pub key info to wallet
- wallet stores and updates the pub key in your DID Doc
- wallet acks to new app that it’s ready to go!
The key-role can be user-defined to limit the scope of compromise. For example, a delegate key created/used in any new app should not be able to remove other keys in your DID Document. It should purely exist in a delegate context. You should also be able to, in an OAuth 2.0-like manner, revoke delegate keys from your ID wallet at any time.
Distinguishing between “cloud” and “edge” DWNs. The distinction being a “cloud” DWN is always publicly routable on the internet and has different availability guarantees. Useful for reliable message relay / push notifications.
Edge DWNs would be closer to what I imagine run on-device. Really they exist to communicate with an edge (or edges) to push/pull data and receive messages/notifications.
For key architecture between DWNs I imagine a similar design to what I described above. Where you have one (or multiple…) DIDs with a set of delegate keys for each DWN authorized in a certain chain. It would need to be requirements based. For example, each ‘wallet’ I have I’d want to be able to prove control over a set of credentials. Maybe there’s a DID for that. Likely another DID I have just for my DWNs and data access.
My view conceptually aligns with @decentralgabe’s.
An app would have its own key cryptographically linked to or approved by the user’s DID. Multiple possible approaches here: publish app key to user’s DID Document as @decentralgabe mentioned, or a Permission Grant could be issued to an app key/DID.
each app has its own DWN and wallet etc - obviously not ideal.
Agreeing that it is probably desirable for end users to minimize the number of wallets, on the other hand it is conceivable that each app runs a DWN instance that only stores user data in that particular app domain/protocol, whatever protocol the app is granted to read/write by a permission grant.
good discussion - and obviously the terminology around edge vs cloud DWN will firm up over time.
A peripheral question for you all, but still related to mobile: for a minimal user experience for the hypothetical “Dignal”: do I as a mobile user need to source a cloud DWN for it to work?
(I remember Moe telling me the woe of running IPFS on mobile battery wise as is connects and discovers many endpoints) wondering how to avoid that for DWN design.
Agree with @decentralgabe
ION has the ability to store many signing keys that can be revoked by your update key in your main wallet.
Farcaster specifically thought through this problem @moe and that’s why you create a key on the app. Can’t be sent to another app for signing each method.
csuwildcat will say that you can’t create N number of signing keys in a DID document! Not sure if henrytsai has figured out what the upper bound of pub keys in a DID doc is. I don’t know what the trade offs are. But it’s trivial to batch did doc updates and seems like the right use of ION.
do I as a mobile user need to source a cloud DWN for it to work?
@mic, I’d imagine so, unless the mobile DWN has a persistent and reliable connections (extremely unlikely) or Dignal implementor provides its own infra for temporarily store the messages and relays those message to the users, this seems unorthodox to me in the spirit of decentralization.
you can’t create N number of signing keys in a DID document
@erickuhn19, you are right that no one can stop you from keep adding keys to an ION DID through series of updates, but it’s arguably slow, expensive and unnecessary. So this is not a technical limitation but more of a principle: if we can design a system that minimizes the need to updates to the DID Document (through the use of a DWN), then we should try.
@henrytsai Need to break down each one of your points to think it through to see the tradeoffs.
Slow: If I create a new pub key in Dignal for my ION DID, then there would be about an hour of lag time before I could start sending/receiving messages? Or is there some other work around with a long form DID?
Slow #2: Are you referring to slowing down ION if the DID documents get to be of a certain length? Would need to understand this more.
Expensive: I should be able to submit an update to many different services that are paying the bitcoin tx fees since it’s trivial and can batch 10k updates per transaction. I don’t think its that expensive.
Unnecessary: This one is subjective and not sure how to evaluate it.
The part that worries me about removing the pub keys from ION, you make DWN a requirement for the use of ION, which actually seems unnecessary. The DID Document exists precisely to let participants in the system know what public key to trust. Changing that dynamic for some custom scheme looking up pub keys in DWN’s adds to the complexity of the entire system.
one thought on mobile: as I understand it ion builds on IPFS, which seems somewhat difficult on mobile (without some companion backend) for the simple fact that multiple connections are maintained which is usually expensive.
@henrytsai yeah I could imagine an implementer providing their own, but also ideally we can make it as easy as possible to stand up DWNs on various platforms that are reasonably-available to help bootstrap things (I think).