A collection of some thoughts about Packet Radio. Not anticipated for direct consumption but I might find it useful to refer to them in future. ====== Security ====== ===== Authentication ===== Currently authentication in packet radio is somewhat lacking. Passwords are sent in the clear over RF and could be intercepted by anyone. One exception is BPQ's SYSOP password tool that sends a string of characters over the air similar to a [[https://en.wikipedia.org/wiki/Cryptographic_nonce|nonce]] which are then entered into a tool to generate a one time password that can securely be sent back over the air. Whilst this works I'd love to see a more generalised method, and I'd suggest the use of [[https://en.wikipedia.org/wiki/Time-based_one-time_password|Time-based One Time Passwords]] which are supported in apps such as Google Authenticator and Authy. These would allow secure one-time passwords without breaching any rules on encryption. ===== Signing ===== In current packet radio usage there's no way of confirming that a message that has potentially been relayed through 10s of nodes and hasn't been tampered with in transit and actually originates from the person that allegedly sent it. It would be great if we could utilise public key cryptography like [[https://en.wikipedia.org/wiki/Pretty_Good_Privacy|PGP]] to sign and validate messages. ====== Visual presentation ====== It's no secret that I'm a big fan of [[https://en.wikipedia.org/wiki/Viewdata|Viewdata]] a system used in the early 80s. It's very similar to Teletext but would operate over a 1200/75 baud modem attached to a phoneline, allowing users to //send// data as well as receive it. I think it's a great candidate to send data over packet radio with slightly richer formatting whilst still maintaining minimal overheads, and the method of entering numbers to access different pages also lends itself to packet. For an example of how it can work see [[https://www.youtube.com/watch?v=3wc62ZD7ZWI|G6AML's Youtube Video]] ======= App Improvements ====== ====== General ====== * It would be great if things were easily "plugable" to support different compression and encoding etc ====== Routing ====== I would like to: * Distribute routes with a max-forwards parameter, limiting them being distributed more than X hops * Force a route, but still over an L4 protocol? * Add "communities" similar to BGP, that can be used to flat things (blackhole etc) * Include a parameter to indicate if the route is over IP, HF etc * Include a VLAN type indication. Perhaps a route is for management only. ====== Chat ====== The chat built into BPQ is fairly basic and missing some features that would significantly increase usability. I would like to see the following improvements to a new chat application: * Some visual clue that a sent message has been acknowledged, or rejected. Currently it appears like a message has been sent successfully, but might not have been acked by that chat server. * Timestamp / Sequence sent with message so they can re-ordered ====== BBS / Mail ====== The BBS built into BPQ has basic POP3 functionality but most web based email clients etc expect IMAP. It would be ideal if IMAP functionality could be added one way or another, to support new clients and also add functionality like marking a message as read. I've looked at ways to do this without changing BPQ and there's no obvious easy solution. emails could be fetched via POP3 and inserted into IMAP, but if this is a one way process then deleting and reading messages won't get synchronised back to BPQ. I considered trying to write some API but BPQ doesn't really lend itself to such things. I suspect the answer might be to write a new BBS.... ======= New Software ====== * Packet Parse - Something that "sniffs" a KISS interface and prints the headers and body as something human readable, with support for NET/ROM - A poor mans Wireshark. * Mailing List Server - It looks like [[https://www.f6fbb.org/fbbdoc/fmtmulti.htm|Mailing Lists]] have been a thing. Maybe we should create an up to date version?