I tried using SSE and found it didn't work for my use case, it was broken on mobile. When users switched from the browser to an app and back, the SSE connection was broken and they wouldn't receive state updates. Was easier to do long polling
Soz for the late reply. I think you kind of answered your own question. It's not can't, it's won't as you are willing to add tipping but not a paywall to your content :D
So for context, we built a lightning paywall(now defunct). All you had to do was add a single line of js to your site, as easy as Google analytics/ads. The cost was 0.01% of transaction. You could even move to self hosting and not pay us. Finally, we even built an "auto payer" so users could approve a site and auto pay a few cents with limits. Anyways, our experience is content publishers said they wanted to monetize their content but when it came down to it, were extremely reluctant to add a paywall and would maybe think of adding tipping.
Anyways I think our solution was great but no product market fit. I was especially proud how private the whole thing was but users didn't seem to really value that
I think another problem with micropayments is competing with free is hard. Say you have the best lightning paywall with an amazing UX where it's super easy and automatic to pay a creator a few sats. Most people assume the problem is user's don't want to pay but it's actually publishers who won't put up micropayments on their content. Here's why: for a big publisher, adding a lightning paywall is a big risk which may lose them their audience. For small publisher's, they don't care if 10 people send 10 sats, all they care about is becoming a big publisher
True although I'm not talking about Ethereum smart contracts, I'm talking about Bitcoin ones which are very limited and not Turing complete. The lightning smart contract is like 20 lines and has been live since 2018, I feel the probability of the contract getting hacked is very low(famous last words!) https://github.com/lightning/bolts/blob/master/03-transactio...
If bankB is hacked, bankA still gets their money back or the payment is sent to bankC. So I still think the counterparty risk is eliminated between bankA and bankB
I realise that this might seem a bit niche but we can use this to create a payment network(like visa). This system is better as the nodes in the network don't need to trust each other.
Cast your mind back to 2008 and hopefully this means that one bank falling over doesn't bring down the whole system.
USD doesn't have smart contract abilities so yes you are correct about trusting a third party to exchange crypto to USD. You could use a stablecoin but that requires you to trust the stable coin backing.
bankC creates a secret number, hashes it and sends it to bankA. bankA sends money to bankB locked to hash. bankB can't get money until they have that secret number. bankB sends money to bankC locked to hash. bankC reveals secret number to bankB to unlock that money. bankB does the same with bankA.
Tada, we eliminated the risk of bankB running away with money. This is the lightning network
Correspondent banking. So say a bank in the States needs to send money to one in Spain. They may not have a relationship, so they go through an intermediary bank.
You can use a smart contract to eliminate the trust in the intermediary bank, so eliminating that counter party risk