It's not like something changed magically for no reason because humans are weird.

No one says this can't be done. In fact, it's explicitly mentioned in the essay, that the problem this approach has is that it's centralized and you typically can't use it as an anonymous proof of humanity, or disclosing information selectively.

So, why is this important? Well, while you can still make a website and trust you won't be popular enough to become a target, the truth is that without proof of uniqueness / humanity, many services and systems can't be put to the service of the people without potentially falling into an insane battle against spam, in protection of user data, in protection of privacy, etc. And while you can absolutely build lots of things without giving a shit about all this and actually be successful, it's simply immoral (and progressively becoming more and more legally restricted). If this was a solved problem, digital services could finally become truly democratized. Nowadays, this is the main issue preventing many programmers from setting up useful services, very often intended to serve the local community, requiring us instead to start a whole company, getting in touch with some lawyers and storing user data like their actual state IDs. Which we can't do if we don't intend to monetize the service! Without this barrier, we could really do a lot more for our local communities in the digital space.

Edit: "account" may not fully capture everything ory might be trying to do, but it's definitely closer than "identity".

Sorry for the rant and what may sound like a very negative comment, I wrote this quickly. I think it would be great to right away stop using the term "identity" so freely and use something else, or at least clearly explain what do you understand for identity. I think it would be great for programmers to start disambiguating the concept, and I think projects like ory have a good opportunity (that you yourselves created and built, of course!) to make it a bit better.

What happens, as the article indeed points out, is that many things keep breaking, and we keep fixing and repairing and improving and more things fail and stop working and then again we fix and replace them. And so on and so on. The main problem is that people suffers in that process. The system self-regulates, sure. Nature self-regulates all the time through natural selection, evolutionary pressure and competition. That doesn't make it right. We develop medicine because being human is the opposite of accepting the randomness, competition and cruelty of nature. We want to have control, we want people to be happy, we don't want to be exposed to arbitrary tragedy, unfairness, pain.

As I always say, don't confuse the comfort of your boat with the state of the sea. That you are comfortable riding the current wave of pressure doesn't mean no one is suffering. This doesn't mean we should never grow, but it means we should do it responsibly. Saying growth is already responsible because the world keeps self-regulating is just being blind to many of the dynamics of the system.

And ok, one may argue that finding an equilibrium is impossible. That when there are resources available, we will always start taking more and more, growing above our possibilities, taking water until we hit the bottom, dumping shit until it spills. Then pressure and competition kicks in, people fall, people suffer, self-regulation is the way and all is good again. I don't understand.

(sorry for the rant, I understand you may also have concerns about the rate of growth and welfare of people in the process, but I wanted to share this take anyway)

It's really hard to internalize it if you are not "weird" in any of those ways, but we should all be more aware of it.

But sure, let's not give any ideas or question anything ever again, someone might get offended.

I'm actually really happy to get generics in golang, and I'm happy with the team giving it as much thought as they need, but we are only gonna get so far within the current paradigm of trying to model the universe from a few text files. Generics are nice, but we shall do better in the future!

Either the dynamics work in favor of the people, or they don't. That we continually mistake the comfort of our ships with the state of the sea is just the blessing and tragedy of our ignorance.

It helps create a sense of community very quickly, and it helps keep it alive.

Honestly, trying to judge Discord for its ability to structure information is simply missing its point. I dislike many things about Discord, but projecting my needs or preferences onto it and saying it's bad based on that alone is quite shortsighted.

This is not the case here. It clearly says: "we can deal with the simple cases nicely! but no promises beyond that!". It's fair.

My core argument is that tools do not solve problems, they transform them, and you can't trust a tool that doesn't acknowledge that. This one is saying it transforms the common cases into simple ones.

Edit: oh, a relevant reply https://news.ycombinator.com/item?id=30293064

I find this comment from Griesemer [0] on one of the github issues for enums in Golang quite insightful:

>> [...] all the proposals on enums I've seen so far, including this one, mix way too many things together in my mind. [...] Instead, I suggest that we try to address these (the enum) properties individually. If we had a mechanism in the language for immutable values (a big "if"), and a mechanism to concisely define new values (more on that below), than an "enum" is simply a mechanism to lump together a list of values of a given type such that the compiler can do compile-time validation.

Like with generics, I like the team's approach of taking features seriously, not adding them just because other languages have them, but actually trying to figure out a way for them to work in Go, as cleanly as possible. I think computer science, as a field, benefits from this approach.

And I also dislike many things from Go, and I want "enums" badly too, but that's for another comment.

[0] https://github.com/golang/go/issues/28987#issuecomment-49679...

In fact, the idea of trying to model complex systems in a text format divided in files (most programming languages) doesn't quite hold... gracefully at least. For example, the frequent discussions about inheritance and generics are pretty revealing of the fact that we mix modelling and implementations in the same working space, when in fact in many cases it would be better to work on those at different layers.

So, in my opinion, to really make "code colocation" better you would kinda need to start modelling complex systems with richer toolsets that don't try to express them only with code files. You can't properly work with complex systems with a single view, no matter which one you pick.

>> Blocks built with the Block Protocol can easily pass data between applications because the data within each block is structured.

Yeah, what you said. What's their problem? What better world do they imagine? What's the approach taken on their solution? Very poorly explained.

EDIT: Joel's article is much, much, much more convincing.