That includes the original poster! "could have been because I purchased gift cards from the US (online) and added them to my account while I was in Mexico, or I was using a VPN while adding gift cards"

One of the other people was someone who "purchased $2k in apple gift cards from target during Black Friday deals... There was a limit of 1 but if you went in store and were friendly to the cashier a lot of people (myself included) had luck getting them to ring them up as separate transactions".

Pretty sure if the latter person had given those out as separate cards to other people it would have been fine but going from "limit of 1" to "all redeemed by same account" is unsurprising when it triggers a fraud flag.

The big problem in this story as in the past one is the apparent lack of sensible escalation.

I've heard horror stories from Google devs that it's even worse - such a situation follows you for life even if you try to setup new accounts.

Nobody in this HN thread has used the word "sentinel" - see another HN about the concept https://news.ycombinator.com/item?id=36195425

People got hung up on: - "COBOL defaults to..." rather than "banking practices are..." - epoch start dates - many pointing out COBOL didn't use epochs or counts, just much-damned YYDDD or YYMMDD actual strings.

Also, Elon loves to stir with partial misinfo hence his tweet https://x.com/elonmusk/status/1891350795452654076 with the breakdowns by age bracket. "Death set to FALSE" means "Death date not known" but that's not clickbaity enough.

That long tail looks awfully like data entered from historical records lacking death dates - there have been a few discussions of the cost of finding death dates and the decision to avoid spending $millions on it, as this is not data used to make payments.

You would expect, in a system that's pulling data from many sources, to see historical jumps in data cleanup like this. Imagine a few large states finally get around to digital records of deaths, so their data is easily aggregated - you get a sudden flushing of people who would previously have been left on the list. However, this will only apply from a certain age onwards as those sources in turn don't have the time/budget/interest to digitise really old records.

BUT That's now officially unsupported as all of Xamarin Forms is no longer supported and the MAUI replacement doesn't cover Linux nor does that look likely (MAUI is mired deep in problems due over-ambition, failure to resource and it seems a significant push in MS to use MAUI Hybrid aka web UIs within native apps).

The concept may be portable - the devil is in the millions of details on which I've seen many promising tools bog down and die.

Also, please, don't say _first of its kind_ unless you've done enough research to be confident.

https://www.ibm.com/docs/en/rhapsody/8.2?topic=developing-ro...

I did a lot of code generation work in those years, working on the two dominant Mac-based generators (AppMaker and Prototyper) but was never ambitious enough to try round-tripping because of the horrors of parsing C++.

Legal were so backlogged that approval for anything other than a strategic project was impossible.

I was not allowed to submit work to unapproved projects, other than my personal stuff I'd listed as my own IP on being hired.

It's usually about IP protection ahead of brand protection.

Wow, that's fascinating to find out that is how the US works.

Australian mobile numbers and I'm pretty sure most of the European ones, are prefixed by carrier and have no geographical breakdown.

Even just announcing the work of the Xamarin C# team that I'm on got some complaints from the public about this representing a "loss of focus". So yes, you could say there was a "business reason" of protecting the core team whilst they got to 1.0.

If you look at the C++ portions included in most of the Realm open source you can see we have moved code gradually into the open source codebase. There's not yet an official C++ API either for the same reason - it would lock in too many decisions and tie up the team. (disclaimer - these are opinions and observations from a remote contractor, not Realm management!)

I'd like to think that the C# team has also contributed by setting a high standard for API usability and ease of use but we're standing on the shoulders of the giants who wrote LINQ and Fody (thanks Simon Cropp).

Realm also keeps growing all its other teams and people are welcome to apply https://jobs.lever.co/realm