Follow

Centralised web wisdom: if your web app doesn’t work without JavaScript, it is broken.

Peer web wisdom: If your web app works without JavaScript, it is not decentralised.

JavaScript isn’t the enemy; servers are.

(Read this as many times as necessary for it to really sink in as it’s literally the opposite of what folks, myself included, popularised on the centralised web for nearly two decades. If your app works without JavaScript, it means you have logic on a centralised server somewhere.)

(Of course, just because your app doesn’t work without JavaScript in no way means that it is decentralised. 99.99999% of them aren’t. The observation is that if it does work without JavaScript, you can be sure that it isn’t decentralised as there’s a privileged centralised node – server – somewhere.)

@aral @espectalll This seems like a good idea provided that it doesn't have much effect on browser performance.

@aral

No.

#JavaScript on the browser doesn't grant any decentralization. #Google use tons of client side #JS.

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.

@aral

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: bugzilla.mozilla.org/show_bug.

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.

@aral

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.

Even just if you consider permission systems, UI innovation, self hosting and software composability, you can easily see how the #web browsers and JavaScript are not going to free anybody.

@aral

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.

@Shamar @aral If they eventually ship Fuchsia (perhaps this year) then it will be "source available" but its development direction will be decided by Google. They will control what patches are accepted, rather than some pesky GPL hacker. They won't need to be involved in the Linux Foundation or its corporate politics. They can optimize the kernel to work with their cloud storage, ad delivery and telemetry - things which would never get past the scrutiny of Linus.

Initially it might improve the mobile situation where phones get stuck on a particular kernel version and the manufacturer has zero motivation to maintain or upgrade it. The current situation on mobile with Linux is definitely less than ideal.

@aral I would say that this take is too hot unless you also specify that the JavaScript code needs to be stored locally.

@anathem @aral storing js code locally (and updating periodically) is a good idea if you want to reduce you data footprint.

@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 youre close but still wrong: we shouldnt be using http+html+js for developing decentralised applications
@aral uuh, JS or not doesn’t really matter, decentralisation is about everything not just the client, specially as the client doesn’t hold the data.

@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 [hacks.mozilla.org/category/dwe] would bleed over. But so far (afaict) their focus in webasm has been on improving the central server paradigm and it makes me worried.

@aral I say this because one of the accessibility issues, in terms of JavaScript in the browser, is the performance.

Being able to run webassembly in the peer web style: may allow for in-browser engines while also avoiding the performance issues involved with running heavyweight JavaScript.

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.

@aral
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.

@aral @Tlacaelel Unless the server itself is decentralized and something you can control.

@Tlacaelel @aral

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.

Please repent! :-)
Not by accident those who control browsers and #JavaScript are kings of #centralization!
It's dev lock-in through incompetence.

@Shamar @Tlacaelel @aral @bob I can understand the argument having people run JavaScript apps on the web can be preferable in a software-freedom sense to them running propriatary native apps on Mac and Windows.

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.

@Shamar @Tlacaelel @aral @bob Certainly the ideal would be to get everyone using libre apps on libre operating systems!

@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 .

@aral @Tlacaelel Right. And maybe I should also make this clearer in the documentation. Freedombone is designed for a threat model where the server is located at your place of residence. If it's run within a data center then this could be quite risky, and isn't recommended.

@Shamar @bob @Tlacaelel If I don’t, we don’t end up building a bridge. Even if we end up building the world’s most amazing wonderland, we do so on an island that only Olympic swimmers can get to.

@aral @Shamar @bob @Tlacaelel

In the future, every phone will have its own server.
manyver.se/ is a proof of concept, at least.

@bob @Tlacaelel

@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.

1/

@Shamar
> I have to decide to give SSB a try. Its coupling with NodeJS is what keep me off.

Some new implementations of SSB in Go and Rust are work-in-process. If I see one of those take off, I will be sure to announce it in the fediverse.

@bob @Tlacaelel @aral

@bhaugen @bob @Tlacaelel @aral

Any link to share?
A work in progress won't scare me... 😉

@aral

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.

Basically, the opposite of "don't make me think" #UI philosophy.
The antidote to #SurveillanceCapitalism is to make people #think.
To train critical thinking.

Give people tools that are simpler to hack than to use.

@bob
@Tlacaelel @bhaugen

@Shamar @bob @Tlacaelel @bhaugen Make people think, sure, but don’t disrespect the limited time and energy they have in their lives. The two aren’t mutually exclusive.

vimeo.com/70030549

breakingthin.gs/this-is-all-th

@bhaugen @aral @Shamar @bob @Tlacaelel

I was thinking this reminded me of SSB (Scuttlebutt) and sure enough, they use that protocol...

@bhaugen @Shamar @bob @Tlacaelel SSB and DAT are very close. But the latter is closer to my vision so I’ve chosen to go with that.

@aral
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.

@c0debabe @aral never heard of Brutaldon but that looks like an interesting UX approach :)

@c0debabe @aral If I understand correctly, brutaldon presents a JavaScript-free interface to any Mastodon-compatible instances?

If the brutaldon frontend is hosted by someone other than the user or the organization running the instance, using it increases centralization, diffuses information and reduces security.

@aral I have no strong aversion to using JavaScript or not using JavaScript. However this brought me to an interesting question. If we are essentially writing full fledged apps that run in the browser should we be thinking of going back to traditional apps that run locally instead?

@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 ...

@aral

@z428 @hankg @aral

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.
@hankg @aral

@hankg ...likely to be extremely outdated, run on the same system. It can be resolved, as everything, but it's not necessarily easy or nice. That's why, in example, I see a lot of people choosing Slack over XMPP.

@aral

@aral progressive web apps can do this. They have Offline functionality.

@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?

Sign in to participate in the conversation
Aral’s Mastodon

This is my personal Mastodon.