Readit News logoReadit News
csumtin commented on Back to basics: Why we chose long-polling over websockets   inferable.ai/blog/posts/p... · Posted by u/lunarcave
CharlieDigital · a year ago
Would there be any technical benefit to this over using server sent events (SSE)?

Both are similar in that they hold the HTTP connection open and have the benefit of being simply HTTP (the big plus here). SSE (at least to me) feels like it's more suitable for some use cases where updates/results could be streamed in.

A fitting use case might be where you're monitoring all job IDs on behalf of a given client. Then you could move the job monitoring loop to the server side and continuously yield results to the client.

csumtin · a year ago
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
csumtin commented on How do I pay the publisher of a web page?   sethmlarson.dev/how-to-i-... · Posted by u/surprisetalk
knorker · a year ago
> it's actually publishers who won't put up micropayments on their content

Won't, or can't?

Do you have a good article about how to set up a paywall or tip jar for small transactions, with a clear description of what percentage goes to middlemen and (mainly in the case of proof of work) how much externality cost it incurs?

I would like to be able to pay $cents or even $dollar for instant access to an article, but only if X% actually goes to the recipient (I don't know what X is, yet), and I would lead by example on my own content. (though most likely tip jar, not paywall)

csumtin · a year ago
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

csumtin commented on How do I pay the publisher of a web page?   sethmlarson.dev/how-to-i-... · Posted by u/surprisetalk
sneak · a year ago
This is a relatively straightforward problem to solve. There is a “payment required” HTTP status code and lightning network micropayments are very easy to set up and use.

The problem is that payments that cannot be centrally surveilled and centrally vetoed (without burden of proof of probable cause, usually) are actually illegal to implement.

To do anything like this requires strong ID and KYC for payer and recipient and that isn’t what bare URLs and the web are about.

All of the cool applications of online payments that would spread quickly and efficiently are illegal.

It’s truly sad.

csumtin · a year ago
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
csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
JumpCrisscross · 3 years ago
> counterparty risk is eliminated between bankA and bankB

Correct, but in its place is a new systemic risk with a real-world nonzero probability: the contract itself getting hacked. There isn't analogy for this in modern banking since the equivalent issue would either (a) get rolled back or (b) fold into the bank failing envelope. (There is analogy in pre-modern banking, though it largely revolved around debasement and invasion.)

csumtin · 3 years ago
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...
csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
trompetenaccoun · 3 years ago
Fair but LN is not a smart contract. Bitcoin can't do smart contracts the way a chain like Ethereum does, it's functionality is very limited.
csumtin · 3 years ago
I'd argue it is a smart contract :) just not a Turing complete one
csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
JumpCrisscross · 3 years ago
> think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back

Bank failing in this context would be the bridge (EDIT: contract) gets hacked. Hence mitigated, but not eliminated.

csumtin · 3 years ago
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
csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
JumpCrisscross · 3 years ago
> we eliminated the risk of bankB running away with money

This isn't a real risk with correspondent banks. Instead, it's counterparty risk: bankB failing while it holds the funds in transfer. That risk can be mitigated with smart contracts, but it's not eliminated. (Correspondent banks also take a portion of the client bank's fraud and AML risk.)

csumtin · 3 years ago
I think the bank failing risk is eliminated, if it fails the forwarded payment is unlocked so bankA gets their money back.
csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
csumtin · 3 years ago
Explanation: bankA -> bankB -> bankC.

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

csumtin · 3 years ago
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.

csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
karpierz · 3 years ago
I'm not talking about code.

The goal of the transaction is for the Spanish bank to have access to USD. In the example given, the Spanish bank would then have to take the crypto it got and trust an exchange to give it USD in exchange for the crypto.

How do you get USD to the Spanish bank without trusting a third party?

csumtin · 3 years ago
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.
csumtin commented on Smart Contract Security Field Guide   scsfg.io/... · Posted by u/dmuhs
csumtin · 3 years ago
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

csumtin · 3 years ago
Explanation: bankA -> bankB -> bankC.

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

u/csumtin

KarmaCake day11December 12, 2022View Original