Isn't it technically possible to split browser functions so we can recombine as we like? - i.e. separating the rendering / js engine from everything around the side - managing all the tabs, bookmarks, cookies and passwords, workspaces and sessions, mail, notes etc.
In my case, I like the workspace structure provided by Vivaldi, but don't see why it has to be built on chromium browser.
Anyway as a developer I need to test against blink, webkit and gecko, so would be nice to swap them within the same user interface structure.
By the way, I develop a "javascript-heavy" web-app (interactive climate model) and it seems to be working fine, and fast, in firefox, so I'm not convinced by complaints in the article.
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) ?
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 ]
Yeah, but you just gave me an idea too, how about AI-directed canines? "apple-intelligence" applied to follow-your-nose. My dog loves to chase small spots of light, which might be a trick to steer them.
As a global company, Apple could just re-establish itself in europe, e.g. Ireland, and continue trading with China, they can just put the US on hold for a couple of years.
Meanwhile for those who really addicted to istuff, coyotes can smuggle iphones across the border, so maybe this solves the fentanyl 'issue'.
In principle I'd like to see specific permissions - so for example playing with gui enhancements should be a lower trust barrier than adjusting and running code, but afaik (correct me if wrong) neither js nor rust have a built-in security architecture that could implement this. Maybe certain types of extensions could just be custom script language without filesystem access, but that's harder to do.
About source code linking, last time I heard (maybe they fixed it?) it seemed that trick vscode extensions can link to arbitrary (safe-looking) source repos, which didn't actually produce the extension.
I'm less convinced about slowly accumulating publisher trust, as this could be a barrier to honest new contributors, while big actors with a longterm profit or geopolitical motive could game such a system anyway (as they do for social media).
I do trust the scala tools (build Mill, lang-server Metals, compiler) which adjust my code, having seen them evolve over many years.
and like the separation of functions (lang-server / editor), so we are less dependent on any one big-tech solution.
So I suppose a fundamental issue is what to trust less - big corps with a reputation but lock-in power, or an ecosystem of small contributors which might include tricksters. No perfect balance.
It seems so far Zed is cautious, providing api only for specific extensions - i.e. language servers and gui themes.
add a line ... right before you run it
I run stuff from the command line using a trusted build tool (Mill, in scala), or via a local server (where js is sandboxed).
But indeed, a tricky language server or AI tool (I don't use yet) might inject code where I don't inspect before running it.
That's a risk even with java-based IDEs - java has security permissions, not in js (vscode) or rust (zed), but are they applied...?
As for audits, a problem with vscode is the marketplace got too big, so many extensions, many lookalikes, nobody can check them all...
Such tricks were was predictable, as VSCode extensions, letting arbitrary JS run on your system, are an obvious security risk.
Recently I used Zed editor instead, it's smooth, but this also has extensions, only these are fewer and in rust ( maybe a higher barrier, targeting less users, so far... ). What's the solution here - is there some intrinsically safer sandboxed system ?
I'd like to have no phone at all, I don't like small screens, nor being interrupted.
Problem is that phone apps are now almost obligatory for IDs, transport tickets, passes, banking, etc.
So I'd just like a phone-receiver (modem) with a sim card on a USB stick that can enable phone-app-stuff via my laptop or tablet.
(Yes some tablets have data sim cards, but we still need sms and occasional phone functions for 'verification' etc.).
Any suggestions?
I'm more interested in distribution of users and local-focus of communities than country-based instances, nevertheless the map does illustrate that Lemmy has huge gaps - no country instance in all of Africa, hardly any in Asia... What can we do to make it a more global conversation ?
Isn't it technically possible to split browser functions so we can recombine as we like? - i.e. separating the rendering / js engine from everything around the side - managing all the tabs, bookmarks, cookies and passwords, workspaces and sessions, mail, notes etc. In my case, I like the workspace structure provided by Vivaldi, but don't see why it has to be built on chromium browser. Anyway as a developer I need to test against blink, webkit and gecko, so would be nice to swap them within the same user interface structure.
By the way, I develop a "javascript-heavy" web-app (interactive climate model) and it seems to be working fine, and fast, in firefox, so I'm not convinced by complaints in the article.