kopia lustrzana https://github.com/meshtastic/Meshtastic-Android
get ready for preshared keys
geeksville
rodzic
394fc687c3
commit
eb6ad01c4f
6
TODO.md
6
TODO.md
|
|
@ -4,6 +4,7 @@
|
|||
* when a text arrives, move that node info card to the bottom on the window - put the text to the left of the card. with a small arrow/distance/shortname
|
||||
* all chat in the app defaults to group chat
|
||||
* show connection state on gui
|
||||
* make my android app show mesh state
|
||||
* when notified phone should download messages
|
||||
* at connect we might receive messages before finished downloading the nodeinfo. In that case, process those messages later
|
||||
* investigate the Signal SMS message flow path, see if I could just make Mesh a third peer to signal & sms?
|
||||
|
|
@ -18,17 +19,16 @@
|
|||
* optionally turn off crypto in signal - preferably though see if there is a nice way to be a peer of signal/sms and now mesh.
|
||||
* change signal package ID - if distributing modified binary
|
||||
* good tips on which bands might be more free https://github.com/TheThingsNetwork/ttn/issues/119
|
||||
* make my android app show mesh state
|
||||
* use https://codelabs.developers.google.com/codelabs/jetpack-compose-basics/#4 to show service state
|
||||
* connect to bluetooth device automatically using minimum power, start looking at phone boot
|
||||
* fix BT device scanning
|
||||
* call crashlytics from exceptionReporter!!! currently not logging failures caught there
|
||||
* if nessary restart entire BT adapter with this tip from Michael https://stackoverflow.com/questions/35103701/ble-android-onconnectionstatechange-not-being-called
|
||||
* show direction and distance on the nodeinfo cards
|
||||
* test with oldest android
|
||||
|
||||
# Medium priority
|
||||
|
||||
* test with oldest android
|
||||
* stop using a foreground service
|
||||
* change info() log strings to debug()
|
||||
* use platform theme (dark or light)
|
||||
|
|
@ -39,7 +39,7 @@ Don't leave device discoverable. Don't let unpaired users do things with device
|
|||
|
||||
# Low priority
|
||||
|
||||
* make analytics optional
|
||||
** make analytics optional
|
||||
* also add a receiver that fires after a new update was installed from the play store
|
||||
|
||||
# Done
|
||||
|
|
|
|||
|
|
@ -14,5 +14,8 @@
|
|||
# FIXME, something more like 200? And do fragmentation and reassembly (for larger payloads) at the Android layer, not the esp32 layer.
|
||||
*Data.payload max_size:100
|
||||
|
||||
# 256 bit psk key
|
||||
*RadioConfig.psk max_size:32
|
||||
|
||||
# MyMessage.name max_size:40
|
||||
# or fixed_length or fixed_count, or max_count
|
||||
|
|
|
|||
|
|
@ -114,9 +114,9 @@ message SubPacket {
|
|||
oneof variant {
|
||||
Position position = 1;
|
||||
|
||||
// Times are typically not sent over the mesh, but they will be added to any Packet (chain of SubPacket)
|
||||
// sent to the phone (so the phone can know exact time of reception)
|
||||
uint64 time = 2; // msecs since 1970
|
||||
// Times are typically not sent over the mesh, but they will be added to any Packet (chain of SubPacket)
|
||||
// sent to the phone (so the phone can know exact time of reception)
|
||||
uint64 time = 2; // msecs since 1970
|
||||
Data data = 3;
|
||||
User user = 4;
|
||||
WantNodeNum want_node = 5;
|
||||
|
|
@ -145,7 +145,6 @@ message MeshPacket {
|
|||
|
||||
// Full settings (center freq, spread factor, pre-shared secret key etc...) needed to configure a radio
|
||||
message RadioConfig {
|
||||
// FIXME
|
||||
|
||||
// We should send our position this often (but only if it has changed significantly)
|
||||
uint32 position_broadcast_msec = 1;
|
||||
|
|
@ -157,11 +156,24 @@ message RadioConfig {
|
|||
|
||||
float center_freq = 4;
|
||||
|
||||
uint32 bandwidth = 5;
|
||||
enum ModemConfig {
|
||||
// Note: these mappings must match ModemConfigChoice in the device code.
|
||||
Bw125Cr45Sf128 = 0; ///< Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on. Default medium range
|
||||
Bw500Cr45Sf128 = 1; ///< Bw = 500 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on. Fast+short range
|
||||
Bw31_25Cr48Sf512 = 2; ///< Bw = 31.25 kHz, Cr = 4/8, Sf = 512chips/symbol, CRC on. Slow+long range
|
||||
Bw125Cr48Sf4096 = 3; ///< Bw = 125 kHz, Cr = 4/8, Sf = 4096chips/symbol, CRC on. Slow+long range
|
||||
}
|
||||
|
||||
int32 spread_factor = 6;
|
||||
/// This value replaces bandwidth/spread_factor/coding_rate. If you'd like to experiment with other options
|
||||
/// add them to MeshRadio.cpp in the device code.
|
||||
ModemConfig modem_config = 5;
|
||||
// uint32 bandwidth = 5;
|
||||
// int32 spread_factor = 6;
|
||||
// int32 coding_rate = 7;
|
||||
|
||||
int32 coding_rate = 7;
|
||||
/// A simple preshared key for now for crypto. At first I'm using 256 bit (32 byte) block for the Speck crypto
|
||||
/// but for beta we'll want something more carefully thought through.
|
||||
bytes psk = 8;
|
||||
|
||||
// If true, radio should not try to be smart about what packets to queue to the phone
|
||||
bool keep_all_packets = 100;
|
||||
|
|
@ -198,9 +210,9 @@ message NodeInfo {
|
|||
User user = 2;
|
||||
Position position = 3;
|
||||
|
||||
// Times are typically not sent over the mesh, but they will be added to any Packet (chain of SubPacket)
|
||||
// sent to the phone (so the phone can know exact time of reception)
|
||||
uint64 last_seen = 4; // msecs since 1970
|
||||
// Times are typically not sent over the mesh, but they will be added to any Packet (chain of SubPacket)
|
||||
// sent to the phone (so the phone can know exact time of reception)
|
||||
uint64 last_seen = 4; // msecs since 1970
|
||||
|
||||
// FIXME - some sort of notion of the level of rx power we measured when we last received a packet from this node
|
||||
int32 rx_power = 5;
|
||||
|
|
@ -220,7 +232,6 @@ message MyNodeInfo {
|
|||
/// FIXME - add useful debugging state (queue depths etc)
|
||||
}
|
||||
|
||||
|
||||
// This message is never sent over the wire, but it is used for serializing DB state to flash in the device code
|
||||
// FIXME, since we write this each time we enter deep sleep (and have infinite flash) it would be better to use some sort of append only data
|
||||
// structure for the receive queue and use the preferences store for the other stuff
|
||||
|
|
@ -236,8 +247,6 @@ message DeviceState {
|
|||
repeated MeshPacket receive_queue = 4;
|
||||
}
|
||||
|
||||
|
||||
|
||||
// packets from the radio to the phone will appear on the fromRadio characteristic. It will support
|
||||
// READ and NOTIFY. When a new packet arrives the device will notify? possibly identify instead?
|
||||
// it will sit in that descriptor until consumed by the phone, at which point the next item in the FIFO
|
||||
|
|
@ -250,11 +259,11 @@ message FromRadio {
|
|||
MeshPacket packet = 2;
|
||||
|
||||
/// Tells the phone what our node number is, can be -1 if we've not yet joined a mesh.
|
||||
// No longer sent in fromRadio, instead there is a mynodeinfo characteristic
|
||||
// No longer sent in fromRadio, instead there is a mynodeinfo characteristic
|
||||
// MyNodeInfo my_info = 3;
|
||||
|
||||
/// One packet is sent for each node in the on radio DB
|
||||
// Note: this is no longer in FromRadio because, there is now a bluetooth nodeinfo characteristic
|
||||
// Note: this is no longer in FromRadio because, there is now a bluetooth nodeinfo characteristic
|
||||
// after sending wantnodes that characteristic starts over with the first node in our DB
|
||||
// NodeInfo node_info = 4;
|
||||
}
|
||||
|
|
@ -270,7 +279,7 @@ message ToRadio {
|
|||
//
|
||||
// Rare operations
|
||||
//
|
||||
// All of these have been moved to unique writable bluetooth characteristics
|
||||
// All of these have been moved to unique writable bluetooth characteristics
|
||||
|
||||
/// phone wants radio to send full node db to the phone, This is typically the first packet sent
|
||||
/// to the radio when the phone gets a bluetooth connection.
|
||||
|
|
|
|||
Ładowanie…
Reference in New Issue