BinaryIgor

Isn't it centralized though, thus defeating the whole purpose?

That's a fair point, but as I've pointed out above, I think that the question of Identity is much broader and more nuanced than just owning a set of keys or nicknames; if you're curious I've written about it here: https://binaryigor.com/centralized-vs-decentralized-identity...

My Nickname on Hacker News - yes; but I own this Identity on at least one more platform and my own website, so it's not that simple :) In general, I think given Identity is more about reputation and familiarity that you gain with people by doing or delivering something under particular name in one or multiple contexts/platforms

I relate 100%; there are still a lot of people like us :)

Why not to have a website then? That's the only thing that where the content is truly Yours.

In NOSTR, even though yes there is more than one relay, but you still need their permission to publish; and yes, you can run your own relay - but you might host your own website too - no need for new apps and protocols to do this

Yes; and because your key is your identity, losing your key or having it stolen basically means that you have to start from scratch; there is no "I forgot my password" mechanism

There are also tradeoffs:

* relays can just go away - you don't have your data then

* there is both user-friendly and secure way of managing your private keys; additionally, once your keys are gone, your identity is gone - there is no "I forgot my password" procedure

I've revisited this idea/protocol a few times and still have my doubts:

* is there even a need for it? I would say that most people are quite happy with centralized platforms; I don't see it changing anytime soon (why?)

* wouldn't we end up in the centralized world anyways? Even though there could be multiple NOSTR clients and relays, we all know how network effect works - people will flock to a single or a few best ones; does it really change the situation that we have today - a few centralized platforms?

* I don't see clear incentives in this protocol that would improve current social media landscape - granted that I don't particularly like current ads/sell your attention model

I am not sure that having a protocol like this is better that having a few centralized platforms - today's situation. Not to even mention technical challenges and worse user experience that NOSTR brings

Interesting read, but what is a better alternative to the Process model? I'm not convinced that there is one

Interesting that it turns out to be true for code generation as well!

It's mixed; and to a large extent Internet is still an artifact of its one country of origin - USA.

Thankfully, as I've pointed out in the article - it's getting more and more decentralized; there's neither one country nor entity that controls it; it's a bunch of them

Super interesting - as with coding, these are powerful in the hands of someone skillful enough to get by without using them; they cannot replace engineers, just multiply their productivity

Interesting; I wonder, if the content is of good quality - do people care who/what have produced it? I would say, mostly not; it remains to be seen what/who is valued by most humans the most in this context - humans or machines

I wonder - whose public keys are needed for this particular DoH implementation to work? How do we know that they're legit?

I don't think it's that bad; first, you can always change requirements a bit; second, you always have a conversation about the implementation - there it's crystal clear when somebody has used LLMs without any understanding. If they can defend their solution, they should pass, since they understand it

I sometimes wonder whether we will ever solve all edge cases like the one described here; maybe, autonomous driving will always remain semi and almost there, but never quite fully

...or you can just use managed variety and not have to worry about monitoring anything db-related

Unfortunately, as (I think) all SQLite replication solutions, it requires you to run a separate process on each app machine. It defeats the purpose of using SQLite in the first place; if I must have an additional process to monitor and maintain, I might as well just use Postgres or MySQL

It's not that simple, there's a niuance there - tradeoffs are to to be made if we want to have a decentralized system; it will not scale to the whole planet, if running a node is accessible; and it must be so, otherwise it's not decentralized.

The reality is, we will have a mix of custodian - through third-party - and self-sovereign usage; depending on the context and user's skill

Just treat it as your checking account; for anything substantial, move it to the self-custody

I agree with the first part of your comment, but don't follow the rest - why SE you should be more tightly regulated? It doesn't need to be; if anything, it will just stifle its progress and evolution

Interesting, but way too optimistic and biased towards the scenario that infinite progress of LLMs and similar tools is just given, when it's not.

"Every small business becomes a software company. Every individual becomes a developer. The cost of "what if we tried..." approaches zero.

Publishing was expensive in 1995, exclusive. Then it became free. Did we get less publishing? Quite the opposite. We got an explosion of content, most of it terrible, some of it revolutionary."

If it only were the same and so simple.

100%; Exactly as you've pointed out, some technologies - or their "last" milestones - might never arrive or could be way further into the future than people initially anticipated.

The story of web development:

"For the time being, I’ll just do what most web devs do: choose whatever API accomplishes my goals today, and hope that browsers don’t change too much in the future."

Hmm - why would you do that? How much data, if any, can you safe by compressing it as to compared with the classic Base64?

Interesting idea; For schemas migration I like tools like Liquibase/Flyway/Knex, but their main disadvantage is that the more migrations you've had, the harder it's to reason about your current db schema

These are exactly the problems that often make software maintenance actually interesting :)

Interesting, but 18MB binary for a Hello World example? That Java runtime weighs a lot!

Ahh, still getting better after so many years of development!

I am particularly excited about async I/O to optimize reads and support for UUID v7; the leading timestamp part makes the better than UUID v4 in many contexts (writes, reads, sorting)

Usually there are not worth the complexity:

"Two-phase commit provides an eventual consistency guarantee only. While the transaction is committed, even if no errors occur, other clients will be able to see partial updates to the database cluster."

Plus, I wonder whether they have resilient mechanism to not hold transactions in the prepared state for too long, in case of crashes. In most cases, you can redesign your app/system to no require such complex things