qixxiq

I’d caution against your “free forever” offer. Most people tend to backtrack on it.

There’s one case where it gets super popular, or attacked by spammers/bots, and the site becomes more effort to operate publicly than you want to do for free.

In another case your girlfriend stops using it, as well as some family, and the continued maintenance over the years feels like it isn’t worth it (because there is always maintenance.)

Either way you might want to shut it down, and promising “forever” to users feels problematic when you’re not being finically incentivised to keep it running. With the financial incentives it’s much easier to pass the burden on to someone else if you can’t run it for whatever reason too.

    Current implementation has the following limitations:
      Maximum object size: 65534 keys
      The order of object keys is not preserved
      ...

    These limitations may be lifted by using more bytes to store offset pointers and counts on binary level. Though it's hard to imagine a real application which would need that.

I've worked on _many_ applications which have needed those features. Object keys is a per implementation detail, but failing at 65k keys seems like a problem people would likely hit if this were to be used at larger scales.

A piece of this (after just plain greed and enshittification) is inflation.

Or perhaps some type of shrinkflation, just offering less services at the same price.

I don't have an understanding of SSE in depth, but one of the points the post is arguing for is compress once (using zstd dictionary) and send that to every client.

The dictionary allows for better compression without needing a large amount of data, and sending every client the same compressed binary data saves a lot of CPU time in compression. Streams, usually, require running the compression for each client.

I think there's one extension, although you _kind of_ covered it with "you just like the product"

Some people are addicted to the product. It's not even that they like it any more, and they can see the harm it causes, but they also can't imagine their lives without it.

I think it's a vital move by the government, but I also think it's too late.

Honestly our findings from working at scale (Facebook, Google, Twitter, Discord, Reddit, ...) were actually the opposite.

With hand written (not arbitrary) rules it's easier to understand the intent of the attacker and build a system that they can't work around because we're blocking them at their source of income. Sure they can figure out how to post messages but unless they can include their link/payload/etc it's not worth their time.

Machine learning defences are definitely a part of what we did, but they're slower to respond to attacks and generally easier to work around.

This was temporary due to the Twitter API being turned off, should be working now! (With slightly older data)

Sorry based on some other feedback I was just hacking away on turning off the profanity filter. Didn't think about the profile images (which we're not scanning, but typically is associated with them)

Version I'm pushing up right now has a

  LET ProfanityFilterEnabled := false;

that you'll need to tweak to turn it on.

Ah! Yeah extremely poor timing. The Twitter API has stopped letting me fetch the events. Going to try see if I can fix it quickly.

In the meantime the Wikipedia demo should be working, although it is far less interesting (much less data so not much spam popping up.)