HALO application

[zhenyasav]

Using the app, users can:

• self-identify
• recover their halo / absorb it from another device
• discover and inspect the network
• join parties (spaces)
• send simple messages to each other once in a space
• create and collaborate on a list of strings in a space.
• join HALO across multiple devices (including the CLI)

---

• Spec (TODO: link GH issue/document): app and user experience (https://www.figma.com/file/QY7QhVXKddDEOXLGVlEjBI/HALO)
• Pre-bundling the client #1325: Stage 1
• Get Vite workspace deps working
• Vite module resolution fix (sodium-universal browser mapping)
  • DXOS-only patch
  • Vite fix (fix(optimizer): browser field bare import vitejs/vite#8709 / fix: respect bare imports in browser field of package.json vitejs/vite#9441)
• Config plugin for rollup
• Setup basic DXOS app shell/template in PWA template (feat(halo-app): Redesign first pass #1538)
  • Hook up registration flow for new profile
  • Hook up registration flow for profile recovery
  • Hook up sharing dialog for adding devices to a HALO
  • Create basic interface for displaying HALO
  • Create basic interface for adding/joining spaces
  • Create basic interface for displaying space data
  • Create basic interface for editing space items
  • Hook up sharing dialog for granting members access to space
  • Create basic interface for editing space metadata
  • Make components responsive
  • Update Party language to Space
• PWA Research and Testing
  • React StrictMode breaks sdk #1641
    • Service workers can be installed without user action (https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers#registering_your_worker)
    • In Chrome you can also optionally prompt end-user to install a PWA (https://web.dev/learn/pwa/installation/#prompting-for-installation)
  • Transferring client from one tab to another breaks reactivity of all open tabs #1640
    • "The fetch event lets us intercept every network request made by the PWA in the service worker's scope, for both same-origin and cross-origin requests" https://web.dev/learn/pwa/serving/#the-fetch-event
    • if you make a cross-origin request from a page, it will go through the service worker that manages the page. If there's a service worker registered for the url on the other domain, it will not go the other domain's service worker. Responding to cross-origin requests using a worker? w3c/ServiceWorker#130 (comment)
  • Shared Worker/Client RPC
    • webrtc is not yet supported in workers (Add support for WebRTC Data Channel in Workers w3c/webrtc-pc#230, WebRTC can be used for exfiltration w3c/webappsec-csp#92, Make WebRTC usable as a backend for Service Workers to fulfill requests from a peer-to-peer network w3c/ServiceWorker#1522, Make WebRTC usable as a backend for Service Workers to fulfill requests from a peer-to-peer network w3c/webrtc-pc#2553)
    • possible communication channels:
      • transferable streams (https://stackoverflow.com/questions/54766128/can-a-pwa-run-a-webrtc-connection-in-the-background)
      • websocket sterams (https://chromestatus.com/feature/5189728691290112)
      • message passing along the lines of how devtools works (https://web.dev/two-way-communication-guide/)
    • if client lives in a service worker is it possible to stream audio/video uninterrupted due to worker lifetime? No, when needing to open some sort of long standing channel between two peers the client backend would need to give the frontend the details so that it could make that connection on it's own.
  • Test various limited connectivity use cases to ensure PWA template caches app appropriately
    • For the most part the app "just worked" offline using the default vite-plugin-pwa service worker. The exception to that was the dynamic config request to kube which failed when offline. Catching that failure allowed the app to work offline.
    • Other future considerations:
      • Can we cache the config request? pwa plugin has an option additionalManifestEntries which seems to map to the workbox precache, but emits a warning when I include the well known config path without a revision https://developer.chrome.com/docs/workbox/modules/workbox-precaching/#explanation-of-the-precache-list I think that means that without it, it will not be predictably updated. Passing in a string removes the warning but the docs say "It's strongly recommended that you use one of Workbox's build tools to generate this precache manifest. Never hardcode revision info into a "hand written" manifest, as precached URLs will not be kept up to date unless the revision info reflects the URL's contents!" These tools seem more intended for caching assets within the application, since the config request lives independent from the application I'm not sure we want to use them to cache the config request. Perhaps if we used our own service worker we could intercept and cache the results of that request based on the current version of the app, however what if kube changes config between versions? Config needs a way to become invalidated
      • Do we want the service worker to cache other media assets (e.g., images stored in ipfs)?
  • Understand better and document mechanisms for PWA cache reset when necessary
    • Using default update mechanisms in the vite-plugin-pwa, once new assets have been deployed, the first reload downloads and installs the new assets and the second reload uses them within the app
  • Cross-domain service workers
    • These generally seem to work fine, however stricter browser settings seem to block them (e.g., Brave shields) so that may need to be taken into account when building apps
• Add new functionality to app to scan QR codes from mobile devices to join a HALO
• Publish app to well known location: halo.dxos.org
• Login with HALO flow (feat: Login with HALO #1512)
  • load identity creation/selection interface in iframe modal
  • HALO app creates device invitation and passes it back to the authenticating app to be redeemed
  • once redeemed the app is now an autonomous device within that identity

Bugs

• React StrictMode breaks sdk #1641
• Transferring client from one tab to another breaks reactivity of all open tabs #1640

[zhenyasav]

prior art #68