pull down to refresh
I assume you'll be paying for his admission to work around that, so he's your guest
Sending an invite link with attached sats has worked for some of the people I've on boarded.
But my most successful approach so far has been to ask them to post a bio (which they can do without sats) and then zap it. Then, when they want to post, they already have sats (well, more precisely, they have CCs).
I am not convinced that an SQL wallet is more reliable than Spark. Seems to me that it all comes down to the operator (in both cases), and Spark has stronger incentives to keep things running.
It's extra fragility, extra fees, an extra trust layer.
Maybe this is where we disagree: I don't see Spark as an extra trust layer compared to a custodial lightning service. Nor do I see it as extra fragility. You are probably right about fees, though.
Spark as an extra trust layer compared to a custodial lightning service
I'm talking re:
where SN began with a custodial wallet
SN already wraps invoices and takes a percentage of payments, it's still a custodial intermediary (CC's never made sense to avoid the appearance of being custodial, but I digress...)
So Spark can't get us back to the original SN state, its no different than any other custodial wallet on top of the original trust in SN.
Nor do I see it as extra fragility
There's all the inherent Lightning fragility, plus the fake L2 swap fragility on top of that, which is also where the fees come from. Again, relative to SN internalizing.
A 3rd party SQL wallet vs. fake L2 you could argue is the same on the fragility side in theory, but not in practice. Abstracting a database over Bitcoin is inherently more complex than just using a database.
CLINK might already obviate the need to send a Lightning.Pub invite directly from ShockWallet
If you run a Pub and are using CLINK with SN, SN already has your Pub's nprofile.
SN also already tracks signup referrals.
The new CLINK enroll method could be used in SN to automatically provision a new users wallet on the referring users Pub automagically.
Use Pub on SN -> Refer users to SN -> New SN user is a Pub guests of yours.
You can't get on SN without a Lightning wallet to begin with, so what is a fake L2 wallet solving?
I assume you'll be paying for his admission to work around that, so he's your guest.
Since he's not going to set up a node, he's never going to use non-custodial Lightning. An SQL wallet is fine for this, cheaper and more reliable than Spark.
So again, fake L2 solved nothing.
This couldn't be more wrong. It's extra fragility, extra fees, an extra trust layer.
And still doesn't answer for the fact you need sats to get on SN to begin with.
Since you're paying to onboard him, you're abdicating your responsibility as a host mid-journey. Like picking up up for the airport for a visit, and then dropping him off in the combat zone instead of bringing him back to catch his return flight.
The hospitable thing to do would be send him an invite link to your Lightning Pub, since that's where trust is already implicit.