Ben Matthews

Well problem with any Lemmy community as such a forum, is that current usage (not necessarily intrinsic to the software) is so ephemeral. So it’s good for discussing breaking news, but not to gradually accumulate discussion of solutions to complex problems, over years. I wish this were not the case, but doubt anybody will even notice this comment, as no longer ‘hot’, and folded away … Rather, a few weeks later the same topic will be reopened under a different post, and we start over again.

I agree with most of what you say. I’m a long-time fan of calculating more complex things client side, as you can see from my climate model (currently all calcs within web browser, evolved from java applet to scalajs).
Also, in regarding social media, keeping the data client side could make the network more resilient in autocratic countries (many), and thelp this become truly a global alternative.
On the other hand, some ‘trunk’ server interactions could also doing more not less, bundling many ‘activity’ messages together for efficiency - especially to reduce the duplication of meta-info headers in clunky json, and work of authentification-checking (which I suppose has to happen to propagate every upvote in Lemmy?).

Thanks, that makes sense if I think about it, but maybe users shouldn’t have to - i.e. the Mdon part-conversation way still seems confusing to me (despite being a climate modeler and scala dev), although haven’t used Mdon much since I found Lemmy. And I still feel that both ways seem intrinsically inefficient - for different reasons - if we intend to scale up the global numbers (relating OP).

That makes sense, to store only popular stuff, or temporarily - especially for ‘heavier’ images (although as we see with lemm.ee, that leads to issues when an instance dies). Yet I also wonder about the scalability of just the minimum meta-info, whose size does depend on the protocol design.
For example with Lemmy every upvote click propagates across the network (if i understand correctly, mastodon doesn’t propagate ‘likes’ so consistently, presumably for efficiency, but this can make it seem ‘empty’). Maybe such meta-info could be batched, or gathered by a smaller set of ‘node’ instances, from which others pick up periodically - some tree to disperse information rather than directly each instance to each other instance ?
As the fediverse grows, gathering past meta-info might also become a barrier to new entrant instances ?

I don’t think the general architecture scales that well (think of all the duplicate storage …

That’s my hunch too, although haven’t studied in detail - so I wonder how we can fix it ?
Is there an forum that discusses this scaling issue (in general, across fediverse) ?

Since much (so-called) “AI” basic training data depends on Wikipedia, wouldn’t this create a feedback loop that could quickly degenerate ?

Oh, it’s designed for a big desktop screen, although it just happens to work on mobile devices too - their compute power is enough, but to understand the interactions of complex systems, we need space.

Indeed, here’s an example - my climate-system model web-app, written in scala running (mainly) in wasm
(note: that was compiled with scala-js 1.17, they say latest 1.19 does wasm faster, I didn’t yet compare).
[ Edit: note wasm variant only works with most recent browsers, maybe with experimental options set - if not try without ?wasm ]