DandyDev

This looks really cool and clever. I do have a question about security though. The FAQ states:

> Today, we encrypt all sensitive data on your computer before it is sent to our servers, your data is encrypted in transit and at rest. Our employees do not have access to the private key to decrypt sensitive data.

I wonder how this works. I assume Plus works by storing the cookies present in the user's browser so that it can inject those cookies in a headless browser to take a Snapshot. In order to do that, it would need to decrypt the cookie (if it was encrypted in the first place, which the FAQ seems to suggest). For that, the headless process needs the encryption key. That would mean that employees can also access that encryption key.

What am I missing here?

Fellow Dutchie here. This has also been a tradition in my family for as long as I can remember. My parents would actually act out parts of the sketch sometimes.

For us plebs that don't fluently read phonetics, can you spell it with equivalent sounds from English?

This feels like an uncalled for ad-hominem attack. Also, I might be in the minority, but I actually _like_ brew?

That is true _at the moment_, but do you think that when Elon starts charging money for the check mark, he's going to leave money at the table for something as small as authenticity?

Off topic, but can we please be civil and stop with the strong language?

How about: "I personally don't like the palette"

Gitea was a fork of Gogs. I'm assuming we'll see a fork of Gitea now?

You have left multiple comments now om this post with disparaging remarks about the Clickhouse team without any evidence to backup your claims.

Not super classy if you ask me.

That seems like hyperbole to me. Did you do concrete research/calculations to prove that for example Google in this case would not be able to turn a profit in the EU when they'd comply to regulations?

I think you're confusing installing the compiled package and using it (which doesn't require anything else) with _compiling_ the package, which requires XCode on MacOS

I think you make a good point. I removed that word from the description.

It's not a naive question at all! The 2 biggest differences I can see:

- Errbot being chat service agnostic, also makes it feel a bit "non-native" for Slack. For example, you cannot say "@mybot deploy webapp to production", but you have to say "!mybot deploy webapp to production". slack-machine can work that way as well (with command prefixes like ! or %), but it also responds to actual mentions (@mybot). There are more differences like that, where Errbot tries to be agnostic of the chat service it's running against, but that also means it has to cater to the lowest common denominator in terms of integration with a chat service. slack-machine can for example add "reactions" to messages, which Errbot cannot.

- slack-machine seems more feature-rich. Errbot seems to be focused only on commands that are triggered by sending certain chat messages. slack-machine lets you listen to any type of event Slack emits. Examples could be: someone joins a channel, a reaction is added to a message, a message is pinned. slack-machine also has built-in scheduling to trigger plugin functions on a cron-like schedule (Errbot has something similar with pollers, but it's not as flexible as a cron schedule)

For me it was a clear design choice to focus only on Slack, so the bots you build with it feel as "integrated" as possible with Slack. You can really leverage all that the Slack API has to offer.

That is an interesting use case! The solution you propose, could work.

I've also been meaning to add support for webhooks as well, so you could trigger plugin functions by calling an HTTP endpoint. It's a small step from having messages on a queue and triggering webhooks from them.

Anywhere you can run Python code basically. Sadly, with the decline of Heroku, I don't know of any places you can run Python code 24/7 for free.

Myself, I run Slack bots on AWS inside a Docker container on ECS (for $day_job) and inside a Docker container on my Synology for personal use.

Imports from 3rd party packages are always absolute. That's why I prefer imports from first party packages to be absolute as well

As mentioned in reply to another comment of yours, Budibase is your project. Please be transparent about that when you mention the project, especially as comment on a post that is about a competitor.

Can you explain why this is a bad thing?

Directories with an __init__.py are not modules, they are packages. Modules are .py files

No, the Dutch and Belgian governments are saying you CAN play the game as long as it's changed to remove gambling aspects or is sold as a gambling product with all the consequences that entails.

Activision Blizzard doesn't want to do that. Not the fault of governments

And as for the (im)possibility to develop games that follow the laws of all countries: that had been successfully done for decades. It just doesn't involve predatory microtransactions

Sources for this claim?

"Going to end in disaster" -> that's hyperbole

The fact that the Belgian and Dutch governments label these predatory microtransaction schemes as gambling, shows that they understand the subject matter perfectly fine.

Yes, you and I can sensibly choose not to play those games or spend money on them. But lots of people can't. That's why laws regulating gambling exist.

Nobody is saying that you can't play these games. Those gaming companies just have to accept that their products are a form of gambling and will be regulated and taxed as such.

But then it would be on par with Flask, both performance wise and with regards to integration with third party libraries. That is how I'm currently using FastAPI, with regular sync SQLAlchemy for example.

The difference is that even without the benefits of async, FastAPI offers a vastly better developer experience IMHO, with its integration with Pydantic, Python type hints and the lack of reliance on global objects

With the risk of feeding a troll: can I ask you why you're so angry in every comment? You're almost hateful. I want to understand what makes you act like this, why you think the makers of Fig deserve this kind of response and how you think your comments contribute something positive to the discourse here on HN.

$5/mo for 10 accounts is $50/mo in total. I don't know where you got the $500/mo from.

And that is a very reasonable price for a core service like email and not selling you data

direnv actually won't run anything until you explicitly allow it to. And if the .env file changes, you have to re-allow direnv to read and execute it.

Seems safe to me

This makes it sound so easy, but in my experience, permanent staging environments exist because setting up disposable staging environments is too complex.

How do you deal with setting up complex infrastructure for your disposable staging environment when your system is more complex than a monolithic backend, some frontend and a (small) database? If your system consists of multiple components with complex interactions, and you can only meaningfully test features if there is enough data in the staging database and it's _the right_ data, then setting up disposable staging environments is not that easy.

I'm confused as well. How can you run an RDS instance alone for 7 people for $150 a month? Let alone the other infra? You probably need a VPC on each account, with a NAT Gateway, which easily costs $20/month or so.

While you're right about European investors being risk averse, it's not generally true that American VCs won't talk to European founders. I'm an early employee at an early stage company (1,5 years old), incorporated in The Netherlands and we have raised a $2M pre-seed round and recently a $10M seed round both led by American VCs.

Question: what is "ideological" about the facts stated in the README? Putin invaded Ukraine. Lives are at stake. Being against that is no more ideological than the need for you and me to eat and sleep.

Hey samjs, we've been using Oso at Source.ag for a month or so, and we're really happy with it! Precisely the fact that you solve authorization on a resource level and implement filtering on the DB level, makes it super useful!

The biggest gripe we have, is lack of support for SQLAlchemy 2.0 style queries and lack of support for DB & Python enums as role names

We had a chat with Graham who told us about your upcoming cloud offering. Looking forward to that!