• djvj
    lgierth: ah, you're talking about the firefox code.
  • djvj
    lgierth: it's quite old and likely bitrotted. We shifted towards the mobile app approach a few months before we stopped work.
  • djvj
    I think most of it has to be rewritten. It was during the e10s transition and uses some funky inheritance mechanics to abstract between e10s and single-process modes
  • djvj
    because one requires message passing and the other is synchronous.
  • djvj
    lgierth: if it's a possibilty, I'd work with the iOS or Android code.
  • djvj
    lgierth: the iOS code is lighter, because Apple's mDNS discovery API is actually well implemented. On Android I replaced the system impl with a custom one because their system implementation sucked.
  • victorbjelkholm
    hm, I think our (I work with lgierth on IPFS) usecase is mostly geared towards desktop/laptop usage, as js-ipfs/go-ipfs is currently very heavy for mobile devices
  • djvj
    this is an aside, but I'm curious, why is it heavy on mobile devices?
  • djvj
    I haven't looked at the implementation closely, but I'm assuming you're using content-hashed index trees and assembling data client-side?
  • victorbjelkholm
    djvj: mostly missing connection-closing (so the nodes will just connect to as many peers as possible) and also everyone is helping serving the dht (although we do have some experimental features for having a get-only for dht-clients)
  • djvj
    ah, right, you're a server too
  • victorbjelkholm
    the protocol is not inherently heavy, we're just missing some features for scaling currently, and the network grew a lot recently
  • djvj
    cool
  • djvj
    anyway, even on desktop, I'd recommend wrapping a browser more than extending it.
  • victorbjelkholm
    hm, what would that concretely mean?
  • djvj
    so there are different aspects to the flyweb project that can be separated out. At it's simplest, it's a URL-discovery frontend for a browser, and a routing mechanism.
  • djvj
    the URL discovery discovers local services and maps them to some URL the browser can request. The routing mechanism sends the browser data from the service when it requests that URL.
  • djvj
    So the URL might be something like flyweb://F31A-AC11-.../ whatever (anonymous service with a hash-based name)
  • djvj
    you can implement the whole thing outside of the browser, with a small js-extension within the browser that maps "flyweb://" scheme URLs to a local HTTP proxy server (run in the wrapper program) that bridges to the service.
  • djvj
    You could even stay within the http namespace and just take a TLD (http://<something>.flyweb) as your namespace.
  • djvj
    So that's feature-set 1.
  • djvj
    second feature set was the web APIs that would allow you to host a server in the browser.
  • djvj
    and then advertise that server as a service to nearby FlyWeb client devices
  • djvj
    victorbjelkholm: thinking about it, it seems like this API is what you're more likely to be interested in..
  • djvj
    victorbjelkholm: actually, can you tell me what you wanted to do? It'll give me a better idea of what to suggest..
  • lgierth
    djvj: yes, having a websockets server announced to the local network is what we're after
  • lgierth
    and ideally discovering them too
  • lgierth
    we don't need TLS since the ipfs/libp2p stack does its own crypto depending on the context, but i figure browsers nowadays simply require it :)