Relevant change:

   Security bug fixes

    PR: Critical: fix: prevent template expansion from interfering with git repo initialization. When generating a new repository from a template repository, Forgejo clones the template repository, removes the .git folder, performs variable template expansion on files listed in .forgejo/template, and initializes a new git repository. During this process, variable template expansion could be misused in order to create a new .git folder, which git would adopt and incorporate during its initialization of a new git repository. A malicious template repository could be used to read arbitrary data from the Forgejo host, and to execute arbitrary processes on the Forgejo host, as a remote code execution attack. To address this issue, after variable expansion is completed, any existing .git folder is removed from the directory before the git repository is initialized.

It looks like this is a bit less concerning if you have turned off open account registration.

I'm always curious where these moments of serendipity get their start. How'd you come to read Omar Khayyám's 11th-century poetry?

> Then that crazy bastard started taking photos of people's menus.

I don't get the reference. Is this a startup origin story?

The whole article is satire, parodying the overwrought ad copy designed to sell a simple appliance (electric kettle) to different marketing segments.

I think you can realize how ludicrous it is to invoke 80 year old copyrights for a product whose main use case is coding. How much code from 1946 was it lawfully ingesting?

No, of course not. They have zero domestic police authority for US citizens.

Meanwhile they run around pulling people over for "traffic violations" and then pulling a "Your taillights are out, and papers, please."

I was interested in the approach as a way to reduce DOM bloat, but it's clearly Claude's writing and visualizations.

It's still possible, but how worth it is up to individuals... IMO the biggest loss is accessibility.

Which is a competitive success story. It's much more profitable to avoid competition with abusive dynamic pricing and punish users for price-shopping.

It's a good reminder, because in the auth landscape I wish I had just picked up Keycloak and stuck with it. Commercial auth is a bad value proposition and not the kind of infrastructure where you want to have acquisition churn happening often.

The self-hosted space is another headache. I wasted so much time trying to make smaller self-hosted auth solutions work, since Keycloak has a reputation for being heavyweight.

I looked into the Ory stack extensively trying to actually use it as advertised for self-hosted / open-source auth. It's aggressively gimped and its SSO features are emphatically _not_ open-source and are gated behind licensing, with no way to find out until you're actually running it.

It's also just unfinished. Their "stack" is a lot of cobbled-together Go mixed with incompletely rebranded acquisitions like SAML Jackson (now "Polis"), which they managed to gut so completely it went from a best-in-class OSS library to unusable.

Probably the first time reading that the Ory stack is unfinished! Sorry you had a frustrating time, but there's 10 years of development and many happy customers + adopters who see it differently! Polis / Boxy still works as before, we didn't gut or take away anything.

Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".

For Ory, B2B login is a good value differentiator, because it's required by companies selling to other companies meaning they can spend some money on licenses to further develop software.

Ory powers the largest technology providers, and super small solo projects. It's robust, stable, Apache2 licensed. It's the best CIAM tech out there that's free (!!).

In the end, everyone is entitled to their opinion but the "open source can't make money" train is honestly a bottom tier opinion and I'm tired of reading it on HN, probably written by people making $100K+ a year for writing software and using open source daily (without paying a dime).

It's like the people complaining that Wikipedia is collecting too many donations, while they cheer on Apple or Anthropic or whoever raking in billions of dollars.

Somehow, only if it's open source / non profit it's bad to make money. If it's proprietary nobody gives a damn. Says a lot about society.

>Open source development needs to be paid by someone - most of the time people complaining about paying for software are working themselves (for money!) in some company making huge bucks, or looking up to "successful (as in money) tech leaders".

There is software that is cutting edge and always changing, and those types of products need to be paid for much more than software that is stable.

With a stable product like Auth (which requires only security fixes and minor features), the 'pay per MAU' model employed across Auth companies is unreasonable

A combination of the people and companies using the product for free or selling its support (like RedHat and IBM for KeyCloak) along with an open license allowing it to be offered as a cloud service should be sufficient?

If you want to pay per monthly active user for the rest of your life, up to you.

Vercel have raised multiple rounds, last one was in 2025 and $300m. So we don't know what the VC's are going to demand for revenue targets. https://en.wikipedia.org/wiki/Vercel

Auth is not stable, it‘s constantly changing and evolving and also a lot of work to keep secure, and scalable. Auth is critical infrastructure and certainly not free. Most companies with homegrown at some point go to a vendor because it is so much work to DIY.

I can’t speak for Vercel‘s goals or pricing - but Ory is evidently still open source while many others went other routes!

i'm curious, outside of new models of authn (such as passwordless, totp, hash algos etc) and new models of authz (rbac, zero trust, etc), what else is "constantly changing"?

even the items i mentioned only change every 5 years or so, in my experience. i accept that there will be a lot of work preventing attackers from gaining unauthorized access, but again this feels partially solved by just rejigging the authn flow (rather than username -> password -> totp (leads to password sprays), just do username -> totp -> password)

C# is strongly-typed, not stringly-typed. The point of the union is to list possible outcomes as defined through their respective types.

The idiomatic way to do this would be to parse, don't validate [1] each string into a relevant type with a record or record struct. If you just wanted to return two results of the same type, you'd wrap them in a named tuple or a record that represented the actual meaning.

[1] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

I guess C# is more strongly-typed than Haskell then... /s

String literal typing appears to be a common feature of type systems bolted onto dynamic languages:

    # Python
    MyStringBool = Literal("Yes") | Literal("No")

    // TypeScript
    type MyStringBool = "Yes" | "No"

I assume it exists to compensate for the previous lack of typing, and consequent likelihood of ersatz typing via strings.

It would seem pretty unnecessary in Haskell, where you can just define whatever types you want without involving strings at all:

    data MyBool = Yes | No

Of course you'd need a trivial parser, though this is probably a good idea for any string type:

    parseMyBool :: String -> MyBool 
    parseMyBool "Yes" = Yes
    parseMyBool "No" = No
    parseMyBool _ = error "..."

Interestingly, dynamic languages which make use of symbols (Ruby, Elixir, Common Lisp) probably fall closer to Haskell than Python or TS. Elixir example:

    @type my_bool() :: :yes | :no

    @spec parse_my_bool(String.t()) :: my_bool()
    def parse_my_bool("Yes"), do: :yes
    def parse_my_bool("No"), do: :no
    def parse_my_bool(_), do: throw("...")

Where :yes and :no are memory-efficient symbols, not strings.

String literals are structural types which are way more expressive than regular (Haskell) ADTs, which are nominal types.

In TS in particular, in combination with other features (mapped types), they are equivalent to row polymorphism + whatever Haskell/GHC features enable type families to specialize on constant literal arguments (or you can use atomic types, but that's not structural / open-world)... so pretty advanced.

This is valid TS/Python:

    type ABC = "A" |"B" | "C"
    type AB = "A" | "B"
    const x: AB = "A";
    const y: ABC = x;

The equivalent Haskell requires using several extensions.

I know. I literally gave the example of a Python Literal in the post you're replying to. TS too. :)

My overall point is that Haskell's type system is sufficiently expressive (you may not have "A" | "B" | "C", but you do have A | B | C) that there's no obvious remaining use case for string literals, unless you're thinking of typing input by way of expected literals instead of actually parsing it, which is... a choice. :P

By Haskell's type system do you mean with all the GHC extensions?

Because TypeScript has structural sub-typing, while standard Haskell (eg. `A | B | C`) has neither subtyping nor structural typing, which both are very useful features for safe "integration/glue" type of programs.

(String) literals form a fundamental part of the TS "row polymorphism" (record types) and eg. tuple union type implementation.

You can type a non-empty array that starts with zero...

    type Arr = [0, ...number[]];
    const a: Arr = [0, 1, 2, 3, 4]

Now try in Haskell.

> By Haskell's type system do you mean with all the GHC extensions?

No? What extensions does `A | B | C` require?

> Haskell has neither subtyping nor structural typing

Is subtyping back in? Good news for Java and C++.

Re structural typing, I would ask what behaviour you're after, specifically. For example, this is a valid, typed Haskell function for any two values that can be added, including any user-defined ones:

    adder a b = a + b

If by structural typing you mean silently coercing types that the compiler deems structurally equivalent, then no, but I don't think many people writing Haskell would consider that desirable. A `Person` may have an age (40) and a `Wine` may have an age (2005), but you're not going to get sensible results if you start adding those two together, and your compiler should probably stop you.

Structural typing is the sort of thing that is very valuable if you're bolting a type system onto a language with a cornucopia of untyped structs, like JS objects. It is comparatively much less valuable if you're working in a typed ecosystem to begin with, since you're not liable to have loose untyped structs floating around that require coercion.

> "integration/glue" type of programs

It does sound a lot like you're using string literals in lieu of parsing foreign input, which strikes me as a pretty bad idea. Particularly in a language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways, and cause behaviour far removed from what any static analysis of the TS source would suggest.

> You can type a non-empty array that starts with zero

Can you please name me any possible actual use for this? Especially given the type doesn't even exist at runtime and will never be enforced on input data, so this is a once-off check for comptime constants?

Haha, I knew you'd bring up Go. I even considered pre-emptively dropping Rust and Zig as counterexamples. I think most people who favour static typing consider the duck-typed interfaces of Go to be a mistake. Personally, I consider all of Go to be a mistake.

> these type system features were added by multiple experienced language designers for a reason

Oooh, an appeal to authority, where that authority isn't even named. I'll have you know a famous queen told me you're wrong on this, also for "a reason".

> TypeScript has several runtime-safe advanced validators based on its type system (most well-known being Zod), capable of enforcing types similar to what I provided.

Right, so TS typing is so amazing it requires runtime parser libraries from NPM, and Haskell is less sophisticated because it's not stringly typed.

You realise the entire, complete, exhaustive runtime schema for your zero-first non-empty integer array example looks like this in Haskell, right?

    sch (0:_) = True
    sch _ = False

That's a complete function that somehow manages to work without pulling in NPM dependencies. The best JavaScript minds of our generation remain baffled.

> The Person/Wine example is a pointless strawman

> I didn't give practical examples to save space, obviously, it was just to disambiguate what I meant.

So when you use illustrative examples, it is to "disambiguate what you meant" (huh?), and when I do it, they're "pointless strawmen". A little hypocritical, no?

> a bit ignorant

Honestly, I don't think you know what you're talking about at all. You clearly hadn't even read my comment when you started replying with Python and TS examples... that were already in my comment.

It also really sounds like you're using string literals to type input without properly parsing it, which is just a terrible idea. Haskell's type system is designed precisely to protect you from this sort of mistake. [0] No, you're not always going to get what you expect. No, your JS program will never let you know that's the case. No, a sane type system does not require mainlining runtime parser libraries from the biohazardous oceans of NPM. A schema in Haskell is going to be significantly shorter and sounder than anything in Zod, and you don't need a library for it.

As I said above, TS' type system makes sense for a type system bolted onto a dynamic language post facto. TS needs to more tightly link (even mildly conflate) values and types, since it needs to do a lot of clever narrowing to figure out what mad ball of JS it is dealing with at any given time. Haskell does not operate under any such constraint.

> I don't see a productive continuation to this discussion.

Phew. Timesaver.

Of course the irony of all this is that I use TS daily, and Haskell quite rarely.

[0] https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Yeah, you're just continuing to take whatever was written argumentatively/maliciously as predicted.

Does not seem like this:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

> Personally, I consider all of Go to be a mistake.

You also consider Scala and OCaml to be mistakes? Because all of what I've mentioned also works in a very similar way in Scala.

> an appeal to authority

No, I didn't appeal to authority. It's the opposite - it's statistics. Multiple experienced language designers don't add features later for nothing. For a similar process, see eg. closures getting added to every mainstream language.

> complete, exhaustive runtime schema

Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.

> A little hypocritical, no?

No, they aren't comparable since I wasn't using the examples as supports for an argument of whether X is better than Y. Strawmen involve argumentation.

> read my comment... examples... that were already in my comment

I read it in detail, the problem is you didn't really read my comment in detail, which illustrated both the subtyping and structural typing aspects (albeit trivially, yes), which yours didn't.

> You're also fairly clearly using string literals to type input without properly parsing it

Okay then, the arrogance of this is pretty astounding... You seem to know what I'm doing better than I am!

To be clear, I'm not doing any of that. And I've written Haskell way before I wrote any TypeScript.

I believe I was promised a respite from this.

Everything I said to you prior to my last message was fairly gentle. I'm not sure what response you were expecting to what you wrote at that point, which was to accuse me of disingenuous strawman arguments and ignorance. Perhaps you yourself would have benefited from a rule refresher?

> You seem to know what I'm doing better than I am

Apparently so! Trust me, it gives me no pleasure, and I'd rather I didn't.

> Again, I wasn't talking about runtime schemas, but types. I only mentioned runtime as a counterpoint to the false statement that TypeScript doesn't enforce this. Only reducing this to runtime checking is a fallacy, again.

My dear friend, this is almost completely incoherent.

I wish to strictly type myself as a function at this point, whereby your messages are my input, and void is my output. Zod, activate!

Having reviewed as instructed, I stand by everything I said here. Let's review the action replay.

I began by noting that TS has literals and set theoretic types, and that this makes sense for a post-facto type system bolted on top of a dynamic language. Jaen showed up to inform me that TS has literals and set theoretic types, implying he hadn't read my post.

I noted that typed string literals are not generally considered desirable within strictly typed environments. "Parse, don't validate", etc. Jaen seemed to follow this up by aggressively trying to prove that TS is somehow "better" than Haskell. His arguments comprised the fact that TS has literals and set theoretic types (again, yes, this was is in my initial post), and a mixture of personal insults and just straight up nonsense (I wasn't the one to bring Zod into a discussion of type systems... ). At that point I did have a little fun with things, since it had become clear Jaen was not a constructive or good faith interlocutor.

Jaen's central misapprehensions seem to be that (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".

As I repeated a number of times above, TS' type system makes sense for a type system bolted onto a dynamic language. It's extremely useful when the underlying language has oodles of untyped structs flying every which way. Conversely, Haskell's type system makes sense within a holistic strictly typed environment. Structural typing would be a gaping hole in Haskell's strict type safety, which is kind of Haskell's whole thing. Neither system is better, each has its use. Different strokes for different folks.

I don't usually put much stock in upvotes, but I do note I seem to have the edge there. Seems that our esteemed panel of armchair referees respectfully dissent from your narrative, nvlled. :)

You seem to be aggressively misreading what I said, stuck in your own "world" and instead of asking for clarifying questions, making unfounded assumptions.

> I began by noting that TS has literals and set theoretic types

Can you please quote me exactly the part of your original comment that implies that literal types are structural and have subtyping? Because that is what I said. If you did imply that, well, excuse me for helping you by clarifying then.

> aggressively trying to prove that TS is somehow "better" than Haskell

Sorry, what? Refer to the first line of this comment. Just saying that some type system features are extensions or harder to use in Haskell says nothing about the superiority of TS. This is completely your imagination.

Here's me criticizing TS 4 months ago: https://news.ycombinator.com/item?id=46501061

> I wasn't the one to bring Zod into a discussion of type systems...

Not sure why this is even relevant, but this was a direct reply to: "...language like TS, which is not type safe at runtime, and which will happily ingest an unexpected value, silently coerce it in all sorts of fun and wacky ways"

Zod (just a random library) is a direct counter-example to that. There may be better counter-examples. One just needs a proof of existence - it doesn't have to be good.

I then had to repeat that I am also talking about static types because of: "...exhaustive runtime schema for your zero-first non-empty integer array example...". TS can both enforce that as a type (which you never presented for Haskell) and as a value. (nominally typed solutions quickly run into ergonomic problems like phantom types not being composable across library boundaries - eg. refinement types, which are even safer by nature, are structural!)

In any case, I'd estimate 99% of people using TS don't encounter any type safety issues caused by the design of TS. Haskell has `unsafeCoerce` too, just a bit wordier than in TS.

If wanting to talk about real unsoundness, one would mention something like bivariance (see also: linked comment), but even then almost all of that is entirely irrelevant in most practical software engineering.

> (a) I don't understand literals and set theoretic types, despite this whole thread being in reply to a post where I give examples of them in TS; and (b) that I care which type system is "better".

Huh, what? Again, I'm thinking none of that. Again, you imply you know better what I'm thinking...

> Structural typing would be a gaping hole in Haskell's strict type safety

I mean, yeah, let me just repeat OCaml and Scala here, both also famously type safe languages... Why make an argument when there's two immediate counterexamples that were already mentioned?

> but I do note I seem to have the edge there

This pretty much sums up the difference in attitude, I'm not here to score internet points in an argument.

I just wanted to comment on why the world is not black and white and even technically flawed languages like TS have something to learn from.

Thank you for the lecture but I didn’t mean that. I meant `Either String String` is possible in Haskell and not in C# because… C# is strongly-typed.

You're welcome! Knowing is half the battle.

That Haskell snippet is just syntax sugar for Left(string) | Right(string), which is trivial in any language with unions.

Not clear why it would be an improvement over just naming the alternatives something meaningful, but if you're wedded to Left and Right, go for it.

You cant have a `type Foo = String | Strimg` in Haskell either.

But you can have an `Either String String` which is what GP was talking about.

My mistake. I see my oversight now. `Either String String` is not equivalent to `String | String`, but to `Left String | Right String`. The same must be done for the C# version.

Yes, you must have individual constructors for the left and right cases in order to distinguish them. In C# you would use two distinct record types for this. Haskell’s syntax is more concise though, since you define the constructors inline in the declaration of the sum type.