Tightly coupling identity to cryptosystems should be entirely dismissed for anything that is supposed to have broad adoption.
First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.
Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.
Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.
In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).
We need more and more varied DNS zones so there's competition between them. And not gTLDs which are just extensions of .us, but zones with genuinely independent administration.
Agreed. DNS is, afaik, the very best naming system we've got. But there's plenty left to do to make it better for human beings. Legally encoded rights to DNS names paired with easy-to-use GUIs for non-technical users would be near the top of my list.
And greater zone diversity like you say too. Kinda related to that, something like increased pinning of non-root DNSSEC keys so that the root isn't so all-powerful.
Technical people, maybe. Even if we hypothetically grant that vibe-coded backup systems can be trusted, deploying, using, and maintaining are still hurdles. And there’s absolutely no way that’s all tractable for the vast, vast majority of the population.
Mind you, an average person probably doesn’t even really know what a server is. And these average people need backups just as much as (probably more than) people technical enough to vibe-and-deploy.
I think that product people are very much doing development with these tools; and trusting, deploying and maintaining them. The vast majority won’t even know the trust, deployment and maintenance challenges that technical people know and so they won’t worry about them and probably never will need to. Anything very risky will be eventually protected by exposure in the training data. Not unlike how you see in lovable like building tools having built in scan tools.
The training data for these mechanisms is growing. As a technical person I deployed a clients site to lovable and now he maintains it. Anything risky? I trust lovable will surface it, and he’s comfortable with additional risk, and platforms like lovable may want to offer contracting help from humans In their platform in The future to help.
Why does someone who says “I pay -$x for Google Drive, how much can we make our own clone for?” need to know what a server is? The natural language doesn’t necessitate the technical jargon.
Even just by narrowing to some definition of "product people," you've cut out the vast majority of the population.
> Why does someone who says “I pay -$x for Google Drive, how much can we make our own clone for?” need to know what a server is? The natural language doesn’t necessitate the technical jargon.
My point wasn't specifically that they need to know what servers are. Rather, the point is that the average person who needs backups doesn't have the faintest inkling of the smallest fraction of what goes into a backup solution. For these people (the vast majority of the population), you'd need a truly new level of vibing than what exists today.
Looking at Lovable's homepage, their tagline is "Create apps and websites by chatting with AI." Your average person probably doesn't even understand that "apps and websites" are primary components of a backup solution.
Yes I get that. And yes I did narrow it in by saying Product people. My point is why would anyone bother to know what goes into building x (a backup solution for example) if building it doesn't require that?
Using me as an example, or my non-technical client now doing app development using lovable, we don't care to know how the things being built but just that it works and its reliable and consistent enough.
Less than a year ago I'd never built iOS or Mac apps, and now I'm building those - I come from an HTML and frontend world, not the Mac or iOS screen layout world and I still know nothing about that and don't want to either.
And I'm glad that works well for you! But this is the context of the thread:
>> most people don't need cloud backups
> What world do you live in?
As put by another commenter:
> Most People™ do not have the technical knowledge to set up a self-owned backup system, and/or will not realize how badly their future selves will wish they had backups if the setup friction for a self-owned solution is too high to conveniently do it right this second.
So, okay, if you're just saying Some Small Percentage of People™ can vibe up a long-term backup solution, then, sure, I grant that.
I just don't think it's a useful or interesting point in the context of this thread, even if it's true.
No I think we are taking about similar things, but the core of it is this:
- you and other guy believe non-technical people can't build technical things because its still too hard and you need to know the technical things
- I'm saying you don't now, and some the samples I showed are that we are moving in that direction and its possible now, even if most people aren't doing it now. that they could. and its an awareness and comfort problem.
> - you and other guy believe non-technical people can't build technical things because its still too hard and you need to know the technical things
Pretty much. Though maybe I should more softly phrase it as "you still need to have some idea about technical things." Even more importantly, you still need to have some idea about decomposing problems in a technical way.
What you said:
> the samples I showed are that we are moving in that direction
> and its possible now...its an awareness and comfort problem
So which is it? Are we there, or are we only moving in that direction? Core to my position is the idea that there is a long tail of competences that technical and "product" people have or can fill in the gaps with. Other people don't have these things that are needed to smooth out what AI misses.
Said another way, even if AI has made it 90% of the way there, that still leaves the remaining 90%[0]. Long tails are long, and smoothing everything out such that a truly average person would feasibly whip up a bespoke, reliable backup solution really relies conquering so many edges that technical and product people would never even notice.
looks like I had some issues with my thinking. thanks for pointing it out. correcting my stance to: we are going there.
your insights reveal we are actually further away than I thought. But I think I underestimated my skill in using the AI tools and thought the average person could build more than they can.
Not my area, but isn't it really only because glibc doesn't maintain stable interfaces across versions? If it did, you absolutely could use the same ld.so with different glibc versions. But it doesn't, so here we are.
First of all, techy nerdy people like things to be easy too. They're just somewhat more likely than other people (on average) to overcome not-easiness.
Second of all, how long is IndieWeb supposed to cook for before it's supposed to be ready for a broader audience? This is no shade on the IW folks if they like what they're building. But if what they're building is supposed to catch on somewhat, what's the path supposed to be? The project seems to be 15 years old already: https://indieweb.org/IndieWebCamps#
You mean a few customers? Yes, I think that’s perfectly reasonable to expect that changes made to a very expensive product are well-documented for those customers to whom that matters.
It says it's on the standards track, but it's clearly quite new. How well has it been proven out? This page from Hurricane Electric shows <3% adoption: https://bgp.he.net/report/rpki_and_aspa
It's still very early. RIPE and ARIN have only supported publishing them for a few months. ARIN made very little noise about it during the rollout, and many networks are probably still unaware. Give it a couple years, and I expect we'll see fairly good adoption among those already publishing ROAs. There will still be the never-RPKI holdouts, however.
Huge fan of jet. It lets you just write SQL, but in your Go. I basically can’t imagine using anything else now.
Why is that better than writing plain SQL like in sqlc? My main reason was being able to dynamically construct queries and reuse different bits. Plain SQL statements simply don’t compose at all, and I don’t recall sqlc giving any solution to help with this.
> Poor writing is not a new thing, of course. Most of the moderation mechanisms that it uses were perfected a quarter century ago when sites like Slashdot were popular as a defense mechanism against bad user behavior. Bad user behavior impacts commenting, article submissions, and moderating itself. While bad users now have AI to abuse, the problem of a large volume of low quality content is is largely the same.
I respectfully disagree on almost all counts (beyond poor writing not being new, of course!).
Moderation mechanisms have not been perfected. They're certainly not perfect, and, given that, I don't know what would make one call them perfected. Humans have probably gotten more accustomed to being moderated, but it'd take a lot to convince me that we have even reached a decent place for moderation at moderate scale, let alone something that is good-to-perfect.
Most importantly, the problem of low quality content is now not the same. Magnitudes matter, and a difference in degree eventually becomes a difference in kind. LLMs have escalated the problem of garbage content beyond what would've previously been conceivable.
To illustrate: How do you dispose of several trash bags at once? Take them to the trash can. How do you dispose of several tens of trash bags at once? Need to rent a dumpster.
Or a classic: If you owe the bank $100, that's your problem. If you owe the bank $100 million, that's the bank's problem.
Bringing it back to written content: doing human-driven moderation on hundreds of submissions a day is tractable with (idk) a couple of people. For thousands or tens of thousands? Intractable. And bear in mind that human-driven moderation is one of the things that keeps HN a better place on the net than many (most) others.
First off, these systems always require indefinitely-lived secrets. To rotate keys (or the whole cryptosystem—think future possible quantum computers) is to change identity. Therefore, to change keys is to break the previous identity. Anything that requires users to think about long-term secrets is user hostile and leads to a fragile system.
Second, the economics of pubkey-as-address are untenable. Can you imagine publishing .onion addresses on billboards and business cards, let alone sharing them verbally? Absolutely not.
Unless there’s something I’m missing (please do say), these problems are intractable when you’re dealing with cryptosystem-based identity.
In the end, identity and naming and fundamentally human concerns. If you try to kludge around this with purely technical solutions, all you’ll end up with is a system that doesn’t adequately reflect what identity means to people. Good systems support this (DNS, email); bad systems fight this (cryptocurrency, nostr).
reply