The name should be closer to "offline-first-octopus" to clarify the importance of resilience and that consequently Internet access must always remain optional.
It grew to incorporate not just 1 type of device connected via a single hotspot to something more generalist, namely connecting (ideally) any kind of device via a single hotspot or (also ideally) relying on a mesh of them.
This was achieved in part by having a single hotspot (RPi0 running Raspian on arm) and multiple different devices (SteamDeck running Arch Linux on x64, reMarkable2 running Linux Codex, Quest 2 running Android via Termux), see 5c1f449f67 .
It was then extended to another network with additional machines (iPhone running iOS via ish, PineNote running Android via Termux), see fa3ee1fc2a.
It was then extended once again to spawn other devices, see 5c3b7063d3 .
Due to the difficulty to support some machines #7 or the risk of going from a purely offline solution, thus in a trusted context, to the Internet with obvious consequences #6 (and despite some form of authorization, both via its interface and existing solution, i.e ssh keys) it could be interesting to consider linked work, e.g https://git.benetou.fr/utopiah/vpn-metaverse-tooling
Yet, overall, the question at its core is : how can the boundary be clear enough to be safe and understandable while remaining flexible to efficiently build more and better prototypes?
Finally, what is currently defining that boundary?
ssh keys,
authoriozation mechanism with its bearer token,
~/.ssh/config,
result of scanpeers() as peerFounds
all help to define it but the result is unclear.
the name is "offline-octopus" because implementation started offline. The basis was started as https://git.benetou.fr/utopiah/local-metaverse-tooling from a need of giving a social workshop, in VR, without requiring an Internet connection. In retrospect the need arised much earlier via https://fabien.benetou.fr/innovativ.it/www/HistoricalArchives/Seedea/Oimp/Lqnet formulated in 2008, ~15 years earlier.
The name should be closer to "offline-first-octopus" to **clarify the importance of resilience and that consequently Internet access must always remain optional**.
It grew to incorporate not just 1 type of device connected via a single hotspot to something more generalist, namely connecting (ideally) any kind of device via a single hotspot or (also ideally) relying on a mesh of them.
This was achieved in part by having a single hotspot (RPi0 running Raspian on arm) and multiple different devices (SteamDeck running Arch Linux on x64, reMarkable2 running Linux Codex, Quest 2 running Android via Termux), see https://git.benetou.fr/utopiah/offline-octopus/commit/5c1f449f672df69cc6b40631469ab1369a1564a2 .
It was then extended to another network with additional machines (iPhone running iOS via ish, PineNote running Android via Termux), see https://git.benetou.fr/utopiah/offline-octopus/commit/fa3ee1fc2a21a26739cc40cccb7c395282bfa42a.
It was then extended once again to spawn other devices, see https://git.benetou.fr/utopiah/offline-octopus/commit/5c3b7063d3b51b111a70eaed5bb1d463500222ed .
Due to the difficulty to support some machines https://git.benetou.fr/utopiah/offline-octopus/issues/7#issuecomment-435 or the risk of going from a purely offline solution, thus in a trusted context, to the Internet with obvious consequences https://git.benetou.fr/utopiah/offline-octopus/issues/6 (and despite some form of authorization, both via its interface and existing solution, i.e ssh keys) it could be interesting to consider linked work, e.g https://git.benetou.fr/utopiah/vpn-metaverse-tooling
Yet, overall, the question at its core is : **how can the boundary be clear enough to be safe and understandable while remaining flexible to efficiently build more and better prototypes?**
Finally, what is currently defining that boundary?
* ssh keys,
* authoriozation mechanism with its bearer token,
* `~/.ssh/config`,
* result of `scanpeers()` as `peerFounds`
all help to define it but the result is unclear.
Interesting to consider the network traversal perspective but it must not be taken too simplistically as it is done at different levels.
For example one can think of a node at the peer level for IP, i.e 1.1.1.1 trying to ping 1.1.1.2. Yet, one can also take a Web client on node 1.1.1.1 trying to reach an HTTP server on itself, namely 1.1.1.1 or its loopback interface. This would still be traversal of the network. This is especially important here as the very raison d'etre of this work is to provide access to resources that would otherwise be limited to the current node at that level.
Consequently, one must consider boundary for multiscale network traversal.
Interesting to consider the network traversal perspective but it must not be taken too simplistically as it is done at different levels.
For example one can think of a node at the peer level for IP, i.e 1.1.1.1 trying to ping 1.1.1.2. Yet, one can also take a Web client on node 1.1.1.1 trying to reach an HTTP server on itself, namely 1.1.1.1 or its loopback interface. This would still be traversal of the network. This is especially important here as the very raison d'etre of this work is to provide access to resources that would otherwise be limited to the current node at that level.
Consequently, one must consider boundary for multiscale network traversal.
Relying on Express, `next()` could help organize unauthorized versus authorized, see e.g https://github.com/expressjs/express/blob/master/examples/web-service/index.js#L30 and documented as https://expressjs.com/en/api.html#app.use and https://expressjs.com/en/guide/writing-middleware.html
Was already commented as https://git.benetou.fr/utopiah/offline-octopus/src/branch/master/index.js#L115
See also OAuth prototype relying on Keycloak as identity provider with AppAuth-JS as client
See also OAuth prototype relying on [Keycloak](https://www.keycloak.org) as identity provider with [AppAuth-JS](https://github.com/openid/AppAuth-JS/) as client
Consider Tailscale as a solution to "Due to the difficulty to support some machines #7 or the risk of going from a purely offline solution, thus in a trusted context, to the Internet with obvious consequences #6 (and despite some form of authorization, both via its interface and existing solution, i.e ssh keys) it could be interesting to consider linked work, e.g https://git.benetou.fr/utopiah/vpn-metaverse-tooling"
Consider Tailscale as a solution to "Due to the difficulty to support some machines #7 or the risk of going from a purely offline solution, thus in a trusted context, to the Internet with obvious consequences #6 (and despite some form of authorization, both via its interface and existing solution, i.e ssh keys) it could be interesting to consider linked work, e.g https://git.benetou.fr/utopiah/vpn-metaverse-tooling"
the name is "offline-octopus" because implementation started offline. The basis was started as https://git.benetou.fr/utopiah/local-metaverse-tooling from a need of giving a social workshop, in VR, without requiring an Internet connection. In retrospect the need arised much earlier via https://fabien.benetou.fr/innovativ.it/www/HistoricalArchives/Seedea/Oimp/Lqnet formulated in 2008, ~15 years earlier.
The name should be closer to "offline-first-octopus" to clarify the importance of resilience and that consequently Internet access must always remain optional.
It grew to incorporate not just 1 type of device connected via a single hotspot to something more generalist, namely connecting (ideally) any kind of device via a single hotspot or (also ideally) relying on a mesh of them.
This was achieved in part by having a single hotspot (RPi0 running Raspian on arm) and multiple different devices (SteamDeck running Arch Linux on x64, reMarkable2 running Linux Codex, Quest 2 running Android via Termux), see
5c1f449f67.It was then extended to another network with additional machines (iPhone running iOS via ish, PineNote running Android via Termux), see
fa3ee1fc2a.It was then extended once again to spawn other devices, see
5c3b7063d3.Due to the difficulty to support some machines #7 or the risk of going from a purely offline solution, thus in a trusted context, to the Internet with obvious consequences #6 (and despite some form of authorization, both via its interface and existing solution, i.e ssh keys) it could be interesting to consider linked work, e.g https://git.benetou.fr/utopiah/vpn-metaverse-tooling
Yet, overall, the question at its core is : how can the boundary be clear enough to be safe and understandable while remaining flexible to efficiently build more and better prototypes?
Finally, what is currently defining that boundary?
~/.ssh/config,scanpeers()aspeerFoundsall help to define it but the result is unclear.
On a conceptual viewpoint reconsider https://fabien.benetou.fr/Cookbook/Cognition#ExocognitionAsNetworkTraversal
Interesting to consider the network traversal perspective but it must not be taken too simplistically as it is done at different levels.
For example one can think of a node at the peer level for IP, i.e 1.1.1.1 trying to ping 1.1.1.2. Yet, one can also take a Web client on node 1.1.1.1 trying to reach an HTTP server on itself, namely 1.1.1.1 or its loopback interface. This would still be traversal of the network. This is especially important here as the very raison d'etre of this work is to provide access to resources that would otherwise be limited to the current node at that level.
Consequently, one must consider boundary for multiscale network traversal.
On interfaces specifically and finding the right level (of abstraction) see https://fabien.benetou.fr/Content/OnManagingInterfaces
See also https://git.benetou.fr/utopiah/offline-octopus/src/branch/reverse-proxy providing more flexibility
Relying on Express,
next()could help organize unauthorized versus authorized, see e.g https://github.com/expressjs/express/blob/master/examples/web-service/index.js#L30 and documented as https://expressjs.com/en/api.html#app.use and https://expressjs.com/en/guide/writing-middleware.htmlWas already commented as https://git.benetou.fr/utopiah/offline-octopus/src/branch/master/index.js#L115
See also OAuth prototype relying on Keycloak as identity provider with AppAuth-JS as client
See also PAN or https://en.wikipedia.org/wiki/Personal_area_network in particular related to #7
Consider Tailscale as a solution to "Due to the difficulty to support some machines #7 or the risk of going from a purely offline solution, thus in a trusted context, to the Internet with obvious consequences #6 (and despite some form of authorization, both via its interface and existing solution, i.e ssh keys) it could be interesting to consider linked work, e.g https://git.benetou.fr/utopiah/vpn-metaverse-tooling"