Live data from Hacker News

Web by Google (TM)

landshark.io

471–480 of 496 posts

Re: Web by Google (TM)

#471
post #84

The problem is that, IMO, centralization of the internet is simply the natural course. Especially when people seem to care so little. Centralization is cheaper, easier to monetize, easier to control, easier to update and upgrade. That's why people prefer Discord to IRC, that's why people prefer Slack to SMTP or Jabber, that's why for many people these days the distinction between git and GitHub is blurry. I suspect t…

> people prefer Discord to IRC ... prefer Slack to SMTP or Jabber "Centralization wins" is the wrong conclusion from this dataset. Discord & Slack have seen far more investment in UX & backend than IRC & Jabber. Because chat is addictive, relatively easy to implement, and easy for users to access via website or app, there's huge incentive roll your own chat service, and then incentive to differentiate from innumerabl…

> email is going strong

Except most emails end up at Gmail SMTP servers (@gmail.com and hosted G Suite).

Re: Web by Google (TM)

#472
A bit late to the party here but Google's monopolistic tendencies are only increasing. When you login to any Google service, Chrome automatically recognises your login and keeps you logged in. The only way to disable this is in advanced settings. These kinds of practices should not be allowed.

We need anti-monopoly action to avoid complete dominance by these tech companies. Google services need to be split up and run independently.

Re: Web by Google (TM)

#473
post #290

Earlier quoted context omitted.

I still expect them to make a more coherent case, I still don't know what native means here, still don't know why existing solutions are different from what native means. It is not stated as a counterfactual either, it is stated as direct criticism, e.g. > The Web’s orignal architects were off base on hyperlinks; it turns out people just want to skip right to the answer they’re looking for. Who are the original archi…

Author here. The article is making a case that Google has in fact captured the Web, and secondarily that there are some clear reasons for it. I had no intention of writing a dissertation on the history of the Internet. Also, filling in the missing technical gaps would be several RFCs. As for what would native payments look like: 1. I put the element $1.00 in my HTML 2. User clicks on Pay Me button in any browser and…

> 1. I put the element $1.00 in my HTML 2. User clicks on Pay Me button in any browser and I get $1.00

And then what? If all that is needed is a tag support then why is the problem not yet solved? I mean if it is so simple to add support in HTML, why not just add it outside HTML?

I'm not asking for the actual final RFCs, but just some idea of what everyone except you is missing which makes this an easy problem to solve for you. Just broad strokes will be awesome. At the moment all you are saying is that the architects did not know what they were doing, but can't explain what they missed.

Re: Web by Google (TM)

#474
post #82

This is depressing, we as developers have to take the bull by its horns. Simply stop using their services, advocate against AMP etc. But in the end, the US government will most likely have to split the company in order for stuff to really change.

I'm posting this from Firefox Mobile. Works just fine for my day-to-day surfing. DuckDuckGo is my default search engine, and it's not perfect or a panacea, but it works well enough (and there's "!g" for when it doesn't). What we really need to do is be willing to pay for our tools, though. Wikipedia estimates there are 21 million developers in the world, so if one out of twenty developers donated $1 / month to Mozill…

Well except that donating to Mozilla, is donating to a bunch of diversity projects and people, not to the browser or tech.

I would gladly donate to mozilla the day I knew my money didn't go to Bakers already filled pockets or to some worthless diversity cause like a "queer feminist filmmaker" that is obviously on their payroll.

Mozilla as an org takes in a lot of money already, it is just that they seem to spend it on nothing of value for the most part. It's sad, but it's the reality.

Re: Web by Google (TM)

#475
post #361
post #299

Earlier quoted context omitted.

> That's a very interesting observation. Google will thus prevent a native payment option at all costs, which leaves a huge opening for Brave or another payment provider. Can you elaborate on what a native payment option would entail? How would it be different from non native payment options? How would it be different from crypto or other payment options that already exist?

Like barrenko said in another comment [1]: >Wasn't it that the creators of Netscape wanted to put some kind of payment protocol similar to crypto in the original browser but ran into trouble with the government, can't remember anymore. 402 error was famously reserved for money trouble. You could have one standard, in the same way that webpages are standardized. Then you could use your preferred option on any webpage.…

> Wasn't it that the creators of

I don't know? Was it?

> With a standard, those fights would be over and users could start paying for everything.

What prevents anyone from making a standard? Why do we see standards for everything else but this? What would the standard entail?

I think the real issue here is that payment is a hard problem, open payment systems like bitcoin is horrible to use, and closed payment systems like visa is closed due to trust and security concerns.

To me it seems like the author is just dismissing the inherent complexity and accusing the people who put in the time to standardize the protocols we have of being incompetent. This is not worthy of hackernews.

Re: Web by Google (TM)

#476
post #396
post #361

Earlier quoted context omitted.

Like barrenko said in another comment [1]: >Wasn't it that the creators of Netscape wanted to put some kind of payment protocol similar to crypto in the original browser but ran into trouble with the government, can't remember anymore. 402 error was famously reserved for money trouble. You could have one standard, in the same way that webpages are standardized. Then you could use your preferred option on any webpage.…

I always thought a sensible approach would have been a sort of "payment tag" that browsers could render directly. Something like 30.00 USD 123456 https://secure.gateway.com" merchantid="123456" /> This would render as a group of buttons representing the payment choices. The browser would pop up an appropriate form-- potentially in an isolated context where the fields can't be sniffed by on-page scripts, perform the r…

> There is the Web Payments API now, but it's a clunky ball of JavaScript with limited support. This could have been demoed in 1997 and universal by 2000.

If it is so simple, why was it not? Are you suggesting it was purely incompetence of the people who standardized the web back then?

Re: Web by Google (TM)

#477
post #84

The problem is that, IMO, centralization of the internet is simply the natural course. Especially when people seem to care so little. Centralization is cheaper, easier to monetize, easier to control, easier to update and upgrade. That's why people prefer Discord to IRC, that's why people prefer Slack to SMTP or Jabber, that's why for many people these days the distinction between git and GitHub is blurry. I suspect t…

> people prefer Discord to IRC ... prefer Slack to SMTP or Jabber "Centralization wins" is the wrong conclusion from this dataset. Discord & Slack have seen far more investment in UX & backend than IRC & Jabber. Because chat is addictive, relatively easy to implement, and easy for users to access via website or app, there's huge incentive roll your own chat service, and then incentive to differentiate from innumerabl…

>"Centralization wins" is the wrong conclusion from this dataset. Discord & Slack have seen far more investment in UX & backend than IRC & Jabber.

I'd still argue that it correlates with centralization. We could argue about causation but it still goes hand in hand IMO.

A company is much less likely to invest resources into improving IRC or Jabber because if you made huge breaking changes you'd end up with an incompatible, custom fork of the protocol (negating the benefit of using a standard protocol, since you'd effectively lose the interop with third party client) and even if you kept the standards open and federation possible you're basically hurting your own business since you make it easy for people to use your work without giving you a way to monetize it.

If your objective is to be profitable it makes a lot more sense to just create your own centralized, proprietary protocol and clients that you control end-to-end. Standardizing and federating your protocol is a massive amount of headache in the long run for very little benefit in terms of $$$.

Re: Web by Google (TM)

#478

Earlier quoted context omitted.

As for SMTP, most people use Gmail nowadays anyway. Google might be able to kill SMTP if they wanted to.

Google will not be able to kill smtp, gmail is only one side of the email market. They’d have to offer a transactional and marketing email service and get every app/company to use that over smtp. It’s monumental and I don’t think it will change for decades.

You can damage open/federated email without having to break the lower level layers. See winmail.dat for instance[1].

I don't know if it's still in the pipeline but I remember that Google proposed an "AMP for email" not so long ago, with basically self-updating email contents.

Open email can be severely damaged if good old SMTP is only used to tunnel proprietary formats, especially if those formats are effectively just metadata that's used to fetch the actual content of the email from 3rd parties.

[1] https://en.wikipedia.org/wiki/Transport_Neutral_Encapsulatio...

Re: Web by Google (TM)

#479
post #84

The problem is that, IMO, centralization of the internet is simply the natural course. Especially when people seem to care so little. Centralization is cheaper, easier to monetize, easier to control, easier to update and upgrade. That's why people prefer Discord to IRC, that's why people prefer Slack to SMTP or Jabber, that's why for many people these days the distinction between git and GitHub is blurry. I suspect t…

Meh, I think the longest lasting protocols are the decentralised ones, the good ones just can’t fail by design. SMTP is still going very strong, BitTorrent isn’t going away, bitcoin won’t die anytime soon slack/discord will probably disappear and be replaced by another closed system until we find the right way to do real time chat in a decentralised way.

HTML is also "going strong", that's not really the problem. The proprietary takeover happens at higher layers.

If SMTP is only used to tunnel proprietary content à la winmail.dat, it doesn't really matter that it's still technically open.

Re: Web by Google (TM)

#480

Earlier quoted context omitted.

The power to promote is just as dangerous if not more dangerous than the power to suppress because it is much harder to make a case against it but can have the exact same effect.

Promotion of any content results in the suppression of other content (inventory isn't infinite). If you were in charge of the algorithm, what would you promote? Considering half of America views CNN the same way you view Breitbart, do you consider that to be a despicable source too? It's really not as simple as you think.

How half of America views something doesn't really matter, what matters is that there is an observable factual difference between Breitbart and CNN. I don't have a dog in the race and that's pretty easy to establish. Or do you really believe that CNN also promotes conspiracy theories and outright nonsense? If so I guess the conversation is over.
Post reply on HN