Hacker News

Top stories

Live mirror
30 storiesupdated just nowView source snapshot
  1. Hacking OpenAI(hacktron.ai ↗)
    122comments
  2. Jemalloc 5.4.0(github.com/jemalloc ↗)
    17comments
  3. Astra for Law(openai.com ↗)
    488comments
  4. The scourge of x86 emulation(fex-emu.com ↗)
    8comments
  5. Bonsai 2 27B: Near-Lossless Compression in a 9x Smaller Footprint(prismml.com ↗)
    118comments
  6. Bend – A language that blocks AI mistakes via proof, on CPU and GPU(bend-lang.com ↗)
    205comments
  7. Qwen 3.8 Omni Flash(qwen.ai ↗)
    59comments
  8. Pre-Greek: The lost language hidden within Ancient Greek(linguisticdiscovery.com ↗)
    24comments
  9. Hister: A private search engine for the pages you visit and the files you keep(github.com/asciimoo ↗)
    158comments
  10. Wax motor(wikipedia.org ↗)
    63comments
  11. Fujitsu launches made-in-Japan next-generation CPU FUJITSU-MONAKA(global.fujitsu ↗)
    220comments
  12. Shapelearn Qwen 3.8 27B (13.1 GB VRAM)(byteshape.com ↗)
    5comments
  13. When the fractional part of a float fixes your shader(crocidb.com ↗)
    discuss
  14. How to Write with an LLM(sockpuppet.org ↗)
    81comments
  15. Telstra outage: The night a network decided the year was 2006(netnod.se ↗)
    21comments
  16. Flet 1.0 – Build cross-platform apps in Python(flet.dev ↗)
    51comments
  17. Apple detectives solved mystery of ancient tree and rewrote the history of fruit(scientificamerican.com ↗)
    4comments
  18. Ask A Monk – A digital wilderness for thoughts with no immediate answer(askamonk.online ↗)
    20comments
  19. Diplodocus, Long Thought Exclusively American, Turns Up in Spain(sci.news ↗)
    36comments
  20. The most important product decision is what you don't build(liamnugent.me ↗)
    32comments
  21. Fixing an NZXT Signal 4K30 part 2: the green/pink video bug(downtowndougbrown.com ↗)
    8comments
  22. CrowdSec Source Code Leak(crowdsec.net ↗)
    44comments
  23. Waymo in Singapore(waymo.com ↗)
    106comments
  24. How do we prevent mathemathics from devolving into the Medieval Era of secrecy?(mathoverflow.net ↗)
    94comments
  25. Why I didn’t sign the Fields medallists’ letter(gowers.wordpress.com ↗)
    353comments
  26. How Uber Protects Against Retry Storms(uber.com ↗)
    35comments
  27. Show HN: Snapdrop: Instantly share files between devices. No setup, no signup(snapdrop.me ↗)
    34comments
  28. Khipu (Quipu) Field Guide(khipufieldguide.com ↗)
    discuss
  29. Infinite-Parameter LLMs: Generating and Adapting Weights from Live Data(arxiv.org ↗)
    39comments
  30. Code Scans(devin.ai ↗)
    4comments

Brave's new YouTube donation system seems designed to misdirect user donations

1 pointsby 8y ago
0 comments
I was reading the comments on https://news.ycombinator.com/item?id=15722299 and saw a link to the Brave browser FAQ (https://brave.com/faq-payments/#unclaimed-funds), which says:

> When there is about $100.00 USD in BAT for a

> specific publisher, from all contributors, Brave

> makes three attempts to complete the publisher

> verification process. We will hold unclaimed

> funds for a minimum of 90 days, after which it

> will be added to the UGP (User Growth Pool).

They also claim that "This new ability will especially benefit YouTube creators who have under 10,000 lifetime views, as they do not receive ad revenue from YouTube". This claim of benefitting smaller creators seems very suspect.

Brave doesn't publish full user numbers, but some quick napkin math based on their 13,000 Android app reviews vs Chrome's 8,000,000 leads me to estimate < 2,000,000 users. There are 1,000,000,000 Youtube users according to https://www.youtube.com/yt/about/press/. Assuming the average channel with < 10,000 lifetime views has < 100 subscribers, and assuming a uniform distribution of Brave users over channels, the average channel only has a 20% chance of having _1_ Brave donator. Even if they have 3 people donating $10 worth of BAT per month, they won't be contacted, because they will only get $90 within the 90-day withholding window. Brave then confiscates those donations and feeds it into their "User Growth Pool".

Of course, I made a lot of assumptions / back of the envelope math here due to a lack of data (it's possible that Brave users tend to congregate towards certain kinds of channels, and therefore those channels are more likely to break the 3 donator threshold), but I think the point is reasonable.

There's a simple way to fix this: if funds are unclaimed within 90 days, they should be _returned_, not confiscated. And if one of my assumptions is wrong, then prove it: Brave should release information about what percent of user donations are being used towards the UGP instead of being claimed by creators.

A quiet thread, for now.Start the conversation on HN ↗