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.

I've been using Google Sheets as a data store for some of my latest projects, and it's really (mostly) delightful.

https://www.wheremoneygo.com barely has a database, and bedsides protecting the Google access keys has minimal privacy/security risk.

The main risk, and something I've only seen once, is a corrupted database on the Google Sheets side. Since I don't want to keep backups of peoples sheets, if something goes wrong on the Google-side the entire database could be lost.

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.

I've tried to release this a couple times in the past (you'll notice the git repo has a four year history), and happy it's finally out the door. If anyone is interested in using this, or wants to talk about the strategies I'm happy to help in any way I can.

Proud of what we built at Smyte, and hoping it can find another live outside of Twitter </3. I know there are already a couple of implementations based on SQRL, one at Discord and another at Sumatra.ai[1]

[1] https://docs.sumatra.ai/scowl/

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.)

Yes, but stock ownership isn't even and so it'll again primarily go to the CEO/etc (while reducing their tax impact).

The employees earning minimum wage, and who likely don't hold any stock, won't see any of it.

Yes.

The buyer would might have been willing to pay $15,000+, but wanted to anchor (and start low) so went $4,500. The real max was introduced when the seller gave the $15,000 number... buyers never want to or will reveal their number (i.e. the $7500 was a lie.)

A minor clarification about IPFS here:

The metadata in the NFT can (and in my opinion _should_) point to an ipfs:// style URL. The websites displaying the NFT would have to use some redirector, but the actual token would have a URL that anyone could host (known as "pinning") on the IPFS network.

Was released early December, was pretty confident about it-- probably should have bought more than one ;)

I bought one of his "Into the Ether" NFTs[1] but now I'm in a fairly interesting position. If I prove ownership of the artwork (via a signed message from the address) then Beeple will send the physical artwork to me but it'll immediately lose a high percentage of its value (currently trading at ~$90,000 from $969 original).

Right now it's owned/stored by the artist and someone buying the piece from me would be able to get it delivered directly from Beeple. That's a new level of unboxed where the piece of art is basically unseen at this point in time and can easily be guaranteed original.

[1] https://niftygateway.com/itemdetail/primary/0xd92e44ac213b9e...

Would bitcoin be where it is today without Coinbase?

Not to say it's impossible, but their work and approach definitely helped bring Bitcoin to the masses.

... and now you get to my point why I argued ETH2 is likely better on the security front.

Bitcoin needs a huge factory. ETH2 needs a billion dollars. I feel like a billion dollars could probably buy the factory you're talking about.

ETH2 also takes time to add new stakers to the network, but perhaps not as long as building the factory.

If you did this with BTC you'd cause a huge drop it the value of the network, and therefore your investment in miners

If you did this with ETH2 your investment would be destroyed by slashing, and the network might survive

... also keep in mind the Bitcoin factories already exist. You just need to buy one or two, or perhaps hack some of the mining pools.

I prefer the ETH2 semantics.

I've worked on a few similar projects, and in this case I'd recommend trying to write your syntax however you want, but implementing it as a transpiler to Python.

That way you always have access to the Python libraries, for competitions where you need to show your code it'll be easier, and there are already a lot of optimisations.

That said if you're primarily doing this for fun- go wild with the implementation.

Following the links down a hole a little bit I saw this statement: "Bitcoin is by far the largest and most secure blockchain"[1]

Sure it's the largest, but it seems ETH2 might now be the most secure. It (at current prices) has $2,400,000,000 staked in the network. Sure this is still in the league of nation states to corrupt, but the penalties for breaking the rules are _so much higher_.

Given that, and the fact that Ethereum is based around smart contracts, I find it hard to believe that this could compete with ETH2.

[1] https://blog.blockstack.org/realizing-web-3-proof-of-transfe...

This looks great! I've been looking for exactly something like this for one of my side projects: https://weblight.vercel.app/

I'll dig in a bit later/tomorrow, but assuming I'll be able to run some of my own JS to convert the code into the visual representation. If not you might have a pull request soon :)

It's still surprising to see Dragon Speech Recognition as the recommended (and only) choice here.

Is anyone working on decent speech recognition for Mac/Linux or know good resources for that? The ideal output is a stream of what could have been said, as well as some alternatives, each with a confidence.

Every alternative I've tried has not been as effective as the version of Dragon I used from 2011. I think the focus on accents and training is a big thing here -- I'm happy to spend a couple hours training it for better results.

The original version of EC2 (basically AWS) was built in Cape Town.

Google BigQuery does this though. They host huge public data files and then only charge for the queries.

Smyte (YC W15) | San Francisco, CA | Full time | Onsite | https://www.smyte.com/

We're primarily looking for a quality devops/infra/sre engineer, but we're also interested in anyone full stack or frontend focused. Check out our "jobs repo" here: https://github.com/smyte/careers

Why Smyte?

* We've built a platform to stop the victimization of innocent people online. We successfully stop scams, harassment, fraud, account takeover, money laundering, and policy violations.

* We are the highest-quality product in this space. We work with a selection of the top websites and mobile apps.

* We solve interesting technical problems. Open-source where we can [https://github.com/smyte] and give talks as well.

* We've built our own (successful) SQL-like rules and data counting/fetching DSL [http://docs.smyte.com/docs/introduction-to-sqrl].

* We have the strongest team tackling this problem (founded by ex FB and Google engineers working on spam and fraud, and Pete was part of the original React.js team)

* We recently a series A and our growth is out of control.

* We offer competitive salary, benefits, and equity.

Interested? Feel free to send me an email at jobs@<...>

Smyte (YC W15) | San Francisco, CA | Full time | Onsite

We're hiring for a variety of technical roles at Smyte. Check out our "jobs repo" here: https://github.com/smyte/careers

Why Smyte?

* We stop the victimization of innocent people online.

* We are the highest-quality product in this space.

* We have a seemingly endless supply of interesting technical problems and not enough people to work on them all.

* We have the strongest team tackling this problem (founded by ex FB and Google engineers working on spam and fraud, and Pete was part of the original React.js team)

* We offer competitive salary, benefits, and equity.

I do something similar, but the solution instead of `Aa$1` is to use the output to produce a shorter password with those properties [1]. Makes it a little easier to type in.

I also keep a list of the "domains" along with plaintext comments for each of them (username, email I used, etc) that are not strictly required (so still portable) but just make it a little more useful when it's synced.

The big downside I've found is lack of apps. Sure it would run on any phone, but I haven't managed to get it to run on the phones conveniently. So if I'm without a laptop right now for the most part I'm locked out.

[1] https://github.com/passwordly/passwordly-python/blob/master/...

Smyte (YC W15) | San Francisco, CA | Full time | Onsite | https://www.smyte.com/

We're primarily looking for a quality devops/infra/sre engineer, but we're also interested in anyone fullstack on frontend. Check out our "jobs repo" here: https://github.com/smyte/careers

Why Smyte?

* We've built a platform to stop the victimization of innocent people online. We successfully stop scams, harassment, fraud, account takeover, money laundering, and policy violations.

* We are the highest-quality product in this space. We work with a selection of the top websites and mobile apps.

* We've built custom databases [https://github.com/smyte/counters] and give talks on them [https://www.percona.com/live/17/sessions/smytedb-poor-mans-d...]

* We've built our own (successful) SQL-like rules and data counting/fetching DSL [http://docs.smyte.com/docs/introduction-to-sqrl].

* We have the strongest team tackling this problem (founded by ex FB and Google engineers working on spam and fraud, and Pete was part of the original React.js team)

* We recently a series A and our growth is out of control.

* We offer competitive salary, benefits, and equity.

Interested? Feel free to send me an email at josh@<...>

Smyte (https://github.com/smyte/careers) - San Francisco, CA

We've got hard problems in the spam & fraud space. Looking for infrastructure engineers, database engineers, experienced C++ folk, data scientists that have worked with fraud, etc.

The clipboard api only includes 'cut' and 'copy' commands. There is no way (except via extensions) to access the clipboard.