My father uses ChatGPT extensively. My friend, whos an electrician, but has 0 things to do with computers, even called it Chat once and I said who? Because for me its ChatGPT. He also uses it extensively. Although I would bet they won't be willing to pay, advertisements will eventually hit them. And with inference prices going down, with distilled models being used, OpenAI will profit, and people will still hapily use it for whatever random queries they have. Exposure is the currency and OpenAI will have infinites of it for the foreseeable future.
Worked on an ESP. We had a couple of server software we used on low-level for sending. None of them would accept the message without a Message-ID. But even if you have a super-custom, SMTP-injecting service built, how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to? Unthinkable. I would not like to have business with such a payment provider.
This is the one that gets me - sometimes you're forced to work with systems that do annoying things that you have to accommodate. It's annoying, but it's more important to do the thing that prevents your users from having issues than it is to be theoretically right about whether something's required by a standard.
I've dealt with many worse cases than this, where the systems I was integrating with were doing things that weren't even close to reasonable, but they had the market power so I sucked it up and dealt with it for the sake of my users. Maybe Google's wrong here, but how do you not just implement the solution anyway?
> Maybe Google's wrong here, but how do you not just implement the solution anyway?
But they just did (make it work). The logical assumption is that most ppl did the same, just used another email provider. Why would viva care? (same as google, why would google care?).
Well, apparently it's not even an issue for gmail users:
To unblock myself, I switched to a personal @gmail.com address for the account. Gmail's own receiving infrastructure is apparently more lenient with messages, or perhaps routes them differently. The verification email came through.
So it's only an issue for people paying for Google's hosted email—a much smaller set!
> how can you ignore all of these bounces from a provider thats likeliest to be the major one you are sending to?
This is the major issue that most of the discussion is missing. It doesn't matter how you want to interpret the word SHOULD, if you want to send to google workspace, you MUST include a message-id. It's not like this is some fly-by-night server with 12 clients.
If you absolutely and completely don't want to include the message-id, then you need to have a warning that your service can't be used by Google Workspace customers. This used to be common practice, blocking communication to servers that behaved badly, and I sort of wish we'd bring it back.
> I would not like to have business with such a payment provider.
Chances are that the decision-makers in most companies don't care about the technicalities (i.e. which email you used for registration) - they want to get up and running.
The reason that Viva doesn't care, I assume, is the reason Google workspace doesn't care: they're both too big to care for 5% of their clients won't do the extra work. They know that their, usually much smaller clients, will "figure it out" by i.e. using another setup that works™. So why bother?
Since workspaces are probably tied to custom domains all they see if only cursorly looking are "random" businesses with bounces (as TFA mentions, Gmail addresses seem to work fine), sure if you look closer you'll notice the MX might be a google one but going from the cursory look to a closer one takes a bit of time.
For now, but with EU digital sovereignty efforts in full swing, it's possible this changes over time. More so if the EU uses regulation to dissuade the use of US Big Tech products and services.
This is round 5 or 6 of a " EU digital sovereignty efforts in full swing" maybe this time they will having a success or two but nothing seems to indicate they've changed enough to avoid failing again.
... which is irrelevant to the demonstrated and shocking incompetence of being unable to deliver either to the #1 or #2 inbox for businesses in the EU?
This is the case for PHP library that is used to collect data, but i guess others either already have it or will do it soon. Don't get me wrong - i'm ok with companies adding telemetry, but adding that as an opt-in by default is just not cool.
And this might be just the last straw in us switching away from DD, with all the random price hikes (them counting hosts and RAM on them and basing pricing on it?!), we will probably look into some OpenTelemetry setup we can host ourselves.
Fwiw you can start looking at migrating to OpenTelemetry while using Otel's DD exporter to start with and then continue shifting from there. Luckily Otel's PHP implementation is relatively complete so it should be relatively straightforward.
Shameless plug: I've been working on a DD alternative, pricing based on data volume (instead of adding on by hosts or users), Otel native as well so you're never locked in. If you want to check it out: https://hyperdx.io
I think parent was referring to the telemetry being opt in (enabled) by default, whereas you're mentioning that the telemetry itself is opt out. Both referring to the same thing, just opposite verbiage funny enough.
That's a misunderstanding I think, dictionaries say (of opt-in)
- choose to participate in something.
- to choose to be part of an activity, arrangement, etc
- The property of having to choose explicitly to join or permit something; a decision having the default option being exclusion or avoidance; used particularly with regard to mailing lists and advertising.
Yeah, thats what i think too, thanks. Hoping for a miracle solution. And also i did google, and i understand that the schema will have to be provided, we can do that, but the actual data transfer is the pain point here. I tried one solution, Airbyte, locally, but its mongo support is in beta, and does not use a feature like WAL, etc.
This is just a bad hot take. It does not even propose anything that's better. Just do work and it will be there? How? I'm confused. And, i, my self, don't believe sprints are 100% the best, but for us it helps to manage load, see how much we can do, and make sure everyone is on the same page. It's not a bible, it's just another tool in the chain.
