jmusall
Joined 1 year ago
Joined 1 year ago
One in particular on pratical implementation of ZKPs was popular on HN back in 2024: https://zkintro.com/articles/programming-zkps-from-zero-to-h... (discussion at https://news.ycombinator.com/item?id=41398092)
I think they should spend another few billion tokens and let agents try to disprove any of those statements or links between them. Then I'd be a lot more convinced.
Yes, but there can be other benefits than monetary ones. Besides, I find it rediculous to believe that wealthy people receiving more benefits automatically translates to improvements for the general society.
To add another point: The monetary value these companies create is often only possible because of their monopolistic market distortion. I don't think it can be a net benefit for society when competitors have little to no chance to offer a better product.
> When people suggest regulation they want to control how these companies are acting
That's true. In your original comment you also said "government taking over YouTube" which is why I thought we were talking about complete transfer of control à la planned economy, which is normally not the goal of regulations.
"Regulating" also doesn't mean "taking control".
> Since we're making a new app, we're going to want two things: an app server (which hosts our API & frontend) and a view server (which collects data from the network for us).
Yes, the user data is decoupled from the apps, but aren't both stored on some kind of instances? Also:
> Why are we listening to the event stream if we're the one making the write? Because we're not the only ones making writes! There are lots of user repos generating events, and lots of apps writing to them!
Who is hosting this event stream? Aren't we making some kind of federated network by deciding on our app server which event streams or which users/apps pushing updates to listen to?
https://research.swtch.com/qart
Looks like this is definitely possible, the results aren't as clean as you might hope though. Maybe they could be improved by introducing some intentional errors (which were explicitly avoided here).
Your argument still partially applies though, as introducing new unrelated colors at the module edges could also lead to aliasing effects when the code is too small for example.