I am setting up onboarding for our application deployed on DABL. I spoke with @ManishGrover earlier this week to talk about two different strategies.
The first was to send a user a dabl ledger id and have them join the ledger via the ledger explore.
The second is add a DABL onboarding flow using a propose and accept pattern between the new user and the ledger operator. This is where I’d ultimately like to get to but would like to try the first strategy for now.
Let’s say I invited fake@gmail.com to my ledger. They create a DABL account. They use ledger explorer, enter the ledger ID that I provided.
When they enter the Live Data tab, as expected they cannot see anything because “There is no data for this party on this ledger… yet”.
If I login from my console, their party ‘fake@gmail.com’ doesn’t appear. And when I try to add them, the DABL console won’t let me add their email as a party becuase it has special characters.
However, my email by default has a party created called jamesj@optimisinc.co and so does theirs.
So my question is, is it possible as the ledger operator, to send fake@gmail.com a role invitation contract from the DABL console?
Unfortunately there is a bit of a Catch 22 here; without knowing the party literal, there isn’t a way to send an invitation to them. Because DABL creates a different Party for the same user (in your case, fake@gmail.,com), knowing their e-mail isn’t enough.
The propose/accept pattern is really the only pattern that you can use on DABL for your workflow. And for ledger portability, this pattern is also the only way to make such a workflow work without assuming a service provider (in this case, DABL) that can somehow grant you information about parties outside of the system.
Unfortunately right now the party will only show up after they are made a Party to a contract, but we do have an upcoming item on the roadmap to ensure that parties are discoverable via the HTTP JSON API (see the docs on the /v1/parties API). Publishing information about parties at creation time instead of first-use time would help make your use case work better, but at the expense of relying on both DABL and the user providing you their legitimate e-mail address.
If I understand correctly, that means we can’t assign fake@gmail.com a party on this ledger using Ledger Explorer without becoming too dependent on DABL. Is that correct?
We definitely want to maintain portability. As we all know, that’s an important feature for DAML.
The “public party” on DABL is considered a well-known identifier, and on any Daml ledger you, as the application author, can choose to make your own special/operator parties well-known through your application. This allows new users to notify those well-known parties of their presence.
The workflow is basically:
Make your operator or public party well-known. You could think of this like publishing your address or website for the world to see.
Users name your party on contracts they create; extending the analogy, this is them going to your website, and creating an account. They know your party because you can easily provide this information to them (and on DABL, we expose this information for you as documented here). This is the step that cannot work in reverse on an arbitrary Daml system (or indeed, any distributed ledger).
By virtue of them creating a contract and naming your party as an observer, you can now know of their existence, and your multiparty workflow can begin.
Thanks for breaking this down. This makes a lot more sense to me now regarding why each piece is needed.
Currently in our model, we have a party named the operator. On DABL, would you suggest that the operator actually be the UserAdmin party? Or should the UserAdmin be used only to accept new users, to the ledger and the operator a separate party to initiate the workflow (send role invitations to onboarded users, etc.)?
Separating out operator parties can make sense for some workflows; you could think of this in a similar sense as to why you might use separate database users for different applications on the same shared database. Having different operator parties serve different roles makes sense, though it can add complexities to your model so there is a tradeoff to consider.