ezst

> But why wouldn't it be possible to have these two in the same app

I don't believe it's "impossible" to have both in a same app, it's just that the kind of high-density UI and advanced features you depend upon for high-volume chats rarely intersect with family-scale/1-to-one chats, so you either make compromises that directly affect usability/efficiency, or you essentially end-up with 2 chat paradigms at odds in a same client.

> As to whether one protocol can address both use cases: Maybe it doesn't need to either?

It depends what you mean by protocol in this case. Chat rooms (MUCs in the XMPP verbiage) are handled by a specific component, so it's practically happening the way you describe, but at its core, the "message-passing" (stanza-based) nature of the XMPP protocol doesn't change.

> Matrix is a much better conceptual fit for the IRC/Slack-like use case

Debatable, this mostly boils down to the client design choices and priorities, and has little to nothing to do with the protocol. Someone came-up with a metaphor I like to illustrate it: the banquet and the barbecue¹. XMPP has "barbecue"-style clients like Conversations, Kaidan, Dino?, and other that are rather "banquet"-style like Gajim, Fluux, Movim, …

I personally use Conversations on the go and Gajim otherwise. I also happen to have interfaced all my "high-volume/many-participants" IRC chans from back in the days with the biboumi² gateway, so they appear to my XMPP clients as native XMPP groupchats, and the experience was great-enough for me to ultimately drop weechat a decade or so ago and have all my "banquet"-style chans under one XMPP roof.

> between mixed extension support at the client and server side, with XMPP you can never really know if you're getting "plain old Jabber" or something more like Matrix in terms of user experience.

From over a decade of using XMPP daily, this concern is more of philosophical nature than anything. The vast majority of the people you'll reach over XMPP use a decently modern and maintained client that will "just work". Worst case, they will still be getting your messages and the meaning across, because the "message passing" core of XMPP was defined 25-odds years ago and hasn't changed.

The real "risk" for XMPP would be to have a large number of users stuck on an unmaintained client, and users staying behind for years while the ecosystem moves on. We had a bit of that with pidgin 8-or-so years ago. The worse that happens is that you can't use the latest E2EE scheme with them, or that attachments are slower to arrive, this sort of things. That's IMO not bad for a 25 years old protocol that's truly decentralized.

¹: https://blogs.gnome.org/tbernard/2018/05/16/banquets-and-bar...

²: https://codeberg.org/poezio/biboumi/

Probably, and also from the fact that although there's a plethora of matrix clients and servers on paper, none is as feature complete (or feature-complete to the point of usefulness, I might say) as "the one". XMPP has about one decent-to-great client per platform and multiple fully compatible and interoperable server implementations, and every single one of them is by different groups.

What server was that? I got into the XMPP self hosting game in 2014, even then, ejabberd was one of the most "fire and forget" piece of server software I was running. It takes some ports opening and some DNS SRV records to be set and you are good to go with all chat, calls and social features.

You can mediate friends requests by having servers generate an invite link, you can generate QR codes your friend can scan on a side channel, ... There are ways

That's not answering my question, what precisely do LLM enable in ways of educating children that hasn't been thoroughly studied before? What role do you want to give chatbots in the complex framework of child brain development? How do you back it up?

What a weird, unhinged take. Android is mostly written in C, Android apps are AOT/JIT compiled when written in Java, and the NDK lets you write/port from whatever native you have, which is how you get Chrome to run on it to begin with.

Indeed, it won't: I can link a conversation with XYZ-bot that tells me that I'm handsome and my ideas are brilliant and I'm en route to tremendous success. The point is that LLMs are, by design and current models norms, sycophantic and incapable of describing their own knowledge and workings/processes. This is not a matter of "my opinion vs yours", that's what few minutes spent legitimately trying to understand how this works will tell you.

I had the privilege of being educated in several countries and cultures. This might come across as "your education system sucks", and that's essentially what it boils down to, but on the upside I'm truly sorry for you and will oppose a comment to your cynicism. Good exams test your ability to express coherent thoughts about the concepts you learned, and let you generalize upon them by having you use and combine them to solve cases and problems that were not those seen in the teaching material. You can even teach and test history that way, and make it much more insightful and captivating than a laundry list of dates and events (as I suppose was your case?)

Which was pretty much the whole damn premise of needing a teacher to begin with. What a surprise!

> As the nature of assistive tools changes

I mean, does it? The way I see it, the best LLMs have to offer is infinite patience (until they inevitably and unpredictably start to confabulate, which should be a gigantic red flag, anyhow), I don't see how LLMs can be used to explore teaching paradigms that haven't been explored before. We know pretty well from centuries of empirical experimentation how children's brains develop under different stimuli. It's not exactly something the software industry needed to "hack".

Although obvious, I think it's worth stating that this method mostly (only?) makes sense for higher education, where students are conscious, involved and engaged in their curriculum.

Could it be that you vastly overgeneralize? While there's no perfect education system, many are much better than the nightmare you describe.

You can probably keep this kind of unconstructive comments to yourself. Even if this was a place to discuss one's beliefs, nobody was attacking yours to begin with.

there might be several gaps before that, even. From the top of my head:

- text description to 3D geometry gap: you can't easily describe complex geometry in a language that's common and convenient to both humans and machines

- 3D geometry to physical model gap: material , geometrical constraints induced by manufacturing (machines, tools, costs, …)

- physical model to model fit for simulation gap: meshing, constraints, stress modelling, …

- simulation outcome to fitness assessment gap: now you have a high-dimensional and numerically heavy simulation to weigh against a non-rigorously defined acceptance criteria

- simulation outcome to geometry profiling gap: how do you even start to guide the LLM into the vast space of possible changes to apply to the 3D geometry and reboot that loop?

LLMs don't strike me as a particularly relevant technique to apply here, to be honest.

Are you familiar with the problem space at all?

> Claude has been trained on high school physics textbooks, yo

The very fact that physics textbooks have little bearing in the real world is the whole damn reason why Mechanical Engineering exists as a separate discipline, yo

> It’s a problem of the human setting up the description of the problem in such a way that the model can operate.

It's a problem of defining the initial state (which is the trivial part that OpenSCAD may be a contributing element of), defining constraints and variables (what is allowed to be changed and not, for what can, in which ways, to what extent, i.e. what is the library of allowed material, fastening, machining, assembling techniques available to your very specific situation), defining evaluation and fitting criteria.

I see very little adequacy of general purpose LLMs in that

> the same way that ML has been used to produce optimal rocket engine nozzles and fuel transfer systems.

Which has nothing to do with "just use Claude, yo"

And then do what? Do you have any evidence that Claud would do anything relevant with those?

A LLM may produce OpenSCAD compliant syntax, I don't doubt that, but how do you make it produce designs that fit engineering constraints? How do you even express those to a LLM? How do you validate those? How do you iterate upon them?

The domain of ML-driven design optimization isn't exactly new, is quite specific, and I would need convincing that Claude has anything to contribute to it.

How would you even get Claude involved in that? This isn't your git repo that a language model can scrape for textual content.

Not OP, but LLMs didn't exactly invent the kind of content that's not worthy of your time, they merely turned it into a commodity (and made everyone have to work much harder figuring which is which).

This thread made me curious about remarkable, what would you say is a good summary or entry point to the whole remarkable hacking scene?

Following the handwritten comments brought me there, which I found to be HN-worthy: https://mzucker.github.io/2016/09/20/noteshrink.html

Also, as a sign of our times, it hyperlinks to what might have been a Microsoft tech page/knowledge base in the past, now completely replaced by poor taste LLM advertising slop. Good work, Microsoft.

Matrix attitude towards IRC (and bridge implementation) always felt like a trojan horse. Yes, it brought undeniable quality of life improvements over IRC for those who took the bait, but that didn't have to mean making the native IRC experience more miserable for no good reason. Matrix burnt a bunch of bridges with that attitude.

I would also challenge OP on the relevance of E2EE for very large MUCs: beyond a certain point, the room can't reasonably be considered private. With current (Signal-style, also found in XMPP, Matrix, …) crypto, you are encoding ever message for every user/client joined, which scales as poorly as one can guess, but is still adequate for small groupchats.

MLS stands to rise that threshold (and there's work in progress to include it in XMPP), but that certainly won't address the fact that this is just privacy theater.

and to add to that, XMPP has extremely simple and familiar "WhatsApp"-like clients, so there's really not much of a barrier to entry. Especially if you join by a user sending you an easy-invite link (XEP-0401). All you have to do is pick a username and you are good to go.

Core matrix is still an insanely complex and clunky protocol that's still struggling to stabilize and scale after more than a decade. That's not on spaces , threads or video-chats (which are mostly client-side features).

Doesn't XMPP check all those, and more? I run my local _ejabberd_ for a decade and some, and I'm joined to a couple 100+-users rooms. On my phone, I have a whatsapp-like experience with _Conversations_, that even the least tech-savvy in my circles use happily. On the laptop, I have _Gajim_, which is more "banquet-style" and serves to follow along fast-paced large rooms, most of which happen to be on IRC, but I don't even mind that, thanks to the _biboumi_ bridge which unceremoniously connects me there as if I was a regular IRC client. I also keep an eye on _movim_ which promises a more discord-like experience: it has gamers-style voice/video/screen-sharing rooms, it has spaces (although the paint isn't completely dry on those), and it's working on scaling-up calls to very large rooms by having galene as a SFU.

What I find also amazing in all this is that all the client/server/bridge names I brought up are independent and healthy projects. XMPP is very mature and decentralized. Not just in theory by nature of its protocol, but practically/politically by its many implementations across many stacks and implementers across many countries.

Because the tools are somewhat comparable, you seem to have been tricked into conflating "protectionism" (which has some stabilising virtues, especially in the area of agriculture, arms, heavy industries, resources extraction) and "dumping" (which is an aggressive act). There is also something to be said about the scale of it. And of the validity of a world view where "every trick is allowed, everything is for grabs, and let the biggest be the winner, and the winner take it all".

> Ultimately a win for the consumer, China does not tend to ban technology as a weapon

Doesn't have to, China will just subsidize their businesses, sometimes at a substantial loss, for as long as it takes to bankrupt the international competitors. So yeah, if by that you mean "they end up unemployed and in overall economic pain, but for a short time some stuff was abnormally cheap" then yes, "it's a win for the consumers"

I'm more than aware that my comment won't move the needle on the AI debate a slight bit, but I do think that the readership deserves some honesty and transparency there. No, not a single LLM ever has "deployed SQLite in Production", had to be on duty during the weekend, had to pop open a terminal to a misbehaving service while on family vacation, nor meaningfully suffer the anguish and stress to hotfix a botched or misconfigured deployment. Only humans have. What makes or breaks a software product, costs you your holiday, and perhaps even your job, probably won't be found in some generic piece of common knowledge rehashed and repackaged with some stylistic tweaks. It's the fine details, the one-off things, those weird edge-cases and compounded factors that in hindsights were obvious but had to be learned the hard way, and hopefully, shared by benevolent contributors.

That's the whole reason why many here put the effort to read/post articles and argue over comments: so there's something non-obvious to be learned. LLMs are effectively "knowledge averagers". They will put together a pretty article that's not worth reading, except maybe if the problem space is completely new to you. And that's the kind of disclaimer I would hope to see ahead of anything LLM-produced, and particularly on this website.