Receiving the flowers is one thing. Then having a video shared about it is another thing. And even beyond that, the second can also affect the perception on the first: maybe you thought it was something random at first, but then you realize it wasn't.
It's not like something changed magically for no reason because humans are weird.
In a local context, many kinds of "social networks" or spaces to share things with other people from the same area, specially related to art and culture. Also many local associations organizing events could use unique identities to make it easier to make reserves for events with food, races, slots in talks, concerts, etc. Many other kinds of specific applications are also possible. You could even organize games and augmented reality activities much more easily if people didn't have to create accounts for everything, we had an easy way to verify that a human is trying to use the service... and even more if we could verify some info like "this person is from this area" (though there are some workarounds for that). Mostly, use tech to reivindicate public space, which public administrations have a tendency to mismanage as if it was their own private space (lack of vision is typically also an issue). There are many other ways to do similar things, but that's what I had in mind when I talked about democratization.
But does it allow you to anonymously prove that you are a human? You don't want to go telling random websites who you are.
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.
A user account, an email or a phone number do not uniquely identify a person or process, and it doesn't tell you whether it's actually a person or a process.
Edit: "account" may not fully capture everything ory might be trying to do, but it's definitely closer than "identity".
Hey, I've seen the project in the past and it's very interesting, and definitely an improvement over existing alternatives. That said, I have one complaint quite unrelated to tech itself: I think the liberal use of the term "identity" is very inappropriate. Of course "identity" is an extremely hard term to even define, but as far as I can see ory kratos is only assisting with email and phone verification. To talk about "identity" on that context seems very out of place to me. Maybe there's more that I've missed, and if that's the case I'm sorry. I understand words have more than one meaning, but there are big challenges to solve with regards to identity in the digital world that as far as I can see ory doesn't try to solve at all, and we end up spending time reading through the docs and trying to see if someone is making a meaningful contribution to the field for nothing. I know competitors use the term irresponsibly too, but... nevermind.
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.
Funny thought: then we may characterize a complex system as a system that's (most of the time) too big to fail all at once, and whose resilience to failure simply arises from continued previous failure. Which sounds like another way of saying "I don't know what I'm doing, but it kinda works"... until it doesn't. Maybe when it has inevitably grown too big to be successfully maintained anymore.
And yet, at the same time, growth can't continue forever (unless you get into space colonization on artificial habitats and are able to develop that faster than population grows and other stuff we are not going to discuss now).
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)
This reminds me of people who always forget their keys. I always thought: "nah that doesn't happen to anyone", and then I discovered it happens to a lot of people. Different brains work very differently, and there are some common bugs that affect some people but not others. See also those who can't stand watching a video to learn about a subject, versus those that can't stand reading. And that's even without getting started on personality disorders.
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.
Golang is my favorite language, and I really like the approach that the team takes. A few days ago I shared here some interesting comments from Griesemer on Golang enums.
But sure, let's not give any ideas or question anything ever again, someone might get offended.
Programming languages are lacking because they are too stuck in the "implementation plane" while trying to deal with lots of "system design" problems. Generics, traits, interfaces, union types and others are fundamentally targeted at giving developers more expressive power to describe the systems we are designing. We know there are many parts we could swap around, using different implementations, connecting some pieces here and there... and the system should make sense and work. We can see that it must work! But these features are trying to resolve problems from a very closely-connected but still different domain, and that's why we see so much friction when trying to use them. We try to encode system-level patterns in the implementation, and there's gonna be friction. We can see that these features give us power, and that's why we like them, but we also see the problems they cause, and that's when we get cold feet and say "yeah... maybe it's not such a great idea".
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!
Even when recognizing that there are a lot of bad actors in marketing, that's still an extremely over-optimistic perspective: at some point, tricking people becomes easier than improving the products, value propositions become muddier, and snake-oil starts to be used as the lubricant for business relationships. Only the most obvious offenders get run out of town, while most evolve and get to raise the new normal boiling point; as long as refining the snake-oil is cheaper than refining the actual products, the situation keeps getting worse.
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.
My general complaint as a distinguished member of the leaky abstraction crowd is not that abstractions can be leaky, but rather that they are sold as if they weren't... with creators being so willing to ignore from how many places their abstractions leak.
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.
I don't have any strong opinion about it, but I have the same question: is it possible that in the long term the backend will be replaced by a custom one? And if not, what is the postgres backend bringing to the table that's difficult to replace? Sure there will be some friction between edge's model and the way it has to be internally expressed in postgres?
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.
There are many different criteria to decide where to put your code or how to group it. And each case benefits more from one idea or another (and each codebase contains many different cases). Humans don't organize knowledge in folders in their brains. The information network is much more complex. We can't find a good solution only with folders.
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.
The problem is always the same: to do things right, you need people who know what they are doing. Redundantly. Yet, most of us don't know what we are doing, so in practice we end up creating proxies for "the people who know what they are doing according to their certificates certify that I know what I'm doing". Because otherwise you wouldn't be accepted in a cool position, and we all want to be in a cool position. And that's how we end up with so much shit overflowing in the world, but people still pretend they have their own under control. Feeling greedy? Play pretend. A few hours later... Want to be accepted? Play pretend. A few hours later... Want to not be left out? Play pretend.