A nodeDB is one of the core services of a community network. A community wireless network has a couple of needs which are covered by a nodeDB:

• registry functionality: reserve IP addresses, assign nodes and devices to users, register users and their email addresses. As such the nodeDB serves as a database for the network.
• link planning: this answers the question “if I put a node here, will it work?”
• CPE provisioning: image generation: automatically generate images / firmware or their respective configuration (in Guifi.net this feature is called “unsolclick”)
• server config provisioning: central servers such as DNS servers need information from the nodeDB (which devices exist, what are their IPs etc). Services could include:
  • DNS
  • VoIP servers
  • Whois server
  • map service
• allow people to contact each other in a distributed community network
• federation: allow services such as DNS zones to be federated across the network
• monitoring & alerting: devices and central services need to be monitored.
• One goal should be to have a nodeDB as a “Setup.exe” for new community networks
• common query-API: a nodeDB needs to speak the standardized query API

Since roughly the year 2000 different community networks have been implementing and re-implementing their own management tools for running community wireless networks. These tools , amongst them you will always find a node database, are non interoperable. It is currently not possible to program one application for one community network and let it “run” with the services and nodeDB of the other community networks. This results in a waste of resources, waste of time and will be a big stumbling block for connecting community networks to each other. Apart from the non-interoperable tools, there the authors identified two other stumbling blocks for connecting community networks (possibly in a federated way):

• IP addressing schemata: most community networks run on private RFC1918 IP addresses. These will collide when connecting two different community networks. Any future, harmonized nodeDB therefore must take into account the switch to IPv6 which allows the community networks to be connected to each other via IPv6 at least
• exterior gateway protocol interoperability: BGP (RFC 4271) is not particularly well suited for wireless connections and the change in link quality. However, this topic is outside of the scope of this document and merely mentioned here.

The following document shall describe a harmonized nodeDB implementation and an API for querying this nodeDB. The API SHOULD be implemented by existing nodeDB variants in order to allow for improved interoperability and federation as part of the CONFINE project. The API consists of two parts:

1. a RESTful query API
2. two possible answer format for queries: JSON or XML based on the CNML specifications.

In the course of this attempt, the CNML specifications will be expanded (but documented in a different place XXX : link to CNML?)

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [RFC2119], with the important qualification that, unless otherwise stated, these terms apply to the design of the incident response requirements and design document, not its implementation or application.

The interop page at http://interop.wlan-si.net/wiki/NodesDatabase was already a first attempt to get an interoperable nodeDB started. Unfortunately, due to lack of resources, these attempts died off two times.

• 'Funkfeuer' (Austria) [https://marvin.funkfeuer.at/frontend_wien/ Node Database] | [http://map.funkfeuer.at Map]
• 'Redeemer' (Funkfeuer Wien) [http://sourceforge.net/projects/redeemer/ Source code on Sourceforge] | Database Schema Wien | Database Schema Graz
• 'WiND' (Athens Wireless Metropolitan Network) [http://wind.cube.gr/ Source code on Trac] | [http://wind.cube.gr/browser/trunk/install/schema.sql|Database Schema] |
• 'Guifi.net' [http://gitorious.org/guifi Source code on Gitorious] | [http://gitorious.org/guifi/drupal-guifi/blobs/master/guifi.install Database Shema (Database addons for Drupal 6)] | [http://guifi.net/en/node/36672 HowTo add a new Node in Guifi.net] | [https://docs.google.com/document/d/1XYHOMaSkEe2mCj0_Va0pE2om-oHrWifkEInQ2NJ3W18/edit?hl=de Guifi.net business logic]
• 'Nodewatcher' (wlan slovenija) [http://dev.wlan-si.net/wiki/GetSource Source code on Trac] | Database Schema
• 'Freifunk Node Database' (Freifunk Hannover) [http://github.com/knox/nodes Source code on Github!] | Database Schema
• 'Netmon' (Freifunk Oldenburg) [http://trac.freifunk-ol.de/ Source code on Trac] | Database Schema, [http://en.wikipedia.org/wiki/Wireless_Nodes_Database Wikipedia article] | [http://wind.cube.gr/ Development Area, [https://docs.google.com/document/d/1qfOXNrLBrGwU8lKBHIQAShnqgNE3udPoSYEMOhKWoDI/edit?hl=en_US Business logic]
• 'NodeDB Augsburg' (Freifunk Augsburg) [http://augsburg.freifunk.net/nodes.html Source code is missing]
• 'NodeDB Jena' (Freifunk Jena) [http://www.freifunk-jena.de/NodeDB (Source code is missing)]
• 'IP Vergabe' (Freifunk Berlin) [http://ip.berlin.freifunk.net/index.html (Source code is missing)]
• 'DDMesh Hotspots' (Freifunk Dresden) [http://www.ddmesh.de/hotspots.html (Source Code is missing)]
• 'Nodeübersicht Bonn' (Freifunk Bonn) [http://bonn.freifunk.net/tiki-index.php?page=Nodes%C3%BCbersicht (Tikiwiki, Source code?)]
• 'DB' (Freifunk Leipzig) [https://db.leipzig.freifunk.net/ (Source code is missing)]
• 'Anomo' (Freifunk Leipzig) [https://dev.leipzig.freifunk.net/trac/wiki/ANOMO Source code on Trac] | [https://dev.leipzig.freifunk.net/trac/browser/anomo/cgi-bin/definitions.sql Database Schema]