208 karma · joined May 28, 2016
It is forever backwards compatible. API levels is for the rare few cases where we need to deprecate or break something on the engine side but can apply a runtime fix-up script to replicate the behaviour on the scripting level.
Decode/Encode/Network/Terminal is user-relevant insofar as the set of those are interchangeable binaries. If you want more or less (paranoia, legal environment restrictions) media format support, export or streaming capabilities, etc. those can be swapped out per site without any changes to the engine. What is being considered is to be explicit about expected formats in the manifest so that incompatibilities can be detected.
SHMIF is user relevant insofar as "wasm or low-level compiled code" running as local software can be embedded and controlled by the app, allow-listed by the user.
> No third-party storage, and maybe first-party is optional too (not sure what's the plat for this.. user prompt? explicit action?)
Can you clarify what you mean by this?
Failing to do so, that ticking clock, the tell-tale heart, means the engaging article will be an obit called 'Bowing Out'.
> User comes to an artistic website whose author thinks purple on red is a great color schema.
The outer app used as your desktop/browser-UI has two mechanisms at its disposal. The first is collaborative - it can convey the preferred colour-scheme so the 'page' you are browsing to can pick accordingly. That's actually how the terminal emulator and non-terminal shell both gets their colour schemes.
The other is enforced - just as tone mapping is needed on the composition level to deal with HDR, you can use the same facility to apply colour grading per 'page'. That's what I do to chrome right now without it knowing. If the average luminosity exceeds a threshold, it picks a colour map that enforces a dark mode regardless of what the browser wants. Similarly, if a game doesn't respond to resize requests but continues to provide a low 256x240 like output I apply an NTSC signal degradation shader pass into a CRT simulation one. By having it as a composition effect means that I can have my own view of colours, but if I 'share desktop' to someone else the original form is retained.
> - User opens the very newest website, which uses all the latest website standards, including new video codec, new font and new text rendering effect. (In regular web, this would only happen once most clients update to the very latest version of the browser, and telemetry says enough clients have updated)
It's similar to Android API_LEVELS. API breaks (we've had, I think two, since 2013) have been handled with a hook script that exposes the old behaviour. New video codec deployment is a bit special and there's a protocol level degradation path for that with a few nuances. It has mainly been used for hardware accelerated web cameras as a remote data source where it starts with direct pass-through of whatever streams it provides. If the client fails to decode (stream-cancel:reason=codec failure) it signals that and the source end reverts to a safer default from a hierarchy (h264 into zstd).
> In current web, I'd use "reader mode", or a custom UserScript if I plan to go to website often. What happens in Arcan - is this up to the "decode client"? What if the site author chose a "decode client" which has no such functionality?
Decode can be used for that but it is overkill. The hook-script facility (arcan -Hmyscript1.lua -Hmyscript2.lua myapp) can interpose every function the app has access to transparently. Reroute patterns like "load_image_asynch("something.jpg") into null_surface() there. These and other options like the set of encode/decode/permitted integration with allow-list of local software can* be preset per authentication key.
There is a PoC 'more than adblock' that uses an LLMed version of 'decode' in my bin of experiments. The first part is a hookscript that routes all image loading through a version of decode with a local classifier model asked to 'describe the contents of this image and tell me if it looks like an advertisment'. If not the default path applies. If yes it substitutes an image of puppies playing tug of war with a rubber chicken.
* code being written as we speak.
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".
For a handful of reasons (abusive and hostile actors being at the top) we focus elsewhere (https://www.divergent-desktop.org/blog/2026/01/26/a12web/ and https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-e...).
AR/VR development in this space is a massive timesink for all the wrong reasons. Hardware vendors absolutely suck here. Everyone is openly or quietly dreaming of the vertically integrated 'app-store tax' being their real source of revenue rather than selling devices.
This means that if you don't want to fuzz around with half-baked proprietary SDKs that break more often than they do what they're supposed to, you get to sit around reverse engineering. As fun as that can be, it's much less so when that is not what you set out to be doing. Half my electronics 'donation boards bin' is discarded HMDs and input devices by now.
Even in the quirky missed opportunities like Tilt5 you have this situation.
The fabric under attack was the bastard display server protocol itself and not the parts that tie in with the strong points of Powershell, i.e. shell UI design or data exchange format specifics.
This story was continued in a post from yesterday that fizzled, https://arcan-fe.com/2021/04/12/introducing-pipeworld/#pipel...
The way the disconnect happens is interesting though, I am not certain enough about the threaded-IO implementation in regards to hotplug but a quick glance looks like if a hotplug occurs at the same time a client is disconnected the sparse allocation requirement of open() could get an input device confused as a client as it is cleaned up. The odds of that happening though :D
In the wayland code it looks like they tried to have a buffer strategy at some point, but then got too clever for their own good (epoll designs + asynch-OO projected over C is... yeah) and somewhere in 'closure/write/buffering to lower #syscalls/callbacks' landed in a long chain of error propagation and immediate kill.
The best way I found (hence using it) is to have memory mapped ring buffers and just have an atomic head-tail indicator. This makes file-descriptor transfers (DuplicateHandle from win32 fame is just so much prettier) messier, but it means that you can have a recovery strategy and see the backpressure buildup and rate-limit. Since it is mostly input events or 'drag-resize' (and those can be merged) in that direction, silently dropping them and have mouse cursor 'jank' is better than losing your work. If all else fails, the watchdog handle is pulled and the client is set to migrate to a fallback server (if set).
https://gitlab.freedesktop.org/wayland/wayland/-/issues/159
I have probably chased ghosts deep inside GTK from this one alone for multiple full time weeks, to no avail. There will eventually appear a rather harsh teardown post of some of the major mistakes in the implementation (and that alone, no xml business), wayland-server might not improve, but future designers should be able to stumble upon it.
I think to get further with the discussion we need a sort of list of what mechanisms we consider mechanisms, and how policies project over them. Not to be disrespectful, but my budget for engagement is thin, pandemics, sorry :-/
The politics stuff - so I have some logs that precedes the formation that are quite incendiary and outright vile, but there is enough shit flinging to suffice to stop at there being good reason why I wouldn't consider getting closer than bayonet range, and why the post was obtuse enough to discourage most #metoo and discard me as an idiot who knows nothing. The tech stuff matters though and that's only what I want to see. A protocol and not marriage as if from 'the war of the roses'(1989).
There is a fourth option that might materialise, but that's for then.
https://github.com/wayland-project/wayland-protocols/blob/ma...
Is what I mean with political process. Patching the compositor is the wrong side of the equation, it doesn't work with networked clients and it's the client that needs most of the features. It's the client that needs to have a more expressive surface to work with. You can do these things safely and securely without the overbearing constraints and complexity of the policies that we are practically stuck with. See the trayicon/stream-deck articles.
> I'm aware that Arcan got wayland support recently and that actually gives me more hope that we're not headed towards an apocalypse of protocol incompatibilities.
I don't know if 4 years is recently in that span (see the dating my X post), but Xwayland support was initially decided as off limits. That was added recently because, as it turns out, those clients are still the ones that behave the most predictably and are the most robust. Even for applications that should handle both and I need to choose explicitly (arcan-wayland -exec-x11 the_thing or arcan-wayland -exec the_thing) I really only use the x11 side. Even for gtk and Qt. That's the real tragedy.
I would say the babel-split is practically here because of all the sidebands and ad-hoc protocols that have been introduced specifically as a reaction to the strictness and limitations of the initial designs and the poor underlying primitives (as in the wire format and its de facto implementation).
I am not saying that the ones that X have are great or even that good to begin with. A better set could have likely avoided the ICCCM etc. but you can do a lot with just reparent+position - WMs are mostly normal clients after all.
Compare that to say the practically obligatory 'xdg_wm_base' specification, you are much more locked down, and the objects to work with are strongly interconnected. If you want to work around that as a 3rd party developer it's a political process + waiting for n*m compositors and toolkits to adapt.
People tend to miss that Arcan is a Wayland compositor as well, but those clients gets a special path where the WM has to follow extra sets of rules because of it.
I see it as a gradient. Neither is entirely Green (Mechanism) or Red (Policy) but if you look at the sets of both sides and position, I doubt you'll assign the same colors.
Windows exposes lots of WM mechanisms to a developer, hence why something like vrdesktop.net could be built in the first place, or previous WMs like LiteStep for that matter.
It is also why WINE does not, and cannot, have a working Wayland backend while sticking to the protocol. The same is true for X, but there XWayland requires the compositor developer to implement a sideband window manager to hack around the entire Wayland protocol to get X clients to work.
Arcan has had its own fork of Xorg for many years, as well as a Wayland implementation. Nothing here will change that trajectory.
The library mentioned is about ~2kloc, decoupled from the rest of the project (100+kloc) and the relevant subset has not changed significantly for several years.
1. free (bsd) implementation
2. all the remote use cases of x11, rdp(vnc), ssh (not as a suisse army knife netcat with encryption, the interactive thing for text clients), spice, rdp (not usb/printer), ...
3. at about ~300LoC pre-auth attack surface and less than 4000loc implementation, sandboxable down to read/write syscalls
4. preserves original type (passthrough rather than recompression, native formats for vector content, ...) and identity (tray icon with a popup child, ...)
5. compression/packing based on content type
6. covers both audio/video/exotic input devices (accessibility, games, ...) and (soon) 3d/vr
That can runtime 'jump'/redirect (nearly) seamlessly between devices and change the look and feel to match that of the viewer with special provisions for VM like metadata (clipboard) and input bindings.
The first bit is that practically all that is argued in for here, is in Android - and has been so for a long time (~2013 last I worked on the topic in that context) and it is still not enough - they will go (and are going) higher refresh rate.
Even at the time there were crazy things like tuning CPU governor to wake up when touch screen detects incoming 'presence'(before you can get an accurate measurement of where and how hard the finger hit) - it's not like you are going to change your muscle intention mid flight. Input events were specifically tagged so that the memory would be re-used rather than GCed and reallocated.
A sunny frame could go from motion to photon in 30ms. Then something happens and the next takes 110ms. That something is often garbage collectors and other runtime systems that think it is safe to do things as there is no shared systemic synchronization mechanism around for these things.
The second is that this is -ultimately- a systemic issue and the judge, jury and executioner is the user's own perception. That's what you are optimising for. Treating it as a graphics only thing is not putting the finger on something, it is picking your nose. The input needs to be in on it, audio needs to be in on it, and the producer needs to be cooperative. Incidentally, the guitar hero style games and anything VR are good qualitative evaluation targets but with brinelling like incremental loads.
(Larger scale) 1. communicate deadlines to client so the renderer can judge if it is even worth doing anything. 2. communicate presentation time to client so animations and video frames arrive at the right time. 3. have a compositor scheduler than will optimize for throughput, latency, minimizing jitter or energy consumption. 4. inform the scheduler about the task that is in focus, and bias client unlock and event routing to distinguish between input focus and the thundering herd. 5. type annotate client resources so the scheduler knows what they are for. 6. coalesce / resample input and resize events. 7. align client audio buffers to video buffers. 8. clients with state store/restore capabilities can rollback, inject and fastforward (http://filthypants.blogspot.com/2016/03/using-rollback-to-hi...)
There is a bunch of more eccentric big stuff after that as well as the well known quality of life improvements (beyond the obvious gamedev lessons like don't just malloc in your renderloop and minimize the amount of syscall jitter in the entire pipeline), but baby steps.
Oh, and all of the above++ is already in Arcan and yet it is still nowhere near good enough.
'Desktop/display server' parts is just a sidetrack that I do to get about as far away from what is otherwise happening in that space as possible, I need a sane work environment that doesn't keep making decisions behind my back or is laughably unreliable, and this turned out to be the easiest, albeit time-consuming, route.
The initial choice of Lua for Arcan was based on its use, at the time (2004-2005ish), in World of Warcraft. The UIs that people were hacking together in WoW even with little to no serious programming experience was way more advanced than what would ever be needed for desktop interfaces so it seemed like a good fit. Even for other projects, Lua is still my goto "safe" keyword for C.
There are more interesting properties though, especially how the VM- bindings integrate with C. Stay away from using too much metatable magic etc. and what you get is an ok "protocol+binding" in one. Substitute the stack for socket read/write, add an identifier to function translation and you can chose between in-process or stronger separation. The reality is slightly more involved, but not by much.
Alas, the improvement that should really be made is to encode both n and n+1 in the same update and interpolate in the vertex shader, not hard here but I was lazy..
At the same time, speaking from personal experience - 3D in VR can give a much stronger sense of overview of many datasources etc. while at the same time can reduce semantic noise.
I get quite a few productive hours out of a successor to this: https://www.youtube.com/watch?time_continue=1&v=Js7Y1H5D8cY