# DisasterRadio Mozilla Grant Submission Draft

# REMAINING TO DO'S:
* Snipped Applications section to get under character limit - move to Tech Feasibility?
* Tighten Tech Feasibility
* Finish Power section (see To Dos under response)
* Review Users / Community / Social Impact for consistency, relevance and flow

# Team Members (5000 characters)
For each member of your team, please list the following: Full name, Email address, A brief bio, which includes their role on the team (i.e. “designer”), Links to any additional background information (optional)

// BIO TEMPLATE
// - name, email
// - bio
// - role(s) in this project
// - why you're awesome + relevent experience
// - sweet links

- Piet
Piet has seven years of industry experience building, testing and fixing high end scientific equipment and desiging multi-layer PCBs for [complex](https://pietgeursen.github.io/4GAS.pdf) [mixed](https://pietgeursen.github.io/WE32.pdf) [signal](https://pietgeursen.github.io/sModule.pdf) [equipment](https://pietgeursen.github.io/HIMUX_XR.pdf). He is experienced in embedded C programming and is a contributor to the open source [Scuttlebutt](https://www.scuttlebutt.nz/) peer to peer gossip network. More recently he worked as a teacher at [Enspiral Dev Academy](https://www.devacademy.co.nz/).
- Role: Electronics design, testing and small batch manufacturing
- https://pietgeursen.github.io/ - https://github.com/pietgeursen

- Sierk Beij
- Sierk is a web developer, community organizer, and activist. He is interested in participatory democracy and does not like writing bios.
- Role: web developer

- cel - [e-mail]
- cel is a developer focused on peer-to-peer collaborative applications and protocol integrations. He develops Scuttlebutt applications for decentralized git and npm hosting.
- Role: application developer
- @f/6sQ6d2CMxRUhLpspgGIulDxDCwYD7DzFzPNr7u5AU=.ed25519

- Dominic Tarr
- Dominic is the originator and a core developer of the [Scuttlebutt](https://www.scuttlebutt.nz/) peer to peer gossip network. He has over 700 published open source javascript modules on [npm](https://www.npmjs.com/~dominictarr), many of them focused on simplifying peer to peer software development.
- Role: Integration with the Scuttlebutt peer to peer network and mesh algorith development
- https://theinitialcommit.com/2017/04/04/dominic-tarr/ - http://dominictarr.com/ - https://github.com/dominictarr - https://www.npmjs.com/~dominictarr

- mix - [e-mail]
- mix is an active member of the Scuttlebutt Project, where he maintains a client, and supports other developers and community. He's also helped build open participatory platforms such as Loomio and Cobudget. As well as technical roles, Mix runs retrospectives, runs user interviews to inform UX, and supports accessibility through translations.
- Roles: interface developer
- www.scuttlebutt.nz , www.protozoa.nz, www.loomio.org www.cobudget.co

- Scott Garrison - [e-mail]
- Scott is interested in technologies that make communities more self sufficient and robust. In the past he's built software for schools, firmware design for alternative energy systems and an inventory management system for the food industry. BA in Physics from U.C. Berkeley.
- Roles: hardware and firmware developer
-
- Jenny Ryan - [e-mail]
- Jenny Ryan is interested in and actively engaged with emerging movements rooted in the shared struggle to reclaim the commons, create public spheres through the cultivation of open spaces, and enable direct democracy through principles of federation and open source or Read/Write culture. Over the past 6 years she has lived in Oakland, California and co-founded the [Sudo Room](https://sudoroom.org) hackerspace, [Sudo Mesh](https://sudomesh.org) / [People's Open Network](https://peoplesopen.net), and the [Omni Commons](https://omnicommons.org). Professionally, she has previously worked as an ethnographer for [Harvard's Berkman Center for Internet & Society](https://cyber.harvard.edu/), interned with the Open Technology Institute's [Commotion Wireless](https://www.commotionwireless.net/) project, worked as Technology Evangelist for [Open Garden](https://www.opengarden.com/) and as Community Outreach Coordinator for [De Novo Group](http://www.denovogroup.org/). She has a BA in Psychology and an MA in Anthropology as well as an MA in Communication.
- Roles: Ethnographer / Documentation / Community Organizer / Finance / Legal
- http://jennyryan.net - https://sudoroom.org - https://omnicommons.org

- Marc juul - [e-mail]
- Marc Juul has worked on community mesh networks since 2013 as a software developer, community organizer, and equipment installer. Marc co-founded the hackerspaces [Labitat](https://labitat.dk/), [BiologiGaragen](http://biologigaragen.org/), [Sudo Room](https://sudoroom.org) and [Counter Culture Labs](http://www.counterculturelabs.org/) and holds a BA in IT Engineering and an MA in Biotech Engineering. His dayjob is lead software engineer at the [BioBrick's Foundation](https://biobricks.org/).
- Roles: Hardware and software development coordinate, firmware development, web development.
- https://juul.io/ - https://github.com/juul - https://github.com/biobricks

- Stephen Whitmore - [e-mail]
- Stephen Whitmore creates and maintains free software to raise the resources of the commons, in order to enable self-determination for individuals & communities, and honour people over profit. Stephen has worked at Google on communication software, Protocol Labs on [IPFS](https://ipfs.io/) (a massively distributed realtime file system), and now at [Digital Democracy](https://www.digital-democracy.org) writing offline-first peer-to-peer mapping software for marginalized indiginous communities in the Amazon. They hold a BA in Computer Science.
- Roles: Developing offline and peer-to-peer capabilities, especially with regards to the app store.

- Grant Gallo - [e-mail]
- Grant is an artist and engineer who is interested in exploring the intersections of technology and culture. He has been working as a freelancer since graduating with a BS in Electrical Engineering in 2016. His recent work includes creative assitant and haunt master for [Driveway Follies](drivewayfollies.com), a free animatronics puppet show that takes place every Halloween in Oakland, CA.
- Roles: Firmware and hardware developer, documentation and content writer

- leez - [e-mail]
- leez is a technologist at the Electronic Frontier Foundation. She is particularly fond of freely-modifiable and redistributable things, and is a social justice advocate that's often found evangelizing worker-run factories or encryption. Lately she also finds pleasure in the ancient art of seafaring, the modern art of flash mobs, phaselocking bullymongs, and trying to make music with that electronic keyboard.
- Roles: Electronics power design: Solar charging and battery management
- https://www.eff.org - https://leez.us - https://getupstreettheater.wordpress.com

- Nic Weidinger - [e-mail]
- A four-circle Venn diagram of Nicolas’ interests might include furniture, open-source technology, science fiction, and critical design. At the center where those four circles intersect is an open discussion about what it means to be human.
- Nicolas works as a researcher and designer at Institute for the Future, a non-profit in California, where he uses forecasting methodologies to explore possible scenarios, and craft speculative objects known as Artifacts from the Future.
- Roles: Enclosure design, experimenting with drone deployment, graphic and video production.
- www.iftf.org - www.wikiseat.org

- John Fitzpatrick - [e-mail]
- Fitz is an electrical engineer and avid tinker. He has spent the last few years developing low cost electronics since graduating Berkeley with an EECS degree. Fitz also works as a museum exhibit technician at the Exploratorium.
- Roles: Electronic Design

# Application Questions & Responses

## Problem Statement: (DONE)
*Describe the issue/problem you are trying to address. (500 characters or fewer)*

When the critical infrastructure that so many of us take for granted goes away, how do we organize ourselves and our communities to respond? If recent ecological disasters have demonstrated anything, it is the inadequecy of existing models and tools to provide efficient allocation of resources, access to emergency communications, and effective coordination of human effort. Few if any solutions exist that are off-grid, affordable, reliable, easily deployed, and openly standardized.
**(486 characters)**

## Solution Statement: (DONE)
*Describe your solution and how it will connect the unconnected. (500 characters or fewer)*

disaster.radio is an off-grid, solar-powered, long-range mesh network built on free, open source software and affordable, open hardware. It can be rapidly implemented in disaster areas by anyone with the capacity to follow instructions, acquire the necessary components, and mount a nominal number of nodes.

The nodes are small, entirely self-contained units running low-bandwidth web apps that anyone can access with a wifi-enabled device. They can be deployed simply by leaving them in the sun.
**(497 characters)**

## Users: (DONE)
*Who will the users of your solution be? How does the design of your solution address those users’ needs? How will it benefit those users? Did you conduct any user research that shaped the design of your solution? (1250 characters or fewer)*

The target userbase of disaster.radio consists of:
* those who live in areas where cellular signal is spotty or nonexistent
* those living in off-grid/low-power conditions
* communities afflicted by natural disasters
* those otherwise entirely bereft of digital communications interfaces

disaster.radio addresses these needs by:
* connecting over the 900MHz band, which makes up for its lack of bandwidth and power with greatly increased range and penetration strength
* requiring no more power than a 6V, 3W solar panel and a battery capable of 3600mAh
* developing applications designed for fast, efficient, and large-scale coordination and allocation of community resources
* providing an affordable, accessible, and abundantly available alternative to a CB radio, cellular service or broadband subscription

User research was conducted by a team member in early 2013 for Tidepools, a decentralized mobile mapping application. First utilized in New York after Hurricane Sandy, Tidepools was principal to the initial conception and design of disaster.radio in the fall of 2013. This ethnographic research consisted primarily open-ended interviews with local residents and organizations and can be found on the [Tidepools wiki](http://wiki.tidepools.co/view/UserResearch).
**(1229 characters)**

## Community/Location:
*Describe the communities, geographic location(s) and/or types of environments in which this solution could be most useful. (1250 words or fewer)*

Given bandwidth limitations, disaster.radio is most applicable for disaster relief scenarios in which existing communications infrastructure is unavailable, damaged, or destroyed. 900MHz radio waves can reach longer distances with deeper penetration than 2.4GHz signals, making it optimal for challenging geographic topologies (such as hills and forests) and environmental conditions (such as fog).

A future goal is to develop a sustainable framework for mobile, lightfooted disaster response teams to deploy to locations in need with materials to build out an emergency communications network.

This design is also useful as a simple communications system for extremely rural/undeveloped, off-grid and/or areas largely unserved by cellular or broadband connectivity.

Communities located in areas of high ecological vulnerability are most likely to find DisasterRadio useful as an emergency communications infrastructure. In particular, First Responders and municipal disaster preparedness organizations may find DisasterRadio a vital component of their emergency resource toolkit.
**(1083 characters)**

## Technical Feasibility: (done?)
*Explain the technical design of your solution. What technical capabilities do you envision a working prototype will have? Are there any technical hurdles or problems that will need to be solved in order to build a working prototype? At what stage of development is your solution currently? (5000 characters or fewer)*

### Radio

disaster.radio nodes communicate with each-other using low-power packet radio. They operate on 865 to 925 Mhz and are capable of communication over distances of up to 5 miles and speeds of up to 300 kbps. The nodes are able to adapt to a variety of environments by switching between modulation schemes including GMSK for high speed short range and Chirp Spread Spectrum for low speed long range. Nodes use an omni-directional antenna for node-to-node communication (no aiming required). The radio transceiver used is the Semtech SX1276. To communicate with existing consumer devices each node is also a WiFi hotspot with a built in DHCP, DNS and Web server. This is accomplished using the ESP8266 WiFi-enabled microcontroller. The WiFi antenna is a high gain semi-directional (120 degree) on-PCB antenna, similar to the antennas used in existing outdoor WiFi equipment such as the Ubiquiti NanoStation. This allows connectivity from between a node on rooftop and e.g. a smartphone inside the building, even through ceiling and insulation materials.

One or more special nodes with Iridium satellites modems connect the mesh to the wider Internet.
### Power

See Power, below.
### Software and routing

An open source firmware running on the ESP8266 provides a complete WiFi hotspot with DHCP server, DNS server and web server. In the first version each disaster.radio node includes three web apps: Collaborative mapping, twitter-style microblogging and check-in (report that you are safe). The programs are all stored on the ESP8266 built-in 4 MB flash memory and loaded as single-page web apps with all of the program logic happening on the client device. After initial load of the web app most program logic takes place on the client device and the node simply acts as a caching router between the WiFi and long-range radio. For the map app a vector tile version of Open Streetmap of the local area is stored in a 128 MB MicroSD card connected to the ESP8266.

The routing is based on a feed-subcription model. There are public and private feeds. Feeds are like twitter users that can be followed. One public feed might be the default public emergency map feed. All nodes are default-subscribed to this feed and anyone can publish to it. Private feeds are feeds that can be subscribed to by anyone but messages can only be published by the owner and may be encrypted. Nodes track subscription requests and remember which nodes they came through. Nodes ACK messages and track which nodes in their vicinity are likely to receive messages based on the transmitting node, then make a decision about whether to relay a message based on this information.

The disaster,radio firmware will integrate with the scuttlebutt peer to peer gossip platform which will allow messages to flow between DisasterRadio and scuttlebutt social networks such as Patchwork. Scuttlebutt provides automatic wifi/ethernet relaying of messages directly between laptops/phones/tablets.
### Mechanical & electrical

The node is constructed as a single PCB that includes all electronic components and wifi antenna on the bottom layer. The top layer of the PCB is covered by the solar panel. The solar panel is always pointed in the opposite direction of the WiFi antenna. If the node is on a rooftop then the WiFi signal is aimed down into the building. If the node is flat against a window then the WiFi signal is aimed into the building. A vacuum-formed or 3D printed 5-sided case is mounted on the bottom of the PCB to cover the part where electronics components are mounted and this case contains a snap-on attachment that allows for a variety of mounting options including hose-clamp for mounting to rooftop vent-pipes or a tensioned suction-cup for window mounting. The omni-directional packet radio antenna is always pointed up.
### Alternate nodes & open standards

We've also designed a hand-held version of the node. This version uses nearly the same electronics and PCB as the standard version, except without the solar panel and large WiFi antenna and with a small clamshell case.

Anyone can develop new disaster.radio nodes. The only requirement for compatibility is that the disaster.radio layer 1 and 2 network protocols are used. Layer 1 is already openly documented and implemented by the Semtech SX1276 chip. Layer 2 will be made available as an open source reference implementation & proposed RFC standard.
### Progress

The electronics, firmware and microblogging web app have been prototyped to the point where the entire basic system works with two nodes. This excludes the wifi antenna and power system which have only been prototyped in less integrated versions than described here. An early simulator for the mesh routing algorithm has been implemented. Our next phase of development will focus on improving and testing the mesh algorithm, and on finalizing the electronics for small-scale production as we prepare for a 50-node field test.
***(4995 characters)***

## Differentiation:
*How does the proposed solution differ from or improve upon existing solutions? What is innovative or novel about the proposed concept or technology? (1250 characters or fewer)*

Ham radio systems, walkie-talkies and WiFi mesh networks solve similar problems. Ham radio disallows sending/relaying of traffic sent by unlicensed operators. Walkie-talkies quickly reach capacity in a disaster, provide no relaying and are real-time only. WiFi mesh networks are more expensive, difficult to set up and require more power but when present can be linked with DisasterRadio to provide a high-speed backbone.

The closest device to DisasterRadio is possibly the GoTenna Mesh - a battery-powered, long-range packet radio that links to a phone over bluetooth and allows text messages to span three times the range of a single node using relaying. DisasterRadio is a fully open source community project, while GoTenna Mesh is a commercial product with neither open network protocols, software or hardware. Unlike GoTenna Mesh, DisasterRadio doesn't need an app to be installed from the internet before it can be used (problematic in a disaster), works on anything with WiFI and a web browser, incorporates solar charging and is designed to survive extreme weather. DisasterRadio costs only ~$40 to produce in quantities as low as 10, whereas the GoTenna Mesh is sold for ~$80 with no solar even after the benefits of scale.

***(1247 characters)***

- **Open/Libre**: Not a company looking to profit off of "disaster capitalism," our mission is to build a truly libre and liberatory technology.
- **Scalable**: Uses an actual mesh routing protocol combined with ssb's decentralized message storage and syncing abilities, and thus able to scale to hundreds of users [vs. eg; GoTenna]
- **Off-Grid**: While other existing solutions require charging over micro-usb, DisasterRadio nodes are powered by the sun, with built-in solar panel and battery backup.
(eg; Serval, OpenGarden, GoTenna, Murmur - are there any solutions that don't?)
- 900MHz vs. 2.4 GHz: http://afar.net/tutorials/900-mhz-versus-2-4-ghz/

## Affordability: (1210 characters, DONE)
*How affordably do you envision the solution could be implemented in a real community? (1250 characters or fewer)*

The solution is designed to be affordable and built by anyone with minimal need for specialized tools. The necessary materials are readily avaliable through various online retailers and could be stockpiled in advance. The estimated cost of a single DisasterRadio node is ~$40. A detailed cost breakdown can be found [on our website](https://disaster.radio/build/). In addition, we provide [instructions](https://disaster.radio/learn/) and [support](https://disaster.radio/connect/) for anyone who would like to build their own DisasterRadio node.

While building a single node is inexpensive, it takes more than one node to make a mesh. The range of a node is largely dependent on the height at which it is deployed. The transceiver we use [has sent a packet over 436 mi](https://www.thethingsnetwork.org/article/ground-breaking-world-record-lorawan-packet-received-at-702-km-436-miles-distance) using a weather balloon to get the node as high up as possible.

In practice, most DisasterRadio nodes will be mounted on roofs of buildings or other structures. Under the very conservative assumption that one DisasterRadio node has a range of 1 mile, then there must be a node every mile. Therefore, covering an area the size of San Francisco, California, at 47.9 sq mi, would require ~48 nodes, with a cost of ~$2000.

***(1210 characters)***

## Social Impact: (1241 characters, DONE)
*How well-tailored is the solution to the needs of the community and users for which it is designed? How will the design of the solution help engage community members in order to maximize utilization? (1250 characters)*

The solution is designed such that anyone who has used a wifi network and a social network will be able to participate without extra training. Rather than spending a lot of time upfront attempting to understand and meet the needs of vastly different communities around the world, our solution makes an effort to be as open and flexible as possible to make it easy for communities to adapt the solution to their own needs. The DisasterRadio app store allows any web programmer to publish new apps or variations and translations on existing apps.

DisasterRadio apps will be integrated with Secure Scuttlebutt, making it possible to use an app even if you can't afford a DisasteRadio node. Messages and updates to apps propgate through the network once a device connects to a node.

One concern is getting communities to use and care about DisasterRadio before a disaster arrives. A geo-spatial limiting feature lets users create messages that don't propagate beyond a specified number of miles from the origin node. This can be used to engage the local community prior to disasters by making it easy to announce local events or have discussions about the neighborhood that aren't available outside of a specified geographical area.
(1243 characters)

Engagement:
-
- DisasterRadio provides a cooler and more affordable alternative to CB radios.
- Given that it's open source, budding and expert software developers alike can build DR applications under challenging power and bandwidth constrainsts.
- Everyone knows how to connect to a wifi hotspot and use a web browser! When the power goes out, the DisasterRadio hotspots will be the only WiFi network available! People won't need to know about it in advance, they'll simply see the hotspot, try to connect and be guided through basic usage.

## Scalability:
*How will the solution be adaptable to a broader set of communities or areas? How scalable is the solution? How will you provide tools and documentation to anyone who might wish to build upon your work or launch a similar effort? (1250 characters or fewer)*

DisasterRadio functions with even a moderate amount of sun, is simple to set up (just place a few nodes in the sun), and is much cheaper than existing alternatives.

The size of a DisasterRadio network is limited by number of messages per second rather than number of nodes. We estimate that a network of only single-channel nodes will have a worst case maximum capacity of at least one message per second. Multiple nodes positioned in close proximity will automatically link over WiFi and become super-nodes that allow the mesh to span multiple channels, increasing potential bandwidth by at least an order of magnitude. Messages are buffered such that while they may be delayed, they are never lost.

The decreasing cost and availability of smartphones, tablets and e-readers has meant that including a screen and input device with each DisasterRadio node makes little sense. Instead, DisasterRadio focuses on providing long range off-grid communication for most existing devices. We considered SMS gateways to extend this to dumbphones, but regulatory overhead, equipment cost, power requirements and impending obsolesence make GSM less than attractive.

DisasterRadio is an open source community project. See Openness section for more.
(1249 characters)

## Openness:
*Mozilla works in the open. How will you document and share your project progress with the community? What documentation and resources have you created to help others understand and leverage your design in their own work? (1250 characters or fewer)*

We have launched [a public website](https://disaster.radio/) with a short video presenting the project to a wide audience. Our group has weekly hacknights that are open to the public at the [sudo room hackerspace](https://sudoroom.org) in Oakland, CA and have open voice calls using [open source VOIP software] every two weeks. We collaborate online using [a public mailing list](https://sudoroom.org/lists/listinfo/disasterradio) and the #DisasterRadio channel on the [Scuttlebutt](https://github.com/ssbc/patchwork) social network. All of our source code and schematics are fully open source and open to collaboration on [our Github repository](https://github.com/sudomesh/disasterradio). [Our wiki](https://github.com/sudomesh/disaster-radio/wiki) contains technical writeups around electronics design choices. We are planning a series of videos and comics that show how to install and use the equipment, and are working toward a draft low-bandwidth packet radio mesh protocol standard to be published through the IETF RFC process.

We have written a software simulator of the hardware API so software can be developed without owning the hardware and are already making the first 30 initial hardware dev kits available for the price of postage.

We will continue to make every part of this project available under Open Source, Creative Commons or similar licenses as appropriate to the type of media, ensuring that all licenses are compatible with the [Free Cultural Works](https://freedomdefined.org/Definition).
***(1247 characters)***

## Previous awards:
*Have you previously been awarded a prize for this solution in any competition? If so, please explain. (1250 characters or fewer)*

The DisasterRadio project has never been awarded any prize.

Members of the Sudo Mesh team received a small [$500 award from the Awesome Foundation](http://www.awesomefoundation.org/en/projects/58613-people-s-open-network) in February of 2016 and a [$1000 grant from the Pollination Project](https://thepollinationproject.org/grants-awarded/marc-juul-peoples-open-network/) in 2014. However these microgrants were for the People's Open Network project and not the DisasterRadio project.

**(304 characters)**

# Off-The-Grid Internet Challenge (Challenge 1 Applicants Only)
## Portability:
*How portable is your proposed solution? Could your solution be easily carried by hand? Please explain. (1250 characters or less)*

There are two types of DisasterRadio nodes:

* Solar node with integrated battery, solar panel, mounting bracket and high-gain antenna
* Pocket node with battery, no solar and smaller antenna

Pocket nodes are about half the size of a pack of cigarettes. They use nearly the same electronics design as the solar nodes. The pocket nodes can be hooked into external USB battery packs or can be clipped directly to a 12V car battery using a car jumper cable.

Both node types are weatherized. All nodes cache all received messages and synchronize the entire backlog of messages between two nodes if they get within bluetooth or WiFi range - so as people move around, meet each other and gossip, so do the nodes in their pockets.

We have developed a prototype system that allows mounting of solar nodes to rooftops using a drone and a small, high-torque motor that tightens a hose clamp around plumbing vent pipes. We estimate that this system could be used by one to two people to cover the entire area of San Francisco in a single day.

In addition, the scuttlebutt software can be installed on phones and laptops and will propagate messages from device to device using WiFi connections even without the presence of DisasterRadio nodes.
***(1236 characters)***

## Power:​ <done but needs editing, 1248 chars, numbers need tweaking (juul), needs editing>
*Could your solution be powered, for hours or days, by a portable power source? Please explain. (1250 characters or less)*

For Solar Nodes, a 4-watt monochrystalline solar panel and a 3200 mAh li-ion battery provide power 24/7 in most scenarios. Nodes detect extreme low-light situations and intelligently schedule necessary down-time at night when traffic is lowest. Variations of the hardware containing double or triple the solar can be easily manufactured for very low-sun areas. DisasterRadio nodes use a MPPT li-ion solar charge controller, a temperature sensor to ensure safe operation, and a buck converter to ensure a very high power efficiency.

Our calculations show that single solar panel nodes can be expected to operate 24/7 even on consecutive overcast days with a day length down to less than 8 hours. This translates to 365 24/7 operation from latitudes of above 50 degrees north to below 50 degrees south, or from Northern Germany to South of New Zealand. Beyond this range down-time may occur in the middle of the night in winter months.

The Pocket Node can be switched between relaying and low-power mode. Low-power mode will run for over a month on a charge, while relaying mode a node will run for around five days.

Our detailed power budget is available [on our wiki](https://github.com/sudomesh/disaster-radio/wiki/Power)
***(1174 characters)***

TODO removed this: The battery is user-replacable and the nodes use the 18650 battery form-factor which means that in the case of battery malfunction, replacement batteries can be scavanged from common consumer electronics such as old laptops

TODO complete power calcuations. Ensure that the above is true by increasing solar panel size. Also, it looks like we forgot to calculate the inefficiencies of charging and discharging. [Charge efficiency for slow charging is 97% ](https://solarcar.stanford.edu/2012/12/panasonic-ncr18650b-cells) and discharging efficiency in situations where the battery doesn't get close to full (winter) is 100% so this shouldn't be a problem.

## Applications: ()
*What information, apps, services, software, etc. will your solution provide access to? Are these designed in a way that maximizes usability for the intended users? (1250 characters or fewer)*

Given the low-bandwidth nature of DisasterRadios, we're designing simple and lightweight applications that can meet the basic needs of users in disaster scenarios:

* Chat / Microblogging - The microblogging app will function as a Twitter-style local broadcast mechanism, where anyone can post to a channel or start a new one. Messages are signed with public keys to verify the sender's identity. A special channel exists for users to mark themselves as safe post-disaster.
* Community Resource Maps - Each node is shipped with a local offline map. The mapping application allows anyone to place and share markers that visualize needs, requests, offers and available resources.
* Disaster App Store - When internet is available the disaster app store allows users to download new apps onto their node. When offline, apps can be copied from a node to, for example, a smartphone and back to another node over WiFi. The app store will allow any web developer to create and publish new DisasterRadio apps. We don't assume to know the needs of all possible users, so we're focused on making modification as easy as possible. This system will use [peer-npm](https://github.com/noffle/peer-npm), a p2p offline-capable code repository.

***(1198 characters)***

Cut - move to Technical Feasibility or minimize?
"All of these applications will run on a protocol similar to Secure Scuttlebutt. Due to the limited bandwidth of the DisasterRadio network, a full implementation of Scuttlebutt cannot be deployed. However, data will be distributed across the network via logs tied to public keys that can be shared and replayed by nearby nodes.
(old protocol notes: https://github.com/sudomesh/disaster-radio-nodemcu/wiki/Protocol)"

## Links
* Video:
* Public Documentation: https://disaster.radio
* Technical Documentation:
* Github: https://github.com/sudomesh/disaster-radio

## Internet Health
Which of the following categories does your solution fit into? (multiple choice, can be all categories)
- Open innovation” - Yes. Means we should enable publishing and inventing without asking permission. And use standard web building blocks, javascript and HTML. Explain how we use standard, accessible technology that others can build on.
- “Digital inclusion” - Yes, given affordability of network, not reliant on all users having broadband or cellular subscriptions?
- “Decentralization” - Yes. Our solution should effectively be a kit that can be taken and reproduced by others
- “Privacy and security” - Yes - messages are encrypted for sender authenticity
- “Web literacy” - hmm...

# Older Notes
## External Links:
- [Wireless Innovation for a Networked Society (WINS) Challenges](https://wirelesschallenge.mozilla.org/)
- [Official Application Guide](https://assets.mofoprod.net/nsf/NSFWINSapplicationguide.pdf)
- [DisasterRadio Github Repo](https://github.com/sudomesh/disaster-radio)

## Roles
- community-based research / story telling (same?)
- jenny, mix, sierk, scott, jorrit(use cases)
- coordinating writing proposal / design doc
- (dominic), jenny, scott, grant, sierk, jorrit (review?)
- grant administration / budget
- jenny, grant?, sierk
- outreach (getting folks to use it)
- dominic : development work in asia, friend with refugee-camps background
- noffle : unsure whether the groups we work with would use this; could ask more knowledgable DigiDem folks
- jenny: standing rock / water protector camps (as active sites for potential community use)
- jenny: i worked at standing rock with lisha sterling from geeks without bounds, would be a good org to collaborate with
- documentation
- juul?, jorrit?,
- hardware/prototyping
- robb, grant, scott, piet?
- firmware
- grant, piet?, scott, cel?
- routing (modelling/protocol)
- dominic, cel?, jorrit (novice)
- software applications
- ssb integration: dominic, mix, cel
- mapeo/osm-p2p-db integration: noffle
- data-mule / guided sneaker-net: jorrit, sierk

## Grant Criteria
All submissions to both challenges will be judged based on the following criteria:
* Technical Feasibility: How feasible are the ideas presented? What are the technical capabilities of the idea or prototype?
* Differentiation: How does the proposed solution differ from or improve upon existing solutions? What is innovative or novel about the proposed concept or technology?
* Affordability: How affordably could the idea/prototype be implemented in a real community?
* Social Impact: How well tailored is the idea or prototype to the needs of the community and users for which it is designed? How will the design of the idea/prototype help engage community members in order to maximize utilization?
* Scalability: How will the idea or prototype be adaptable to broader communities or areas? How scalable is the project? How will the idea or prototype provide tools and documentation to anyone who might wish to build upon it or launch a similar effort?

### Additional Criteria for Off-Grid Internet Challenge (1):
- [Rules and Examples for Off-Grid Challenge](https://wirelesschallenge.mozilla.org/_assets/NSF-OffTheGrid.pdf)

- Portability: How portable is the solution?
- Power: Can the solution be powered, for hours or days, by a portable power source?
- Access: How many users can the solution support and at what distances?
- Applications: What apps does the solution provide access to? Are the apps designed in a way that maximizes usability for the intended users?