switz

They are banned at the edge in Cloudflare (now), they never hit my application.

There is so much spam, abuse, and aggressive scraping that I've had to block:

  - AWS
  - Google Cloud
  - Azure
  - Alibaba Cloud
  - Oracle

and a handful of other ASNs on almost all of my properties. It would be one thing if it was simple scraping, but it's often genuine agentic abuse (just spamming for vulnerabilities* or scraping millions of pages with very little valuable or dynamic content). These clouds must get the abuse happening under their own roof under control.

I banned Alibaba's Cloud two years ago and it still hits one of my domains 1 million times per day, despite every route 4xx-ing during that time.

Even Apple has aggressively ramped up its scraping in the past few months, but thankfully they do respect robots.txt.

It's frustrating because some of my real users route through these clouds via their work VPNs.

* like leaked .env routes, brute forcing admin panels, and so on

Been really enjoying the X3 lately. This is a great piece and ideally how a good blog post written about an experience with AI should go – authentically written, and not AI generated. I had fun reading it.

4.6 was the last model that didn’t over-cook its writing in circular loops. I use it as a daily driver and drop into fable when I’m doing higher level architectural work. 4.6 is so much more efficient in its effort.

It became obvious to me very quickly that 4.7 and on were broken. I’m a little puzzled how others didn’t realize it, but maybe they don’t actually review model output (code) or have a strong process/workflow.

I agree. They can only build things that have incredibly well defined surface contracts[0], where every tasteful decision has already been made, tested, and scaled.

And putting out a 50% solution counts as 'enough', even though the hard work was always in the last 50% (qa, deployment, docs, bug-fixing, etc.). And they get to effectively state 'we wrote X in Y', which makes for a great blog post, but terrible software.

Is it worthwhile for some abstract benefit of theory-crafting and experimentation? Sure–but it ultimately is more noise than signal.

Note that the bun-rust conversion blog post took an extra month or two to come out, because it wasn't just a theoretical marketing piece.

[0] (disclaimer: my blog post) https://saewitz.com/tests-are-the-new-moat

It largely works and it's a massive business success. This is the classic engineer asking the 'why this technology?' to what amounts to a business question.

They chose it early on, it works, and it makes obscene amounts of revenue. End of story. That doesn't mean it was the "greatest" choice, or has a perfect technical architecture.

Rewrites are never easy, even the bun rewrite. But a non-UI developer tool with a rigid API surface contract (and associated tests) will always be easier to trust after a rewrite than a partially tested UI tool with ambiguous functionality.

I do this. The awkward thing is when I am in person or on the phone and have to explain that my customer email address is [their_business_name]@my_weird_domain.tld

But the people usually just nod along.

The other downside is that it's forward-in only, wish I could proxy responses without setting up a whole new inbox (and outbox).

Can someone explain to me if EU card transactions are capped, why Stripe charges me (US) the full ride on my EU customer's cards? In fact, I get charged even more for EU cards – perhaps as much as 2.5% extra.

I just checked and I get charged ~8% in fees on a 10 euro transaction on Stripe. Of course some of that is the low transaction amount (flat 0.30), but it's brutal for a small business like myself.

    2.9% + 1.5% (intl card) + 1% (currency conversion) + 0.30

    Payment amount (€1.00 EUR = $1.15253 USD)
 
    €10.00 EUR -> $11.53 USD

    Fees

    Total:    - $0.93 USD

    Stripe currency conversion fee 
    - $0.12 USD

    Stripe processing fees
    - $0.81 USD

    Net amount
    $10.60 USD

I guess the NA interchange is charging the card, rather than the EU? Could using a MOR reduce the fee structure?

I personally don't agree, and my experience is that RSCs embrace the inherent complexity of building websites. All websites span the server and the client to some extent. Giving you the tools to wield those boundaries is actually a bid for developer autonomy and flexible control over user experience.

It is complex because the domain is complex. Though it requires a deep understanding of the web as a platform, most high-level websites could net-benefit from the ideas behind RSCs. I don't find it to be quite as much of a footgun as most people would suggest, but if you don't understand both server and client in a deep manner it is, of course, confusing.

Happy to dig in deeper for anyone who wants to have an honest discussion about the benefits and drawbacks without dropping into FUD. Even if you decide it's not for you, all web developers could glean something from their model.

It's also always worth noting that RSCs don't require a server, and still bring value without one.

It's a shame that VCs have corrupted a $200MM/year business into the perception as a failure. Who cares if the VCs didn't get a large return, or if the outsized impact of the software didn't quite fully capture the value created. $200MM/yr without aggressive R&D or operational costs could be an incredibly healthy business.

Maybe we should stop trying to build so many billion dollar/year businesses and work on more sustainable models.

Please do not wash your authentic writing through an LLM.

Workers runtime is open source and permissively licensed fwiw

https://github.com/cloudflare/workerd

Though this would be mildly annoying for the earnest case (selling a ticket to a friend), it would be the actual solve to the problem.

The parent's suggestion still creates artificial scarcity, which is the real issue: people buying tickets they have no intention of using.

The problem is that the artists, venues, and ticketing companies benefit from this artificial scarcity. So we'll never see it change.

It's really up to the artists. Many are surprisingly cool with it, though there are a few notable exceptions (i.e. Prince). Sounds like the artist in this particlar case gave their blessing.

Many bands (like GD and Phish) specifically note in their rider that venues must allow and provide space for tapers to bring their rigs in.

A sibling comment in this thread pointed out my project Relisten[0], which now has over 4,000 bands who have given explicit permission for people to tape, record, and share their concerts non-commercially. We've been operating our FOSS platform for 12 years, and most of the audio is hosted by Archive.org. I can't tell you how many bands have begged us to add them to our platform.

[0] https://relisten.net (https://github.com/RelistenNet)

(The 4,000 number will be coming to web soon - it's available today on our mobile apps)

Oh hey, it's me! Happy to answer any questions

We landed an update on mobile last week that brought all 4,000 artists with a "collection" onto Relisten. That'll be coming to the web and sonos shortly as well.

We've been discussing the Aadam Jacob's collection with the archivists for some time. It comes with its own unique UX[0] and data constraints so we've been iterating on that and waiting for a critical mass of uploads before tackling it. We're getting closer though.

I agree with most of the sentiment in these comments. Archive and share non-comercially all the things!

[0] it's not "one" artist so it requires some custom UI, it should be unified through a single Aadam Jacob's collection, and it has a unique data path/structure on Archive.org relative to other collections

4 1's == 4/1

could just be a coincidence

really appreciate you building and maintaining it! state machines are the truth!

I run Firefox latest so it should work. There's always a risk when going from HTML5->Web Audio. There's an occasional blip that's impossible to avoid (or at least, I have never found a solution). It doesn't happen every time though. Try going from track 2 to track 3 in the second tab of the demo (if both are "READY" as web audio).

The problem with exclusively using the web audio API is that the entire track must be loaded into memory before playing it, whereas HTML5 loads progressively. So we use both to balance the techniques.

In prior versions of the library, we'd load the track in parallel to HTML5 and make the switch mid-track so it's actually far less noticeable even if it does blip. I'm considering adding that to the new version.

Another alternative is building a custom buffer using RANGE requests to exclusively drive it via the web audio API. But obviously that is a far more complex undertaking (and requires the server to support RANGE requests). I'm open to implementing it, though.

Thanks! Please do share if you choose to implement it (you can open a Github issue). I'd be glad to add any projects using it to the README.

Gapless 5 was actually the pre-cursor to this library over a decade ago, so Rego deserves full credit. They built the first example of gapless playback on the web and I took inspiration from their techniques.

Gapless 5 has a built in UI and style. Our library is headless: you bring your own UI and controls. It just depends on what your use-case is.

RSC by design does not ship everything to the client. That's one of its basic premises. It ships markup, composed in client interactivity, but you can shed a lot of the code required curate that markup.

This is pretty fascinating and comes with some complicated AI-world incentives that I've been ruminating on lately. The better you document your work, the stronger contracts you define, the easier it is for someone to clone your work. I wouldn't be surprised if we end up seeing open source commercial work bend towards the SQLite model (open core, private tests). There's no way Cloudflare could have pulled this off without next's very own tests.

Speaking more about the framework itself, the only real conclusion I have here is that I feel server components are an misunderstood and under-utilized pattern and anyone attempting to simplify their DX is a win in my book.

Next is very complex, largely because it has incrementally grown and kept somewhat backwards compatible. A framework that starts from the current API surface and grows can be more malleable and make some tough decisions here at the outset.

Crazy to see it's already being run on a .gov domain[0]. TTFGOV as a new adoption metric?

[0] https://www.cio.gov/

Yup! We’re just one link in the chain (bands, tapers, archivists, & the listeners), but I appreciate the sentiment. Alec and I have been running Relisten for over a decade and we’ve put a lot of work into it these past few years.

Had to give the Dead a little nod here

Huh, sounds like a fun unicode rendering width issue. I suppose if I claim it's ASCII, I should just use ASCII. maybe I'll add an `--ascii` flag?