Update playground to support easier creation of BTCR testnet DIDs

Was reading up on the latest medium post for BTCR and was curious about this bullet point:

• Update playground to support easier creation of BTCR testnet DIDs (e.g. a hosted service backed with faucet funds)

What would this entail? My initial thoughts were that it would be on the /create page or another similar page but instead of inputing the funding/output address and WIF, it would hit an API that had a funded bitcoin testnet address that creates DIDs for others based on their Continuation DID Link.

Not sure how that might affect a user's ability to prove ownership or update their generated DID but the benefit would be for someone to create a fully formed BTCR DID for education/development purposes.

@kimdhamilton and/or others, was that the idea or was there another thought for the hosted service?

[hawkmauk]

I suppose the simplest way to do it would be to click a button and then automate everything to return an address, public/private key pair and DID. In the backend there would need to be a wallet with testnet coins that could be automated to send a transaction to the generated address

[hawkmauk]

The biggest issue that I see with this is being able to avoid long waits during the process:

• fund wallet, wait for confirmations
• create transaction with op_return, wait for confirmations.

This could take a couple of days which could be seen as prohibitive. It would be great to have a faucet that we could call with an address and op_return data but this doesn't really exist at the moment so it would have to be built and hosted somewhere - another little project!

How about the following:

1. User creates/opens wallet in wallet tab of playground
2. User clicks New>DID Menu
3. User fills in optional OP_RETURN data
4. User clicks Create button
   1. Creates request to new shiny BTCR faucet with OP_RETURN data

[hawkmauk]

Just been reading up on the spec again and think I have this wrong.

Am I right in thinking the DID authentication pubkey is that which is revealed in the spending transaction of the DID?

If so the faucet could generate the DID but the user can't authenticate it until they create a continuation DID.