Finding neighboring mesh nodes

Assumptions

• There is at least one mesh node.
• Meshes are not built through collusion, i.e., each person setting up a node does not do so knowing that others are as well.
• Mesh nodes are able to broadcast the existence of services they run ("I run a microblog!")
• Services can be activated on a node (implying that their presence will be announced) or deactivated (implying that their presence will not be announced)
• Mesh nodes continually listen for announcements of services from neighboring mesh nodeds
• Mesh nodes maintain directories of services running on neighboring mesh nodes
  • ...except when a service is designed to automatically federate with others of a like type (i.e., announcements of content from one will automatically be incorporated into cached announcements on the node)
• Clients neither broadcast nor listen for service announcements
  • Smartphones
  • MP3 players
  • Computers not running Byzantium

Existing protocols

• Avahi/ZeroConf/mDNS
• Included in Porteus Linux
  • Host can publish running services
  • Host can be informed of services running on other hosts
  • User does not have to specifically configure any of this
  • Host admins may have to configure this
  • Bindings for multiple languages are available
  • Protocol in a nutshell:
    • Ad-hoc DHS over IP multicast (224.0.0.251)
    • Each node has a resource record for each service
      • SRV
      • TXT
      • PTR
      • Types documented in /usr/share/avahi/service-types on Windbringer. File is part of Avahi on all systems.
        • HAS NOTHING TO DO WITH dnsmasq!
  • Resolution is done by the host running an Avahi implementation - broadcast a resolution request to the multicast domain and listen for a response
  • Node needs to have its hostname set (machinename.local)

• XMPP service discovery
  • XEP-0030

• DHCP

• XRDS