> The formulation in the article may lead to a very bad advice: in some areas, scammers do display a "company name", regularly. So: a numeric sender string increases the chances of the SMS being a scam; an alphanumeric sender string /does not/ decrease the chances of the SMS being a scam.

Just curious, which part of the text did you understand this way?

If I would guess it could be with this part:

> The number of the sender and that of the service provider they claim to be, do not match. Moreover, when you receive a message from bigger service providers, (f.e. banks, post offices, or delivery services) they will mostly have their company names displayed instead of their numbers.

As I understand it, the article suggests that you still should compare the numbers even if only a name is displayed? But yeah your explanation is still on point.

> which part of the text

Well, there is a big image below, visually more impactive than the pasted paragraph, that goes "Messages from bigger services #do not# display their numbers". Yes, but neither do scammers.

You are trying to discriminate legitimate entities L from impersonators L̅ through properties P, and especially define ways to identify L̅. You state that P(L), but that says nothing of L̅. And in fact, it is P(L̅) also - logical exhaustion.

Logically the sentence works, because it implies "If messages display their numbers, they are not from bigger services". But in terms of effectiveness in communication, if put in the context of "how to recognize a scammer", the original may be misleading - because there (see the picture) you are focusing on the alphanumeric, not on the number, and the alphanumeric is not a criterion - the number is.

The intention was to state "do not trust numbers". But in that context it is important to stress "do not trust alphanumericals either".

Sounds like you would be interested in v2 (https://zitadel.ch/v2) as in it will be provided as single binary, which you should be able to use in our homelab setup.

There are a lot of other improvements, but if that's the only dealbreaker, v2 should take care of it.

Wow I was not expecting that! Usually offering only a Kubernetes version is the new way to force small users to the SaaS version.

True, we think that for most setups and early explorations K8s is too much of a beast. TBH we are in the process of switching our cloud from K8s to Cloud Run which is kind of close to Knative but without the ops hustle ;-)

Apache 2.0 and golang. Thank you! That’s exactly what I was looking for. I’ll check out v2 asap.

Thank you, v2 will be ready in the next 2-4 weeks. We are already running it internally ;-)

Oh yeah I came here to ask "when". 2-4 weeks is brilliant. Hopefully this is my IAM strategy sorted and I can worry about some other stuff instead :)

I'm really impressed with your strategy and v2 looks like a really great upgrade.

Thank you ;-) we will keep you posted.

Yep, that's the only dealbreaker for me - I'll keep an eye out for v2!

Love it, we will definitely create a post here in the next 2-4 weeks.

Your v2 pricing model is lame. I was literally pulling out my credit card when I saw the original pricing.

Thanks for the feedback.

What do you not like of the new pricing? The pay-as-you-go approach?

The background to this is, that we got many customers asking for features on the lower tiers and that many of them wanted to have a more linear scaling in their business cases. On the other hand we wanted to make sure, that even from the start you get all security features without paywalling them.

The 25K request roughly translate to 10K user per Month and you will be able to get that without a credit card :-)