All in all I love the ecosystem, it’s very convenient.
So basically no adblock and no customization unless remote server's owner allows it.
nix run --impure 'git+https://codeberg.org/ingenieroariel/arcan?ref=nix-flake-buil...'
Ultimately it appears to be software with more fans than productive users.
> Ultimately it appears to be software with more fans than productive users.
Correct. You can swing productive usage of Durden and the rest of the kit in its current state, but it's still an experimental piece of software under active research and development. As it stands, it's more attractive to daily drive xorg as a default while keeping arcan around to hack on and experiment with.
It's been rapidly closing the gap towards usability over the last few development cycles. I can speak for myself as tentatively waiting for 1.0 before abandoning xorg totally, which is at least a few years away.
I love the idea of arcan, I like how as a counter point to waylands "X went to hard, the display server should be a dynamically linked shared object" there is one solitary guy doing his own thing saying "X did not go hard enough we need an even more seamless, recursive solution to move our display between different devices" and doing amazing work on this problem.
But just like plan9 I have a hard time actually doing anything with it. Achingly beautiful software, but just a little to different and obscure. And I say that as an OpenBSD daily driver, where apparently I thrive on the pain that comes from using an obscure system.
But I am currently back on the plan9 kick, seeing if I can get it to stick this time. I may give arcan another try as well.
The focus of arcan is to make the final display target super flexible.
So X was designed to be network agnostic, the programmer could use the same protocol and depending on how the end user had it configured it could be displaying on the same machine as the program via local shared objects or on a remote machine via tcp. But X never was able to dynamically transition between the two, there was no way for X to move a window from one machine to another. This is a core goal of the arcan project. I think the thing that gets people confused is along the way there is also a lot of adjacent experimentation in really wild window managers and control scripts. That is, what crazy things can you do once you have this amazing window location flexibility.
The overall result gives all powers to server owners, and IMHO is pretty terrible for users. Definitely much worse than current web, UX-wise.
- There is forced, instant auto-update. You don't get to postpone updates, and in fact, there is a system for real-time update of all of the clients.
- There is no inner links by design. It's like being in giant SPA, bookmarks are useless.
- User has zero power of customization (unless author designs a system for it). Adblock? Nope. Increase font size or change to more legible font? Not with A12. Custom userstyles? Not here.
- Oh, and if you want to extract information, there is no convenient HTML representation to parse, or an API to intercept. It's all internal state, driven by server. Maybe start reverse-engineering stuff.
- Special mention for search: it's all under server owner control. Server has to provide index for search engines, and inside page, implement Ctrl-F if they feel like it. There is no way to ensure that the index is up to date, nor that it actually has any relation to site's contents.
- About cookies and privacy: each user gets identity, and it is immediately sent to a server at each connection. That identity is salted so it's different between app, but within app, it's permanent.
I'll give credit to the author, it is very much like BBS. As a user, this makes me appreciate how great the current web is, even with all its downsides.
As a special mention, there are some _weird_ claims in here...
- Apparently "eval()" is disabled, to prevent "‘middleboxes injecting code’ adtech style tampering." I had to read this twice and check the calendar.. it's 2026, the last time middleboxes could inject code was over a decade ago, before https was everywhere.
- The only allowed connections are to originating host ("directory"), and it has to proxy whatever resources it has. It is no longer possible to keep control of HTML and offload large files to CDN - if you want CDN, you go all the way in and surrender all control.
(Author claims this means "request record/replay is trivial for both archival and development purposes.", but unless the script is fully deterministic, any application can easily defeat archival replay by putting a changing number into request and expecting it back. This is, again, 100% inline with author's vision of user having no control)
- Author talks a lot about local-first, and you can bundle media with code in initial downloads. But many examples are of regular remote apps. "image sharing" app which loads images on-demand. A video player which can only stream videos. A complex app which is backed by VNC-like remote desktop connection. None of this is local-first!
Except 'One desktop many devices' and 'your desktop, reaching out' and 'the tools used to browse, are used to host'. The first server in your network is.. yours. So it gives all controls to you. That's IMHO pretty excellent for users. Have your home directory (even if it is just localhost) be proxy, cache and external resolver. Preset for this is included in the next release.
> There is forced, instant auto-update. You don't get to postpone updates, and in fact, there is a system for real-time update of all of the clients.
Not forced, protocol level opt-in, the cli tool as a devtool does that by default because its a devtool. The variant the desktop appl can expose in UI does not. Protocol command to list new applications has a field for 'notify me of updates'.
> There is no inner links by design. It's like being in giant SPA, bookmarks are useless.
The inner links are not included in a textual representation to not repeat the URL degradation of 'arguments encoded in URL but also in cookie and you only share the url'. They are there but controlled to the user, not the application. There is protocol for 'snapshot appl state', 'restore from snapshot'. There is much more to this that was omitted because 6500 words already.
> User has zero power of customization (unless author designs a system for it). Adblock? Nope. Increase font size or change to more legible font? Not with A12. Custom userstyles? Not here.
Fonts, colors-theme, accessibility preferences etc. are all part of the interface between the browser-UI app and the hosted one without any other changes necessary. Engine itself gives available font-set a separate namespace for security. Every single exposed API function is hookable. On that note:
> - Oh, and if you want to extract information, there is no convenient HTML representation to parse, or an API to intercept. It's all internal state, driven by server. Maybe start reverse-engineering stuff.
Instead there is the scene graph of the browser to export as lua, exposed as a script function itself so you can hookscript it. As a trivial one: https://codeberg.org/letoram/arcan/src/branch/master/data/sc...
It reads as 'after n monotonic ticks, create a snapshot of the scenegraph and store.'. These are Lua scripts themselves. This can be triggered by the browser-UI app. Nodes with a text backed origin has the original text, with annotation for extra details or screen-reader accessibility.
> About cookies and privacy: each user gets identity, and it is immediately sent to a server at each connection. That identity is salted so it's different between app, but within app, it's permanent.
The tools for client side key management does key differentiation per directory by default and ephemeral by default. You opt-in explicitly with 'I want a persistent keypair tied to these sets of discovery points referenced by my-petname'.
> Apparently "eval()" is disabled, to prevent "‘middleboxes injecting code’ adtech style tampering." I had to read this twice and check the calendar.. it's 2026, the last time middleboxes could inject code was over a decade ago, before https was everywhere.
Travel more. They are still there. But also, outside of presence in XSS,CSRF,SSRF, ... that are still here, the rest moved to 'SSL removed here :-)' side as per the Snowden leaks. Then they moved to hijacking plugins, npm packages or just shady deals with the site's 888 partners because streaming pornsites need revenue.
> The only allowed connections are to originating host ("directory"), and it has to proxy whatever resources it has. It is no longer possible to keep control of HTML and offload large files to CDN - if you want CDN, you go all the way in and surrender all control.
Which leads into the 'external resolver' part. Large-files retrieved and reference by hash. Resolver mapping that. Swap that out for one that forwards to your CDN or IPFS or your local data-hoarder cache.
> Author talks a lot about local-first, and you can bundle media with code in initial downloads. But many examples are of regular remote apps. "image sharing" app which loads images on-demand. A video player which can only stream videos. A complex app which is backed by VNC-like remote desktop connection. None of this is local-first!
Yet all of the applications currently hosted, including the presentation slides one, are local first and the development workflow is such that you have to say "I want to access networked resources" and the default tooling response is "no".
