As a lurker, it seems many are interested but we don't really have
critical mass.  I see multiple parts as being necessary to eventual
success at the "world domination" level, and my inclination from
previous software/project experience is to see if they can be separated,
to let progress happen somewhat separately.

For background, I've worked on several ad hoc radio projects (not open
source), done a bit of Amateur Radio packet, and done protocol design
and prototype implementation for networking research projects.  Often
I've organized these projects into phases to allow incremental funding,
with more mature hardware and larger scale at the end.

# big picture

It seems obvious to me that this entire project is text and small
amounts of data only, and no images and no powerpoint files.  And, it's
not about providing IP service.

I'm unclear on if there is any aspect of connecting to internet or not.
It might be good to have a description of which problem is being solved,
separately from the description of approach.   I mostly get it, but
there's a more detailed view of concept of operations about who does
what prep and who wants to talk to who and why.

One issue in my area is how to provide 911 service (call to
police/fire/ambulance) during an extended power failure.  Very few
people have copper pair landlines, almost all have a cellphone, most of
them smartphones, and most people have either VZ FiOS (fiber to the
home) or Comcast (cable).  Comcast fails after a few hours due to
battery-powered equipment on poles, and FiOS works if you can power your
ONT (and router, and wifi).  So it would still depend on individuals
prepping but a bunch of nodes and people with cell phone battery banks
and solar chargers would be at least plausible.  This would lead to
wanting some sort of 911 relay with an authorized chat destination.

The 911 replacement concept could also benefit from some nodes being
internet connected when that works and routing to a computer at the PSAP
(911 call taking location) when that is doable, and staying on lora when
it is not.  But is very likely be way too much to bit off right now.

I am unclear on if chat is 1:1 or group, and how addressing and naming
works.  It would seem there are nodes, and then there are users, with
perhaps different namespaces.  I'm also unclear on encryption.

# protocol

It looks like this is defined separately from the code.  Unusual but
yay!  There have been recent suggestions about allowing some authorized
organizer to control things, and that probably requires configuring
public keys.  Baking control into software (vs protocol) feels like the
wrong approach architecturally.

Scaling is obviously a problem, and it's not clear to me what the story
is.  One idea is to keep the number of nodes manageable (100?) via some
network id, and another is to have some limited hop count for messages.
I will try to read the protocol spec rather than super-skimming.

Maybe 15 years ago "Disruption Tolerant Networks" were popular, which is
store and forward at the network layer.  Of course it doesn't really
matter if this is network or application since that's just a bounday of
convenience for thinking.  It's not clear to me how things are and what
the long-term view is.

Perhaps there should be time sync, perhaps not.  Perhaps only very
rough.

# prototype hardware instructions

Maybe I'm off, but if one gives up power resilience and weather sealing,
a protoboard with an ESP32 and a lora module should be enough.  I guess
that's the TTGO thing, but ESP32 and lora are easy to get many places.

Also, for people in the ham radio world that already have backup power,
putting one of these things high in the house  and hooking up to 12V
solar-charged batteries is not an unreasonable thing to do.

# code

More people could hack on code with the above prototype hardware than
probably do now.  But maybe I'm confused.

I'm unclear on whether the android app for BLE is only useful if one
decides to run BLE and not WiFi, or if it's also an alternative backend
on wifi.   Perhaps it's just the webapp pre-staged rather than served.
Or maybe the webapp comes over BLE?

Regarding the android app: f-droid has
  Version 1.7 (17) suggested Added on 2020-03-08 
and if that's old, would be good to figure out how to update.  If it's
not old, it might be good to release a micro every 6 months to signal
liveness.

I know iphones don't allow Free Software, so I wonder if the only path
is wifi/web.  And if so, how viable (in the US) the concept of no wifi
and using BLE is.  Around me, something that only works on android is
just not going to fly outside of the extreme cypherpunk nerd crowd.  (I
realize other countries have different prevalances.)

Network routing visualization seems maybe missing and would help a lot
in understanding an actual network.

# geoprivacy

I realize there is a map notion, which is fine, but I think it's
important to keep the main path of the network not needing to publish
coordinates.  I find not wanting to publish location to be correlated
with a willingness to spend time prepping.  Maybe that's ok now.

# emulator

It would be nice if it were possible to run the code with an emulated
radio that has a link that acts like lora but is tunneled over the
internet to somebody else.   Then the people working on disaster.radio
could talk to each other.   I am not sure how hard this would be and if
it's worth it though.

# power, range and scaling data

It's really unclear to me how much power gets used doing what, and if
nodes can somehow do fair-share of routing vs high nodes using all their
batteries.  But maybe high nodes should just have more power/battery and
then it's all good.  It would be nice to have some measurements.

It would be nice to have some published anecdata about range.  In the US
we're talking 915 I think, for Part 15 compliance, but it would be nice
to understand how being able to close a 5W UHF FM link relates to lora
links.  (Yes, I know I should just buy a few and try some things; it's
on my todo list.)

It would be nice to have reports of network sizes and how they work.  In
various research projects, it was often a big deal to get the network
size up, and I've done demos with 20 wireless nodes, 50 wireless nodes,
and 100 wired nodes.  Has anyone built a diaster.radio network more than
10?  25? 50? 100?

# deployable hardware design

Next is nerd-replicable deployable hardware, and the more it can be buy
commodity parts (even if it's plastic food containers that can be hung
in a tree with rope), the better.  The key point is a set of recipes.

Later comes purchasable hardware.  I suspect that an open hardware
design and mature software will lead someone to build and sell nodes, so
to me this is the last thing to worry about.

I hope at least some of this ranting is helpful.

Greg