I feel like it’s one of those hidden gems that is so powerful people have a hard time fathoming the things it enables people to do. Like 9p/namespaces in plan9..
The trouble, IMHO, is that the author gets way too carried away with their rhetoric on the site. It’s very hard to work out what it’s actually for and does and may one day do.
Simplicity is good.
Clarity is important.
Brevity wins.
I mean, I speak as a professional writer who often tends to write way too long! It’s hard to be short, but it’s necessary. The Arcan site needs to ELI5, a handful of tweet-length bullet points to get the message across.
The excessive verbiage and obscure message is quite deliberate. Judging from my inbox, it works well enough in the sense that the right audience definitely takes note and sometimes even reach out, directly and indirectly; a perfume of equal parts sewage, equal parts ivory tower. It is a balance act being dismissed as obscure and harmless enough as to avoid becoming cannon fodder for a web that thrives on polarisation. The filter setting is somewhere around “if it gets above the HN front page threshold it is time to bring out the thesaurus”. As a person I’m dissuaded by attention, not encouraged by it.
While “formally” a release post (which I normally avoid pushing), there is something of a ‘try asking lobste.rs’ embedded into it – being the filter bubble I have access to that best fits the “ask”.
There is a much lengthier dive into this that I’ll spare people for now, but in the networking section, the lines between app models (mobile, desktop, embedded, web) is blurred and the distance from ‘develop and share’ shortened down to just before the 80ies home computer ‘boot into REPL’ era meets heroku ‘push and deploy’.
I have some idea where this is heading, but much less of its pros, cons and fixable flaws. Normally, to test such things, I tend to pick a few applications, run it against the model and see what comes out on the other side. Here I am having some troubles coming up with ideas that aren’t tainted ;)
What I am specifically looking for here are ideas for applications that are (annoying, awful, expensive), to develop in the current web2.x “networked application substrate” sense that I can prototype and compare against – one example on the drawing board is the kind of collaborate gaming planning being done with (https://xivsim.com/). Any others?
That one is practically possible right now (quality issues around sound and unintuitive tooling aside) - it’ll show off improvements to local discovery though (“of all the devices I trust, which one are available right now) so a good target for 0.6.3 regardless. A nice expansion would be something like Twitter Spaces (moderated many to many) with media/blob data sharing through.
One application idea: collaborative Jupyter-like notebooks with client-side hardware accelerated graphics. Think 3D plots that each client can rotate and zoom but also update via REPL for all participants.
Did you look at the pipeworld[1] project? Ignoring the visual flair / ZUI shenanigans - the basic design and processing model is quite close. The scattered notes for that project have a few collaboration options, though I mostly considered the unsexy one of composing a set of cells into a shared / collaborative that act as a ‘remote desktop’.
The more delicious approach would be to have cells that do synch against other connected users, but the sharing /synchronisation semantics for cells (say I run an external program and you want to use the contents of its clipboard as part of a shader applied to the webcam feed from another being sent to a third) are “non-trivial”. Still it would show off the parts of synchronising local state to a server-side identity-tied store and drive the use of a trusted third party as rendezvous for sharing within a group, so I’ll probably implement it…
I did see pipeworld earlier: very impressive :) The collaboration part could be just a text editor as “remote desktop” as you said. Not very impressive but something that’s not easy to implement in other environments.
The ‘hardware accelerated graphics’ part is there. The ‘collaborative’ part is an application level concern, not a substrate level concern; probably crdt or similar.
The raid planner example calls to mind a “serverless” take on competitive and hot seat games: chess, go, scorched earth, anything fairly simple and turn-based with perfect information where a player could pull their “seat” onto other devices and back.
That by itself is basically a parlor trick, but I’m thinking also that the slower pace afforded by moving players around/across devices (closer to play by email or BBS door games) could also allow for forking and recombining game states: not only to participate from my own device, but to disconnect, play out a few turns against AI or a different human opponent on yet another device, then roll back and reconnect (perhaps from a different network somehow?) or even reconvene on the one original device. Useful for learning or cheating at chess, and so on. In all it’d be a simple and decently demoable example of sharing, validating, merging, and expiring state. A server could do it juggling client websockets and tracking state trees centrally but that sounds kind of horrible.
Your suggestion is probably a more approachable middle ground than the XIV example (though I might just do that for other reasons). The scaffolding for the case you presented was added way back, I think around 2013 when we experimented with ‘rewind’ in emulators (I think the retroarch/libretro guys have some videos around that on youtube still) and then used it as a way to shorten the distance between latency an perceived latency with selective rollback.
You did lead me on to thinking of shared state synchronisation. It will be a bit uncomfortable to implement on the directory server end in its current state, but having multiple concurrent sessions on the same keypair is possible, so synchronising persistent state store updates would be a logical continuation.
I think the demo video will be something visually easy to grasp like desktop wallpaper and colorscheme updates being changed across all local devices at once. That would still match your chess case internally - at load time all nodes get the same state, the alternate hypotheses play out, AI controlled nodes playing forward from their current state, and on a global ‘push’ revert to the next shared default and spin off again.
The next release (and current thing being coded and recorded) sortof fits that – the way clients downloaded and ran an appl is structured so that the server can live ‘push’ a new update, and the local arcan runner can switch to that instantaneously (related is the articles on crash resilience). The same action can act as this sync point. The demo would be something like live-coding something visual and see it project across different form factors, with crashes collected and fed back to the development machine.
I am still in a denial phase (then comes anger, …), but it very much looks like the server end will grow a nodejs (albeit Lua) like structure for expressing sharing semantic, state management and so on.
This is awesome! I am so excited about Arcan :D
I feel like it’s one of those hidden gems that is so powerful people have a hard time fathoming the things it enables people to do. Like 9p/namespaces in plan9..
Fair comment.
The trouble, IMHO, is that the author gets way too carried away with their rhetoric on the site. It’s very hard to work out what it’s actually for and does and may one day do.
Simplicity is good.
Clarity is important.
Brevity wins.
I mean, I speak as a professional writer who often tends to write way too long! It’s hard to be short, but it’s necessary. The Arcan site needs to ELI5, a handful of tweet-length bullet points to get the message across.
The excessive verbiage and obscure message is quite deliberate. Judging from my inbox, it works well enough in the sense that the right audience definitely takes note and sometimes even reach out, directly and indirectly; a perfume of equal parts sewage, equal parts ivory tower. It is a balance act being dismissed as obscure and harmless enough as to avoid becoming cannon fodder for a web that thrives on polarisation. The filter setting is somewhere around “if it gets above the HN front page threshold it is time to bring out the thesaurus”. As a person I’m dissuaded by attention, not encouraged by it.
Thank you for the comment!
That is a very interesting position, but I do sort of see your point.
I have “reached out” (although I am not, nor ever have been, one of the Four Tops).
While “formally” a release post (which I normally avoid pushing), there is something of a ‘try asking lobste.rs’ embedded into it – being the filter bubble I have access to that best fits the “ask”.
There is a much lengthier dive into this that I’ll spare people for now, but in the networking section, the lines between app models (mobile, desktop, embedded, web) is blurred and the distance from ‘develop and share’ shortened down to just before the 80ies home computer ‘boot into REPL’ era meets heroku ‘push and deploy’.
I have some idea where this is heading, but much less of its pros, cons and fixable flaws. Normally, to test such things, I tend to pick a few applications, run it against the model and see what comes out on the other side. Here I am having some troubles coming up with ideas that aren’t tainted ;)
What I am specifically looking for here are ideas for applications that are (annoying, awful, expensive), to develop in the current web2.x “networked application substrate” sense that I can prototype and compare against – one example on the drawing board is the kind of collaborate gaming planning being done with (https://xivsim.com/). Any others?
I own computers A and B, am physically at computer A, videochatting with you, and want to show you a resource ‘located’ on computer B.
That one is practically possible right now (quality issues around sound and unintuitive tooling aside) - it’ll show off improvements to local discovery though (“of all the devices I trust, which one are available right now) so a good target for 0.6.3 regardless. A nice expansion would be something like Twitter Spaces (moderated many to many) with media/blob data sharing through.
One application idea: collaborative Jupyter-like notebooks with client-side hardware accelerated graphics. Think 3D plots that each client can rotate and zoom but also update via REPL for all participants.
Did you look at the pipeworld[1] project? Ignoring the visual flair / ZUI shenanigans - the basic design and processing model is quite close. The scattered notes for that project have a few collaboration options, though I mostly considered the unsexy one of composing a set of cells into a shared / collaborative that act as a ‘remote desktop’.
The more delicious approach would be to have cells that do synch against other connected users, but the sharing /synchronisation semantics for cells (say I run an external program and you want to use the contents of its clipboard as part of a shader applied to the webcam feed from another being sent to a third) are “non-trivial”. Still it would show off the parts of synchronising local state to a server-side identity-tied store and drive the use of a trusted third party as rendezvous for sharing within a group, so I’ll probably implement it…
[1] https://arcan-fe.com/2021/04/12/introducing-pipeworld/
I did see pipeworld earlier: very impressive :) The collaboration part could be just a text editor as “remote desktop” as you said. Not very impressive but something that’s not easy to implement in other environments.
The ‘hardware accelerated graphics’ part is there. The ‘collaborative’ part is an application level concern, not a substrate level concern; probably crdt or similar.
The raid planner example calls to mind a “serverless” take on competitive and hot seat games: chess, go, scorched earth, anything fairly simple and turn-based with perfect information where a player could pull their “seat” onto other devices and back.
That by itself is basically a parlor trick, but I’m thinking also that the slower pace afforded by moving players around/across devices (closer to play by email or BBS door games) could also allow for forking and recombining game states: not only to participate from my own device, but to disconnect, play out a few turns against AI or a different human opponent on yet another device, then roll back and reconnect (perhaps from a different network somehow?) or even reconvene on the one original device. Useful for learning or cheating at chess, and so on. In all it’d be a simple and decently demoable example of sharing, validating, merging, and expiring state. A server could do it juggling client websockets and tracking state trees centrally but that sounds kind of horrible.
Your suggestion is probably a more approachable middle ground than the XIV example (though I might just do that for other reasons). The scaffolding for the case you presented was added way back, I think around 2013 when we experimented with ‘rewind’ in emulators (I think the retroarch/libretro guys have some videos around that on youtube still) and then used it as a way to shorten the distance between latency an perceived latency with selective rollback.
You did lead me on to thinking of shared state synchronisation. It will be a bit uncomfortable to implement on the directory server end in its current state, but having multiple concurrent sessions on the same keypair is possible, so synchronising persistent state store updates would be a logical continuation.
I think the demo video will be something visually easy to grasp like desktop wallpaper and colorscheme updates being changed across all local devices at once. That would still match your chess case internally - at load time all nodes get the same state, the alternate hypotheses play out, AI controlled nodes playing forward from their current state, and on a global ‘push’ revert to the next shared default and spin off again.
The next release (and current thing being coded and recorded) sortof fits that – the way clients downloaded and ran an appl is structured so that the server can live ‘push’ a new update, and the local arcan runner can switch to that instantaneously (related is the articles on crash resilience). The same action can act as this sync point. The demo would be something like live-coding something visual and see it project across different form factors, with crashes collected and fed back to the development machine.
I am still in a denial phase (then comes anger, …), but it very much looks like the server end will grow a nodejs (albeit Lua) like structure for expressing sharing semantic, state management and so on.