pull down to refresh
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.
reply
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.
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.