@aral consider the following
DAT and IPFS
If you want decentralized applications #HTTP #browsers are simply the wrong tool. All you can do is to disable JS, use the Web for what it was designed (#HyperText distribution) and build a new infrastructure for distributed computing.
@Shamar See my follow-up tweet.
We cannot simply ignore the world’s preeminent delivery platform if we’re trying to build a bridge from it to a peer to peer topology. We must use it but use it properly (without creating a privileged node).
I stand by my comment.
I saw it.
And I'm in no way ignoring "the world's preminent delivery platform": it's so broken that the Russian Government is using it to deliver worldwide (but mainly in country) the undetectable attacks I talked about extensively with #Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1487081#c16
And it's naive to think they are alone.
No, really: I work with JS on a daily basis and even just technically in itself, it's broken beyond repair. Not even through #WASM.
It's time we stop a moment and think how to build distributed operating systems that put people in control. We should stop assuming people are dumb and only care about "users", because not all people use our software and most people are used through software even beyond data collection.
And beware that #Google is pretty aware of this. #Fuchsia is not just an attempt to remove an annoying kernel under #copyleft from its business dependencies. It's not even just an attempt to get rid of annoying #hackers like Linus, that dare to review their code.
It's an attempt to disrupt before being disrupted.
They know this crap is not going to last.
Google want to be in charge of the next Web.
If they succeed we will face a new version of this distopia, a stable one.
@aral while I agree, there are counterexamples (like MailPile)
@aral how does this work with relay servers? I'm assuming this didn't consider self hosted machines
@aral I think one of the few exceptions to this is something like node-webkit.
Effectively the server is bundled with the client as a standalone executable. But at that point, you're starting to leave the sort of ecosystem you're talking about.
Being said, I think there is room in this space to apply the same basic concept with a bit of a twist: "if you your (standalone) web app works without a connection to a 3rd party server..."
@aral Thinking about it, the core to your insight on javasript is how the engine that runs the site is 'in the browser'?
An elaboration on this: been watching stuff around webassembly with the hope that someone implements p2p protocols in that space.
Been hoping Mozilla's dweb thing [https://hacks.mozilla.org/category/dweb/] would bleed over. But so far (afaict) their focus in webasm has been on improving the central server paradigm and it makes me worried.
Hate it or not, the idea of using a centralized server to shoulder the load is one of the things that gives that style a sort of protective moat.
that doesn't pass rule one of logic, sir. hence the reason for RMS's militancy and the LibreJS or gnuzilla. the same reason node and centralized goog corp Js garbage pollutes %99999.99 of all apps especially "decentralized ones". I would argue your statement is illogical , capitán.
@Tlacaelel OK, so again, slowly this time:
1. Web app = delivery + execution
2. Delivery = serving html (& maybe CSS/JS)
3. Execution of app logic can happen on the client, the server, or on both
4. If logic is executed only on the client, you can design your app so that no data is ever sent to the server. The only way to achieve this is to implement all logic in client-side JS.
Thus, if your web app works without JS, it means you’re executing logic on the server and it isn’t decentralised.
According to this reasoning, if you need data from the server the application is centralized anyway.
Which is wrong, as @bob pointed out.
Not only the server architecture might be decentralized and under user control, but if you don't need a server... you don't need a client.
But there I'm concerned about repeatable builds, which I view as vital and the web doesn't provide at all. The server can give you whatever JS it wants, defeating the E2E encryption. With whatever attacks it wants.
@bob @Tlacaelel Indeed. Like Freedombone ;) But even then, only because you have physical control of it. If your always-on node is to be hosted by a third party, I would limit its functionality solely to the replication of public and/or end-to-end encrypted data and without ever having the secret key. So the always-on node, in contrast to privileged servers on the Web, must be less privileged than nodes you control. At least that’s how I’m designing #Hypha.
@bhaugen I have to decide to give SSB a try. Its coupling with NodeJS is what keep me off. But I guess it deserve a chance anyway.
@aral the bridge methaphor doesn't work well here.
Even if you manage to build the least exploitative and most inclusive walled garden with #Hypha (which I totally hope you will, really), most people there will still be second class citizens.
Like it or not, programmers like me and you will hold most power. We will still be a cast of elected.
The ONLY way to #free people is #education: on one hand we have to build systems that are easy to #hack (aka simple), on the other we must educate people to hack, to be curious, to challenge our assumptions, to break things, to try anyway, to play.
Give people tools that are simpler to hack than to use.
yeah that makes sense... but centralisation isn't bad per se. I was thinking about static pages with zero to minor Js for navigation vs corporate CDN Google WordPress "apps". I'm all about helping create fault tolerant decentralised networks. thanks for the reply, kind sir
@aral I'm curious to hear your opinion on brutaldon then.
@hankg Possibly yes. Actually I see two reasons why people change that: (a) Supporting multiple platforms (Windows, Linux, Mac) is a pain in a non-web world; a lot of people these days use #electron for that which doesn't seem much better. And (b) If you have an application that requires communication or collaboration features (shared editors, calendars, messaging, ...), having apps that run locally add complexity by potentially having different versions of the same code, some very ...
I think a large part of the problems with web and electron apps are because want cross-platform apps.
But why do we want that?
Why do we insist that every member of a group of communicating people uses the same version of the same app?
Why do we want one app's UX to be consistent across platforms instead of all apps' UX being consistent across one user's computer?
Why is "app" even a thing?
@Wolf480pl Because we have limited resources (which makes building various native applications for different systems difficult) and because XMPP: A lot of features need to be supported by both servers and clients. Still I can't reliably send files to both of my XMPP contacts, in example. That just makes things complex and worse from a usability view.
@aral progressive web apps can do this. They have Offline functionality.
@1337core I know :)
@aral Brython. Though I'd like to see a generic (maybe webasm based) in-browser VM so that we can get rid of the abomination that is JS.
@aral how about an oldschool noJS mastodon UI? Would that qualify mastodon as centralized?
This is my personal Mastodon.