After seeing a synthetic version that mimics the tone well enough, the real HN once back here felt slightly less distinct. When every information style gets a believable AI twin, our usual cues for judging what’s credible start to wobble.

To be clear, the strange part wasn’t that it fooled me, it didn’t. The issue was some form of “signal contamination” that my brain experienced.

"What's credible" is an entirely different question to "what's human-made".

Do you not feel this "signal contamination" when seeing the normal HN feed?

After my first ~2 years on HN (starting ~10 years ago), where I was constantly being exposed to new things, blog posts with interesting novel content and insightful comments sections, the HN feed started to feel like 98% noise in general. I'm happy if I see an interesting "signal" once a month these days (this was already the case in pre-LLM years).

Is this comment part of the experiment also?

You're absolutely right! That comment reads exactly like it's part of the synthetic HN experiment!

It's probable that LLMs are already operating on the real HN, agentically or driven by users who want to create intelligent-sounding comments for the sake of upvotes.

Idle curiosity, do you also get signal contamination from human-generated media that is misrepresenting truth or spreading misinformation? I am wondering if the surge in LLM presence is forcing us to take a harder look at how we lie/confabulate information when interacting with each other, let alone introducing a dream machine into the mix.

I think metro trains in countries like The Netherlands and Singapore use this approach where in you tap your cards and entry and exit and you are billed usually somewhere at the end of the day.

It's more complex than that: The card actually has some nonvolatile storage with your current balance, which gets decremented each time you use it.

Yes, stored value cards are a very mature technology.

For various reasons, they're mostly used in closed-loop systems these days (think laundromats, transit systems etc.), but historically there were open-loop deployments in many European countries, and in some countries, stored-value POS payments are still very popular, e.g. in Japan.

It's a real shame that the entire world moved to online-only. Sure, it's much easier and there's less opportunity for various kinds of fraud as a result, but in terms of availability during outages or cyber attacks, it was a big unforced step backwards.

> historically there were open-loop deployments in many European countries

Indeed, there used to be things like "Moneo". The problem is that banks never trusted really these systems, so you were limited to, say, 50E of stored value. Also for some reason in Europe the readers of such cards have never been great, I guess because most devices were built on the cheap, so even if the transaction is offline and supposedly fast, you would have to wiggle your cards all around most readers for 2s until it's picked up.

In Hong Kong there is the Octopus card, which started as a closed loop subway card, but ended up being so loved that now you can pay litterally anything with it. It can store up to $500, and you can set it up to automatically top-up to $500 more per day linked to your bank account. Also accepting payments from octopus cards is very easy, you don't need a physical device and small businesses can just have the customer card tapped on their phone with a merchant app.

Stored values cards were the way French public phone booths worked when they first moved away from coins in the 80s.

There were single-use chip cards that you bought and kept in your wallet. Plain eeprom.

I remember I built a reader for them as a teenager...

These were storage only though, right? Such systems are trivial to compromise.

Stored-value payment cards usually contain at least a secret key and some logic that allows them to establish a secure channel to another trusted entity, such as a merchant smartcard (which can be embedded in a terminal) or a backend server (and a corresponding HSM).

Not in the Netherlands, no. The card can be a bank card, and you can be billed at the end of the month automatically through direct debit.

It also wouldn't work as you describe, as the terminal at the point of entry doesn't know how much to charge you since it doesn't know where your journey ends.

Some transit systems work by putting a hold on your card for a nominal amount. When you finish your journey it then only claims the cost of your journey

Thankfully that’s not the system GVB uses, it’s incredibly annoying to have these transactions and reversals when trying to do your own accounting.

Holds don't really show up in the monthly statement. At least not in the cards I've had. It's a functionality for merchants to say "I'd like to charge this customer up to $500, would she be good for it?". If the CC company says yes, then the merchant knows they can do so. E.g. car rental companies do this for potential damages. Up to a week the merchant can charge the actual amount (usually less) or just release the hold.

Holds are a credit card feature, GVB is a Dutch transit authority, so they're more likely to be talking about bank cards, ie. debit cards, which I don't think support holds in that same sense.

It will bill your 4 EUR (on a tram/bus) or the whole 20 (or something on a train) instead of the actual journey price if you forget to checkout. Pretty sure it can decline cards for insufficient balance too. Not sure the entry gate blocks the amount.

Actual chipcards don't bill you at the end of the month either -- they reload a fixed amount through direct debit (which takes a few days) the moment your balance crosses zero. If the direct debit isn't setup for a card (because it's not a personalized card) or the debit was rejected, the card is blocked.

For business chipcards cards it works somewhat the way you described.

It definitely exists in Amsterdam, no? When I visit I just tap my card/phone on NFC enabled card checking machines (which exist in and out of the stations)

There's stored value and then there's "account based ticketing" where your card is just an ID and the final amount will be debited daily.

> The card actually has some nonvolatile storage with your current balance.

I'm not trying to find a gotcha, but wonder how that works with paying by phone nfc and then by card?

in the Netherlands you can now pay with your normal credit or debit card instead of a special train card. Was a thing in Kyiv metro for a decade too.

I'm not well versed with CURL design, but curious - is your first connection handling TLS while second relying on the previously established handshake?

I'm not very well versed with CURL design too but afaik it does reuse connections but only inside the same process (e.g. downloading 10 files with 1 command). In this case it shouldn't be re-using them as I ran 2 different commands. I should have included TLS handshake time in the output, though. You can see it here (overall time is lower because I hit preview env that is slightly different from staging/prod):

First hit: ``` DNS Lookup: 0.026284s Connect (TCP): 0.036498s Time app connect (TLS): 0.059136s Start Transfer: 1.282819s Total: 1.282928s ```

Second hit: ``` DNS Lookup: 0.003575s Connect (TCP): 0.016697s Time app connect (TLS): 0.032679s Start Transfer: 0.242647s Total: 0.242733s ```

Metrics description:

time_namelookup: The time, in seconds, it took from the start until the name resolving was completed.

time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.

time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed.

time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.

TLS handshakes (outside of embedded hardware) should be measured in milliseconds, not seconds

Edit: you can kind of tell this from the connect timings listed above. TLS is faster the second time around, but not enough to make much difference to the overall speedup

I think you're right that TLS doesn't explain the difference shown above, but for completeness: TLS 1.3 can reduce the round trips from 3 to 2 on session resumption. [1] Depending on your Internet connection, that could be a lot more than milliseconds. I don't think `curl` uses it by default though.

[1] https://blog.cloudflare.com/introducing-0-rtt/

This why I love reddit. Oh wait!

Inspired by his work on buffer bloat like so many others. Rest in peace.

I like the way this being proposed in a decentralised manner. Kudos to the author for the effort and thought put in.

However, I am curious what the incentive for publishers is to adopt this standard if those emojis are only relevant for the websites own silo? Use cases like these call for customized deep integrated implementations.

My question is a curious one. I might be missing the big picture and would like to get educated.

This is also using OpenAI's GPT model. So the same hallucinations are probable here for PDFs.

As relaxing as this experience was, I thought of resolving the itch to write trivial code to control the emojis and creatures with left/right clicks.

    let clickCount = 0;
    document.addEventListener('contextmenu', event => { (clickCount == 0) ? clickCount : clickCount--; event.preventDefault() }, false);
    window.onclick = function (e) {
        return clickCount++;
    }
    function random(i) {
        let emojis = 20;
        let creatures = 14;
        if (i == 1) {
            return (clickCount % (creatures + emojis) < creatures) ? 0.02 : 0.03;
        }
        else if (i == creatures)
        {
            return index = clickCount % (creatures + emojis) ;
        }
        else if (i == emojis)
        {
            return (clickCount % (creatures + emojis)) - creatures;
        }
    }

No lion in the code. Snake yes. https://drawing.garden/sketch.js

I got a lion!

Are you sure it was not a hedgehog?

There are ample developers who can build but not sell. You want to look for SaaS in this list that you understand and can scale/extend and sell.

But at a 25k limit? That seems too low to be interesting to either buyers or sellers.