elithrar

IPs as identifiers aren’t great: in a world of both CGNAT (more shared IPs) and a ton of sketchy residential proxies, they’ve become poor proxies for identity of a “thing”.

There's ~four of us trying to reproduce this right now, using Astro and Remix, and cannot at all.

An important note: React-based frameworks tend to use camelCase attributes vs. hyphen-case (which is the output) in components: including the icon library being used here. Something during the build process is not converting them to hyphen-case.

* I've pasted a decently complex SVG exported from Figma into a Remix component verbatim (hyphen-attributes) and it renders fine: https://9b14a265.test-broken-svgs-remix.pages.dev/ (scroll down)

* I've rewritten those attributes to camelCase: and again, renders fine - https://1af766a8.test-broken-svgs-remix.pages.dev/

* This is all deployed via the Pages Build system; no local builds at all.

* Someone else on the team has an Astro example stood up with the specific unplugin-icons library: https://astro-svg.pages.dev/ - cannot reproduce the invalid SVG attributes.

We're going to continue investigating but don't see this as widespread and don't yet have any other reports. That there is a _difference_ between the direct deploy vs. using Pages Builds is a problem, though. We've also asked the Astro folks to understand if there's something up here as well.

(If not clear: I work at Cloudflare)

Can you share the ticket ID here and/or email me the details? silverlock@cloudflare

This should not be the normal experience. Want to drop me an email - silverlock@cloudflare - and I will have the team look into it ASAP.

(I lead our storage & DB product teams here at CF)

> The fact that D1 still doesn't support replication is an indication to me that it has been deprioritized, likely with other newer and less used products, while the infrastructure updates are dealt with.

D1 is definitely not deprioritized. We're heads down on replication, and it's important for us to get it right. Takes time!

> What a nightmare! Now your application code spills into your database and our initial goal of simplifying application development is nothing but a long-forgotten dream. All of that for what? To save a few milliseconds to display a web page.

I think "a few milliseconds" vastly understates this: if you want to run your application closer to users, even just across the US, each query is (at least) 70ms just to get over the network and back again.

"Application code spills into your database" was a bad thing when you wrote one language (say, Java, or PHP) and another language (PSQL/TSQL/etc) for your "stored procedures", but that's not what most modern databases are advocating for.

Instead, and not unlike something like React Server Components (RSC), you can choose whether to run code close to the user or closer to the DB (for transactions) in the same language as your application, because it's still part of your application code. This is the model that Durable Objects[1], our coordinated storage service, uses.

Disclaimer: I work on D1 & Durable Objects at Cloudflare, so I'm likely to be called biased here, but it's not like we haven't a) thought about this deeply and b) actually use D1 and Durable Objects to build distributed systems at Cloudflare.

[1]: https://blog.cloudflare.com/durable-objects-easy-fast-correc...

(I work at CF)

The dashboard team had a bug that caused too-large cookies to be returned to some users.

They’ve rolled out a fix but you can also clear cookies to remedy.

Unrelated - that’s a planned infra maintenance event.

Our public postmortem on the incident: https://blog.cloudflare.com/cloudflare-incident-on-october-3...

See my comment here: https://news.ycombinator.com/item?id=38075877

(We’ll share more when we can)

This should be resolved. We’re still investigating the underlying root cause, and intend to share a write-up once we have that in hand.

This is not the way we wanted anyone to start their week.

(I am the PM lead for Cloudflare Workers: Databases & Storage)

Not related.

(I am the PM lead for Workers databases & storage)

> due to the writers literally having disdain for the actual source material and we're just using the how's setting as a backdrop to push their own entirely disconnected stories.

Is this concretely true, or just disinformation to put blame on writers vs. producers?

I’m not saying it’s not plausible either way, but this is a common cop out.

(I lead DO & databases product here at Cloudflare)

Thanks for the kind words! Durable Objects also underpins a tremendous amount of what we build internally as well — it’s fundamentally a very powerful “coordination API”.

FYI: We’re continuing to work on observability & throughput improvements so folks can get more of each DO, on top of the horizontal sharding (“a DO per X”) approach we recommend.

> do you think you will have any API driven access to the data held in these services? IE, I don't per se want to have to use a worker to arbitrage between the Cloudflare platform and HTTP access to the data within Cloudflare systems.

For D1, yes — on the roadmap is a native HTTP API. KV has a HTTP API as well, so you can write directly.

Correct. DuckDB is really interesting technology, but it's not a direct successor to SQLite for transactional workloads. It's also very new: there's a LOT of new code in DuckDB on top of the (heavily fuzzed) SQLite parts.

(I use it personally, but it's not the same thing as what we're building with D1)

Fixing this. We ran a few benchmarks (and some were much faster than 37x), but this was a more typical case. Not our goal to inflate numbers.

> The problem with MQTT is that most of the use cases I’m interested in involve a web browser as at least one party of the connection, and the browser doesn’t support MQTT. I could wrap MQTT in a WebSocket, but then I’d lose the advantages of MQTT’s compactness and interoperability (unless MQTT-over-WebSocket is a thing?)

We support MQTT over WS (or JSON over WS, or just HTTP) in Cloudflare Pub/Sub, FWIW - https://developers.cloudflare.com/pub-sub/learning/websocket...

I also agree with the comments re: MQTT being well suited to a lot of these "broadcast" use-case, but that the IoT roots seem to hold it back. MQTT 5.0 is just a great protocol — clear spec, explicit about errors, flexible payloads — that make it well suited to these broadcast/fan-in/real-time workloads. The traditional cloud providers do MQTT (3.1.1) in their respective IoT platforms but never grew it beyond that.

I would strongly recommend against using IP ACLs to "... verify the source IP of the request to prevent acknowledging webhooks from unknown and potentially malicious servers."

You should validate that the request is signed correctly, and reject it if not. An IP ACL can be a useful "remove some of the noise" tool, but no more than that.

For example, Discord's webhook implementation has you verify the incoming request against an app-specific (your app; not all apps) public key: https://discord.com/developers/docs/interactions/receiving-a... — this is really the right approach to this.

That’s not the case — note that we don’t say “trusted network” in the blog. That’s definitely not the right solution.

There’s two key parts:

1) we can filter and secure traffic _leaving_ the device, whether bound for the Internet or internal apps. This isn’t VPN like: this is part of our software gateway. When you click (tap!) on a phishing link, we can filter it and render it inert.

2) using the eSIM, which is associated with a specific employee, as an identity signal and device posture signal. This fits squarely into the Zero Trust model. ZT is about explicit identity, not the old days of implicit “I’m on the VPN and can move laterally!”.

(I work at CF)

From the blog:

> ... we know that data locality is important for a good deal of compliance use cases. Jurisdictional restrictions will allow developers to set a jurisdiction like the ‘EU’ that would prevent data from leaving the jurisdiction.

It's coming: we understand the importance of data locality & residency requirements.

(I work at CF)

> In my case, despite living near Detroit and CF's datacenter there, I'm routed through Chicago, adding 40ms to any roundtrip time.

This shouldn’t be the case: want to email me (silverlock at cloudflare) the output of https://www.cloudflare.com/cdn-cgi/trace and your company’s accountId?

This is stuff we want to address — whether directly in our control and/or where we need to ensure others are peering with us locally to help their users.

It should work directly against R2 - our S3 compatible object storage) w/ no egress fees: https://developers.cloudflare.com/r2/

Makes experimenting with things like this much cheaper.

(I work for CF)

The $20/mo Pro plan includes formal support (one of the big perks of Pro!)

Just replied.

Ultimately it looks like the existing DS records for your domain weren't removed (and you can see that in your DNSViz output). Still have some questions for "how" it was working beforehand (see the email for those).

For others: I'll let the OP share what details they would like to, as this is their domain.

(It sucks that I had to see this on HN)

Can you email me - silverlock at cloudflare - with your ticket ID and domain name so I can understand what broke?

The F-Secure folks also have https://github.com/F-Secure/mqtt_fuzz - although it doesn't support authenticated brokers as of yet.

No concrete plans at this time, especially since there are many competing implementations.

If we open-sourced we’d need to do it right (proper governance, triage, support, etc) vs just putting into a public repo and calling it a day.

D1 _does_ use Durable Objects under the hood! Like Pub/Sub, it's ultimately an implementation detail, albeit probably interesting to this audience.

In the MQTT world, in which Pub/Sub is based, every publisher is a client, and every subscriber is a client. You can be both, too!

Assuming your existing backend is in $SOME_CLOUD_PROVIDER, publishing messages to Pub/Sub is just a few lines of code in your favorite language - we have a couple of examples up in JS + Rust - e.g. https://developers.cloudflare.com/pub-sub/examples/connect-j...

Subscribers receiving those messages can be anywhere you can run an MQTT client, which turns out to be... a lot of places :-)

(I'm the PM for this, and we'll be adding more examples to our docs in the coming weeks)