Hacker News new | ask | show | jobs
by DINKDINK 2531 days ago
All the ways congestion controls are implemented on the web lead to a cognitively infantilizing UX, privacy violations, and even "skynet" enabling[1] (hyperbolic but nothing stopping it from happening).

"Are you really human? What's: 3 x 9"

"Can you click on images of buses?, hmmmm don't believe you're human still, can you click images of stores, hmmm now bikes, hmmm now vehicles, oh I didn't mean all vehicles I just meant autos and not motorcycles, here quick copy this token, oh it expired? Too bad. How about you click on images of buses for me..."

"Sorry, browsers that protect your privacy and location aren't allowed. We only allow users who are willing to deanonymize themselves."

"Well we all know /those people/ who come /that place/ are antisocial users"

"Here's your IP addresses back. Oh yeah, sorry about blacklisting them"

This is a comment about the meta issue Troy faces. If costs are rubegoldberg'ed to create a facade of "free", it's not actually free (even if user data isn't being sold). e.g. A median-wage (10e3USD/year) world worker spending 20 seconds solving a captcha has an opportunity cost of 0.03USD[2]. Further more, having to solve congestion issues by implementing requirements to use closed/inaccessible (credit cards) poorly programmable, sucks too. Additionally, if a congestion solution is ("I'd rather low-demand users have free access and high-demand users have expensive access) isn't solved by having a flat rate (which a "keep it low cost, mantra is incentivized to keep low"). There is market demand for: If your demands on my service are x, I'll give you back the $3.50 but if you consume y resources You have to pay Z.

Wouldn't it be great if there was a way machines could own money, send it over a layer-2 network, that was open, cheaper than credit cards, faster than L1 bitcoin, and get your money refunded if you didn't demand excessive server resources, all while not using game-able "good users come from here" privacy violating algos?

This is why micropayment using layer-2 bitcoin on the Lightning Network has significantly-valuable, latent, economic-coordination implications. Micropayments aren't about paying for 1/1000 of a peanut. They're about obviating all the engineering, social, product costs dealt with dealing with Marginal Value, Marginal Cost issues. BAD: The marginal cost of anti-DoS counter measures can always be above the marginal value of deploying them ("listen folks it costs to much to keep this service running, we'll have to shut it down". UNSTOPPABLE: If a price is put on service requests (Services on Demand)[3] the marginal value will never be below the marginal cost ("I can keep this AED locator map service running because I know a spamming request will incur costs above my production costs").

In a future where L2 Bitcoin payment/Lightning client infrastructure is prevalent, gone will be the days of annoying, productivity-draining captchas, attribute-discriminating access. Troy could charged a 0.01USD "bond" payment for a request (Which he could give back fast and costlessly to a low-demand user). Meaning the 14e3/min requests for 3 hours would have required the high-demand user a payment of $25,000USD[4].\

0.01USD refundable payment for honest users.

$25,000 USD penalty for high-demand "spammer"

[1] https://i.redd.it/pb5nggw3rulz.jpg

[2] 20/60/60 * 5

[3] https://medium.com/@soddiraju/the-not-so-micro-potential-for...

[4] 14e3 * .01 * 60 * 3

2 comments

That would only solve paying for services if you are an amoral service provider and don't care where the money really comes from as long as you get paid.

It doesn't do anything for people who don't want their services used by bad actors, which is increasingly the case these days - see all the people concerned about privacy and how big tech companies use their data. It's not going to help for anything social where you are trying to promote pro-social usage and discourage anti-social usage, however you define it.

Those concerns inevitably lead to things like "know your customer" and supply-chain policing. You can still build nice services, but not anonymous ones.

The issues are pretty much the same as TOR. Some people are willing to run TOR nodes because the good outweighs the bad, others get squeamish about child pornography and say: no thanks.

And that's why it's an API. If the "have I been owned" database were harmless and there were no concerns about bad actors, it would be a torrent, not a service.

>It doesn't do anything for people who don't want their services used by bad actors, which is increasingly the case these days

My comment illustrates precisely how such an incentive structure denies high-resource demand users.

>That would only solve paying for services if you are an amoral service provider and don't care where the money really comes from as long as you get paid.

This makes no sense to me, sorry. Are you claiming that anyone who accepts cash payments is amoral because a euro/dollar bill could be stolen and equivalently people who accept bitcoin payments are amoral because they don't surveil their customer's financial history?

By "amoral" I don't mean immoral, I mean you don't care what anyone does and you're happy not knowing the consequences of your actions.

Depending on what you're providing, maybe that's fine. In the open source world, we give away code all the time, to everyone. Most public reading material is fine.

But services differ and for some services of interest to bad actors, many people are concerned about the consequences when they do business.

Why do something that is so complicated and time consuming to implement when charging $3.50 is good enough? Its easier for him, as he can use already made tools, and its easier for me because I don't have to add all this extra overhead (and money) to a project. It's just $3.50 and a header.
"Why would anyone put film in their camera, take a picture, have it developed, scan it, email it, all so that I can print it on a dot matrix? That's so complicated; I could just put it in a manilla envelope and send it through the postal service. Why do I need a new way to send information?"

If you want to continue using legacy technology, that's fine. If you're not comfortable with your bits being in a computer, that's fine. But it'll be slower, more expensive, and less transnational etc.

> But it'll be slower, more expensive, and less transnational etc

That's the issue with your idea though. For the current status quo all I need is a valid credit card and the ability to type "curl -H "hibp-api-key: <whatever the key is>" https://haveibeenpwned.com/api/v3/breachedaccount/test@examp...

I can have that done in less then 60 seconds, it fits his threat model, and can be done in any language with a tcp lib.

Your idea isn't bad, it just does not fit the problem.