When it comes down to it, whatever works best and is usually the most simple, non-breaking, used to win out. That decision has been disconnected from the value creators to the value extractors. It is impossible to extract value before value is created.

Additionally, programming is a creative skill no matter how hard they try to make it not one. Creativity means trying new things and new takes on things. People not doing that will harm us long term.

I also like the Lit Framework (https://lit.dev/) from Google which is rarely mentioned but it is quite nice for some of the simplifications and extras you might need when building them but it doesn't get in the way or try to take over your entire domain with dev-lockin.

Whether going direct to WebComponents or a higher level simplification like Lit, they really are a freedom from dev lock-in that is nice to see.

Typically I use something like JSONPath [1] (basically XPath for JSON) [2] or jq for this but having more options with other syntax and style is helpful.

For streamed JSON like NDJSON [3] there are some nice filtering options [4]

[1] https://en.wikipedia.org/wiki/JSONPath

[2] https://datatracker.ietf.org/doc/html/rfc9535

[3] https://github.com/ndjson/ndjson-spec

[4] https://github.com/mbostock/ndjson-cli?tab=readme-ov-file#fi...

> The decision marks a significant shift from Amazon’s earlier return-to-work stance, which required corporate workers to be in the office at least three days a week. Now, the company is giving employees until Jan. 2 to start adhering to the new policy.

So on top of all the hustle of end of year, everyone will need to frantically prepare for return to office one day into the new year. Just seems a bit heartless.

Remote jobs just allow a team to be more robust and dynamic to life changes. I just don't understand the need to force RTO so drastically.

Developers and value creators with power are like an anti-trust on consolidation and concentration and they have instead turned towards authoritarianism instead of anti-authoritarianism. What happened? Many think they can still get rich, those days are over because of giving up power. Now quality of life for everyone and value creators is worse off. Everyone loses.

I knew you wouldn't answer. You fail to even acknowledge evidence, what do you know about it? Nothing. How do you think evidence comes about? Just shows up one day? It takes people researching it and events to happen. Your hypothesis is not even attempting to start to see evidence, never be an investigator with that vibe.

Our discussion on your diversion is done, I know where you stand.

- You like crypto consolidation, you won't even attempt to answer that one.

- You are diverting from the point so far it is laughable now.

- Nick Szabo thanks you.

Admit you are an absolutist not a probabalist. Absolutism to no change is more religious than probability. You sure do preach absolutism.

The idea of boards might even be an anti-pattern going forward, they can be played and used in essentially rug pull scenarios for full control of all the work of entire organizations. Maybe boards are past their time or too much of a potential timebomb/trojan horse now.

Glad you could go on record and show you are an absolutist not a probabilist. Even cryptography itself is probabilistic. There are no absolutes in time except change.

You also skipped these two questions:

- Do you understand what diversion from the point is?

- Do you think Satoshi is Nick Szabo?

We are so far deep in this distraction that we have run out of room to reply without it being a line of vertical text.

Let's agree to disagree. I'll let you have the last word on this diversion.

GitHub Copilot is made with OpenAI's Codex model, a descendent of GPT-3 though.

Anyone putting anything into ChatGPT is taking a risk, or any third party tool really. Especially LLMs/GPTs because all AI models are like immutable datastores in some aspects. Once in, never getting out.

This also coincided with it being integrated directly in Windows. If there is a security issue, and I am sure there are many, this could be majorly problematic for business intel and confidentiality.

You did ask. heh.

As I mentioned, I prefer direct standards or at least frameworks that make standards a main part of the design, even if only on output.

Standards are slower to finalize, frameworks front ran them via abstractions that may have been needed for a while --like Flash with interactivity before HTML5/canvas/svg/WebGL/etc and I was huge into Flash and plugins, those days are over though. Standards will be around longer and more maintainable on standard schedules not just feature/dependency pump frameworks of today that have verbloat.

Plugins and now frameworks innovate and front run, and influence standards, then standards win the long game every single time. Like why use virtual DOM when shadowdom is now available, unnecessary abstraction now that will always lose to native dom abstractions like shadowdom.

Right now with web standards where they are at, Javascript how far it has come, and the coming WebAssembly + WebGPU platforms now being ready or close to ready, the current frameworks are about to be lapped. It is just the way things go and the typical waves in innovation to standards and repeat.

About Lit, I mentioned it as I said in another comment "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice"

We can agree to disagree on the rest.

Answer these, let's get you on record:

Do you think encryption methods today will hold up over time 100%?

Do you think early bitcoin keys from 2008 will never be broken (disregarding tools and being found which is more likely)?

Do you understand what diversion from the point is?

Do you think Satoshi is Nick Szabo?

You won't eventhough these are very easy YES/NO questions.

C'mon, put your money where your mouth is.

The others like React/Vue/Svelte etc are all going more for platform/framework lock-in over making sure people are doing augmentation of standards.

Those frameworks have incentive to lock you in while standards are lock-in at a lower level.

Other standards I like playing with direct like html/css/canvas/WebGL/storage/svg/video/audio/geo/etc and ones that are newer are WebRTC/WebGL/WebGPU/WebAssembly etc. All of these are and will be abstracted by some frameworks and people will know less about them and more about the platforms on top if they aren't regularly going direct. I think people that know about the standards more low level make for better framework developers an developers that use frameworks even.

I like platforms that make web standards the core aim not the platform lock in.

Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.

Lit is somewhat Angular like since Google make both.

Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.

I still prefer direct and custom with less dependencies but Lit is somewhat trying to communicate web standards while other current frameworks really want lock-in to the platform rather than caring about making sure devs understand the standards.

You are very focused on "winning" rather than the topic of concentration in currencies in the digital space, whether those keys are found, solved or some future system or hole is able to break them.

Good debate but I feel you were debating and shadowboxing yourself mostly, some side point that I guess you "won". I answered all your questions and provided sources on them to back them up. You still refuse to acknowledge.

Can the keys be broken now? No. Will they? According to you... NEVER!

Since you still won't answer these questions for our future observers, I take it you think they will never be broken.

Let's get you on record...

Do you think encryption methods today will hold up over time 100%? According to you YES!

Do you think early bitcoin keys from 2008 will never be broken (disregarding tools and being found which is more likely)? According to you YES!

Ok, glad to get you on record. I work on probabilities and that we don't know all parts, is there a probability that these keys will one day be broken, YES. A high probability, with lots of time, YES. Even higher if the values of these early coins/keys are multiples of what they are today, YES.

We can agree to disagree on this point without you going into ad hominems again on some side point. Where there is loot and prizes, some will be very motivated to find a way to get at those keys, either finding them, finding holes in tools used to make the keys or with lots of time, break the algorithms or brute force them.

I work in games and no matter how well you hide things, players will find the holes. It is actually quite amazing when you see it. Never underestimate the human with tools and intel/tracks. I am sure you will misinterpret this but it is true.

Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level.

The article from OP mentions this:

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop.

There are other reasons as well but these are the best reasons.

I think using a framework for a team isn't a bad idea, but for products and personal projects I like going custom or newer framework like Lit simply because of the web standards being less abstracted away and due to that, less need to constantly update on others schedules due to dev lock-in. There is less weight in straight standards.

If you remember React/Vue originally won due to virtualdom and being small parts that work into an existing web, but recently they have been very monolithic in that they take over the entire project. The web is more about augmentation as the article mentions and I agree, those items will be easier to maintain.

The problem with frameworks, especially web frameworks, is they reimplement many items that are standard now (shadowdom, components, storage, templating, base libraries, class/async, network/realtime etc).

DOM rendering speeds have been improved due to virtualdom but is no longer needed with shadowdom.

The web standards of today are amazing and take away the need for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in.

React for instance jumped ahead and front ran WebComponents and ShadowDOM, those are both part of the browser and standards now. The killer feature phase of React is over.

If you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice. [11]

Google Lit is like a combination of HTML Web Components and React/Vue style components. The great part is it is build on Web Components underneath.

[1] https://caniuse.com/template

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

[5] https://caniuse.com/shadowdomv1

[6] https://caniuse.com/custom-elementsv1

[7] https://developer.mozilla.org/en-US/docs/Web/Web_Components

[8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...

[9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition

[10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation

[11] https://lit.dev/

Nice job distracting from the OP even about concentration and early owners of Bitcoin.

> Bitcoin's encryption is elliptical curve.

Did you just learn this? The point is processing power at quantum level already starts to threaten some of the encryption methods and early keys are definitely at risk over time. Additionally there is motive to find holes in early tools that someone could unlock all that lost bitcoin... over time.

Did you ignore everything like this?

"AES-128 and RSA-2048 both provide adequate security against classical attacks, but not against quantum attacks. Doubling the AES key length to 256 results in an acceptable 128 bits of security, while increasing the RSA key by more than a factor of 7.5 has little effect against quantum attacks."

Since you are so singular focused, combative, and black and white on this. Since you don't adhere to future probabilities over time and unknowns, you seem like you fully think today's encryption will never be broken by advancements in decades or longer, as cryptographers fear could happen which I just shared with you, even programs at NIST regarding research on this.

Let's get you on record...

Do you think encryption methods today will hold up over time 100%?

Do you think early bitcoin keys from 2008 will never be broken (disregarding tools and being found which is more likely)?

See if you can contain yourself to what topic you wanted to talk about and double down on your take, answer the questions.

That wasn't even the point but let's get this for future generations to giggle at.

> You are already accusing a theoretical cryptography expert of being "biased" against you?

What are you talking about? Cryptographers would be biased to their field, like yourself, about their system being incapable of being broken. It isn't just about breaking algorithms...

However some are even talking we have to start worrying about advancements by 2030-2040

[When a Quantum Computer Is Able to Break Our Encryption, It Won't Be a Secret](https://www.rand.org/blog/2023/09/when-a-quantum-computer-is...)

"One of the most important quantum computing algorithms, known as Shor's algorithm, would allow a large-scale quantum computer to quickly break essentially all of the encryption systems that are currently used to secure internet traffic against interception"

[The NIST has a "Post-Quantum Cryptography" Project](https://csrc.nist.gov/Projects/Post-Quantum-Cryptography)

[Waiting for quantum computing](https://techbeacon.com/security/waiting-quantum-computing-wh...)

"Large universal quantum computers could break several popular public-key cryptography (PKC) systems, such as RSA and Diffie-Hellman, but that will not end encryption and privacy as we know it."

"The most widely used PKC systems, including RSA, Diffie-Hellman, and ECDSA, rely on the intractability of integer factorization and discrete log problems. These problems are hard for classical computers to solve, but easy for quantum computers."

"This means that as soon as a large-scale universal quantum computer is built, you will not be able to rely on the security of any scheme based on these problems."

"To quantify the security of cryptosystems, "bits of security" are used. You can think of this as a function of the number of steps needed to crack a system by the most efficient attack. A system with 112 bits of security would take 2112 steps to crack, which would take the best computers available today billions of years. Algorithms approved by NIST provide at least 112 bits of security."

"AES-128 and RSA-2048 both provide adequate security against classical attacks, but not against quantum attacks. Doubling the AES key length to 256 results in an acceptable 128 bits of security, while increasing the RSA key by more than a factor of 7.5 has little effect against quantum attacks."

"When large-scale universal quantum computers are built, you will still be able to securely use symmetric encryption algorithms, but not the systems like RSA and Diffie-Hellman. These PKC systems are widely used today to create digital signatures or to securely transmit symmetric encryption keys."

"Fortunately, there are several families of quantum-resistant PKC systems: Lattice-based, code-based, hash-based, isogeny-based, and multivariate systems. NIST's Report on Post-Quantum Cryptography describes each of these families."

Encryption will still exist with more compute and new systems but it will evolve. That doesn't mean keys of the past will that aren't updated.

> Additionally every cryptography expert know the system is only as good as the keys not being found,

I like how you cut out that sentence to disregard the context...

The rest is "and that can come from other means not just breaking the algorithm or brute force... it can be how the key was created and what tool was used."

> Actual experts do not say this. Why do you keep repeating this with zero evidence?

Again let's get the full quote not the biased selective clip you made for you context "With time all encryption will be broken, we may be gone by then but maybe something comes along that changes the game. History is filled with leaps that were not expected. The early keys will get weaker and weaker over time, that is fact."

If you have a problem with that statement you have a problem.

I gave examples you brushed off. You can agree to disagree but historically most crypto either is broken or has trapdoors for export even, so you don't need to break the algorithms, you might just need info on the tools. Try using any non approved encryption algorithm for communicating with defense/military, you'll get a visit from the FBI.

> More than anything, I'm fascinated when someone makes an outrageous claim, someone gives them evidence that it is completely false, they give zero evidence that backs it up, yet they dig in, repeat their claim, distract from it and try everything to not just admit they don't actually know what they're saying.

I am fascinated as well when someone entirely disregards the point of the post and tries to tell others they know everything. I even said it might take longer than lifetimes or the universe even to break the algorithms, yet you still can't get past that point. Quite fascinating indeed.

> No, I'm responding to things you said and you keep trying to distract from them instead of admitting there is no evidence for what you said.

No I already alluded to the time situation, it doesn't matter much in the main point of my comment.

The concentration of currency in digital currencies is a problem and makes people that own that leveragable or too powerful.

The longer it takes to find/break the keys the more the value will be worth potentially...

Yes that is my entire point. You just laser focused in on cryptographic algorithms and not all the things around it. The first sentence of my first comment was a bit salacious but a lead in to the dangers of concentration in currency, and the power people have, or want to take, of the early owners.

Yes I do believe cryptographers know that not all tools and keys will stand the test of time, especially keys made in 2008... just as cyber security people know even with the best security there is always dependency holes, social engineering, and tools that can be trojan horses.

The point was, of my comment, not shifting goal posts, the concentration in digital currency is a problem and is an even bigger problem with large swaths of it in keys out there floating around, either found physically or other means.

You seem a bit combative, you are starting in with the selective context clipping so let's just agree to disagree on the rest. You have been successful in completely derailing the main point... if that was your goal, Good job!