Custody or Non-Custody?

"Choose one", they'll say. If you start building on lightning, you'll have a material number of architecture choices which will materially impact any business model -- and probably regulation in the future. One of the biggest sets of choices is how to approach user's funds.

Right now, with lightning, if you want to do anything with the data associated with the payments (Eg. use them as likes or equivalent), you have to control user funds on one side of the transaction. And, unfortunately, if you don't take custody of funds, your app will likely convert slower for pre-coiners.

BOLT.FUN and ForkableRecipe.com and Stacker.News all have this same conundrum.

The purists will say, "that's the point". You don't get the user's data. The counter argument is that without that data, the business model gets harder or completely invalidated. In my opinion, there are ethical and unethical uses of data. That balance should form a set of explicit opt-in choices owned by the app and the user. It should be a choice. Aggregated data for curation, is one example where I think using the data-usage is acceptable, or even encouraged. Bitcoiners seem to embrace Stacker.News so there are many who see it the same way I do.

Some others might say "Bitcoin is an IQ test", with respect to worrying about the pre-coiners. Right now, there isn't enough lightning users for many viable business models to function. Not worrying about the user journey for a pre-coiner means playing on hard-mode and delaying global adoption of Bitcoin.

Why not both?

What if instead of choosing one or the other, we kick-off a phase where applications direct the pre-coiners, and use the data, to help bootstrap both the application and adoption?

The idea is simple. If you sign up for the app, you can only receive sats. But you can't withdraw them until you provide a self-custody way to receive them. This also implies depositing would be unecessary. Quite a few problems are solved with this hack.

1. The pre-coiner user journey is improved materially. They don't need a wallet or node to start using your app right away. They can upgrade later, after they learn more.

2. The app can use the data associated with new user flow (this is usually where the application-improving data-lives anyway Eg. "what does the user struggle with?")

3. The app can get access to enough data surrounding payments such that it can make assumptions for curation and likes.

What does this look like?

On forkablerecipe.com the pre-coiners receive sats to [email protected] or [email protected], immediately upon signing up. Zero-Knowledge required and maximum conversion rate. They can see their balance climb, as soon as somebody tips them or their recipe. The UI puts those addresses in the places where it makes sense, or the user can put those in social media profiles around the web. But then, when they want their sats, the app should force options which reduce the custody liability for the app and direct the user to learn. Force the user to give withdrawal instructions that are push-like in nature. Right now, that would either be a lightning address or an on-chain address. The user has to learn how to take custody themselves, in order to withdraw any sats AND then the app will auto-forward sats to those destination at a convenient interval for the app (Eg. hourly, daily or weekly). That is, don't set up/build withdrawals on user-command, but make the app do it automatically once the user sets up the instructions for claiming their sats. Then, don't let the user disable that option, unless they replace it with another option to push sats to.

Still Early

Admittedly, the above thinking is early. Maybe there are flaws or weaknesses I haven't thought about. IMHO, there are draw-backs to both custody, non-custody, and permutations in between. Choosing one feels like a gamble, because there isn't an obvious answer.

Feedback welcome, and encouraged.

Next Steps

This discussion prompts two possible future protocol enhancements I'll leave for consideration of the the community.

1. Atomic Lightning Address Payment Forwarding - It should work with 1 fee, and 1 transaction. ie, sending money to [email protected] but the invoice is generated by [email protected] This could also be used as a privacy preserving enhancement. To do this effectively, this may need improvements to the lightning protocol itself. Not really sure. Maybe it could be done strictly as part of the lightning address and surrounding specs.

2. Node Data-Sharing Callback - Upon receipt of payment, if I, a user or controller of funds, want to share the data associated with my transaction going through (or even failing), I should be able to register a call-back to some other server, maybe from something like LNBits or even my lightning node to notify a third-party service about the transaction. This call-back would require a standard, along with trust to start. Maybe in time we figure out a way to do it without trust somehow with cryptography given the lightning protocol.