Do it like plane tickets do, tie a ticket to an identity + buyback up to a week or so before the concert in case someone wants to cancel (or authorize the transfer and capture only a week before). Ask for ID and ticket at the entrance.
I'd simply check filling speed, even with browser's autocomplete humans are slow due needing click submit.
Then when it's "processing", do them in bulk and prioritize slower users. There's huge opportunity do bot checks after checkout without affecting user experience.
Also on product launches you could add unique field which requires user to input, for example that way bots can't prepare for launches.
- behavioural fingerprinting
- ja4
- IP rep
- queue mechanism
- card country to IP country checks
- app attestation
- custom metrics based on knowledge of past scalpers
It's hard but it's not impossible. You can make it very inconvenient for scalpers. They need to poll at volume so their behaviour is very much detectable. A hard stance is required on IP rep, especially for more in demand concerts.
It's either that or you tie tickets to government ID like in France. If the arbitrage opportunity is more than the cost of automation then someone will exploit it.
they have the lowest approval ratings and legitimization in over half a century, because they're making everything shittier and shittier to the benefit of their corporate overlords.
If you are in the US, and are not fascist, I urge you to leave. You are in an equivalent of 1933 germany. It is gonna be dangerous to not bend for the great leader.
Hello, I am a single dev using an agent (Claude Code) on a solo project.
I have accepted that reading 100% of the generated code is not possible.
I am attempting to find methods to allow for clean code to be generated none the less.
I am using extremely strict DDD architecture. Yes it is totally overkill for a one man project.
Now i only have to be intimate with 2 parts of the code:
* the public facade of the modules, which also happens to be the place where authorization is checked.
* the orchestrators, where multiple modules are tied together.
If the inners of the module are a little sloppy (code duplication and al), it is not really an issue, as these do not have an effect at a distance with the rest of the code.
I have to be on the lookout though. It happens that the agent tries to break the boundaries between the modules, cheating its way with stuff like direct SQL queries.
My guess is this is correct. To the extent coding with agents becomes dominant, the need for non-technical managers to coordinate large numbers of developers will decrease.
If you're in Europe, I saw quite a few comments here saying that banks not requiring the duopoly do exist. Otherwise, a dedicated banking phone might be the way.