-
Notifications
You must be signed in to change notification settings - Fork 408
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[pre-HIP] High level LongFi overview #1
Comments
I like this segmentation between LoFi and HiFi; this was nuance I had trouble putting words on and I think these will stick :) That being said, I want to understand "Should LongFi specify any of the HLP? Tentative No". This simply means we don't specify/restrict HiFi because we can't thanks to the trustless network of hotspots? That being said, we can and should provide a reasonable implementation of the HiFi/HLP because it's unreasonable to use LoFi without some notion of authentication between device and router (as alluded to in Q3/Q4). Does that line up with your direction? |
Can you define what is meant by the "High Level Protocol"? |
Correct, but I am not convinced that I am correct one way or the other.
Yep. |
I replaced all instances of |
Pretty please, keep comments and questions coming. Unlike a real RFC where the thing is done and only critical comments are wanted, this issue is a malleable white-board. |
I actually think there's a |
Like, if I want to use ROT13 encryption to talk to my AVR based shit board, I don't think we need to stand in their way as long as they're willing to pay for the LowFi packets. |
Added myself as an author, let me know if this is appropriate or not - I'm just here to help, I’m happy to conference call to talk through the changes. -Fixed a bunch of spelling and typo errors - might have added some more, hope not! -Changed several sentences to be concise, you may want to check the spelling again, I've been at this a while. -Added roles and subgroups to improvements under summary it is mentioned further through but not up there where it should have been -Updated motivation wording to include statements from Tony Smith from 3rd March 2022 community zoom meeting with Helium reprehensive, also to recognise existing work -Updated Stakeholders removed a title to keep with formatting of HIP -Added how improvement will be achieved to first line of the detailed explanation, note this will mean the proposal is the create the Terms of Reference using the details as the minizine baseline rather then make the proposal the TOR. -Updated recommendation to include makers and consumers rather than just operators (following Tony Smith's words as for mentioned). -Removed part about contracts, not sure what you mean but I’m not legal so if it’s something on that… -We may want to discuss the definition of an independent chair! -Removed "and remaining committee members" from decision on conflict of interest, the TOR will have to describe what occurs if the chair has a conflict of interest. -Added quorum statement, feel free to change and look at proxy use. -Updated titles to use the role words instead of expected to be more consistent with a TOR and the improvements mentioned in summary. -Added to chair and member roles some nominal common TOR ones -Updated Drawbacks statement, no I didn’t add one about my conversation with our friendly discord community 😉 -Added to Rationale on reduced confidence statement as per a few comments from Helium discord. -Added to the todo for out of scope and an unresolved question. Let me know if you can answer the unresolved question as IoT has a lot of inherent security issues.
* Initial checkin of HIP LoRaWAN Committee * inital check-in of detailed committee guidelines * minor changes * minor changes * minor changes * incorporate early feedback * incorporate early feedback * incorporate minor feedback * incorporate early feedback * incorporate early feedback * Gathered feedback #1 and my feedback on the HIP Added myself as an author, let me know if this is appropriate or not - I'm just here to help, I’m happy to conference call to talk through the changes. -Fixed a bunch of spelling and typo errors - might have added some more, hope not! -Changed several sentences to be concise, you may want to check the spelling again, I've been at this a while. -Added roles and subgroups to improvements under summary it is mentioned further through but not up there where it should have been -Updated motivation wording to include statements from Tony Smith from 3rd March 2022 community zoom meeting with Helium reprehensive, also to recognise existing work -Updated Stakeholders removed a title to keep with formatting of HIP -Added how improvement will be achieved to first line of the detailed explanation, note this will mean the proposal is the create the Terms of Reference using the details as the minizine baseline rather then make the proposal the TOR. -Updated recommendation to include makers and consumers rather than just operators (following Tony Smith's words as for mentioned). -Removed part about contracts, not sure what you mean but I’m not legal so if it’s something on that… -We may want to discuss the definition of an independent chair! -Removed "and remaining committee members" from decision on conflict of interest, the TOR will have to describe what occurs if the chair has a conflict of interest. -Added quorum statement, feel free to change and look at proxy use. -Updated titles to use the role words instead of expected to be more consistent with a TOR and the improvements mentioned in summary. -Added to chair and member roles some nominal common TOR ones -Updated Drawbacks statement, no I didn’t add one about my conversation with our friendly discord community 😉 -Added to Rationale on reduced confidence statement as per a few comments from Helium discord. -Added to the todo for out of scope and an unresolved question. Let me know if you can answer the unresolved question as IoT has a lot of inherent security issues. * Minor layout fix Bullet points incorrect * add LoRa Alliance Bylaws Reference * inital outline of LoRa Class-C HIP * Delete Class-C HIP - no longer relevant due to HIP-70 * checkin inital HIP-70 alternative proposal * undo checkin inital HIP-70 alternative proposal * checkin inital HIP-70 alternative proposal * minor feedback * minor feedback added * minor feedback added * added feedback co-authors * Update 0071-scaling-helium-transparently.md Correct typos previously identified. Have NOT changed diagrams per my notes, only MarkDown. * Update 0071-scaling-helium-transparently.md New PoC data reporting diagram - correct "Decentralized Oracales" Co-authored-by: Leo Gaggl <leo@g3i.com.au> Co-authored-by: Leo Gaggl <leogaggl@users.noreply.github.com> Co-authored-by: Matthew Smith <matt@smiffytech.com>
Before writing the first draft of LongFi, I'd like for this issue to serve as a place to ask a few high-level questions to help steer the direction of the protocol. It's become apparent that what we've been calling LongFi is two separate protocols, LowFi and HighFi. That leads to some questions. Please do not consider the answers below as gospel but as possibilities or outright bad ideas.
Glossary
LowFi: a low-level
device ⟷ hotspot
protocolHighFi: a high-level
device ⟷ router
protocolACK: a small and possibly data-free packet sent to acknowledge the receipt of a data-bearing packet
A → B
: a data-bearing packetA ← B
: ACKUplink-ACK: a
device ← router
ACK in response to an uplink packetDownlink-ACK: a
device → router
ACK in response to a downlink packetQ1: Should LongFi specify any of the high-level protocol (HighFi)?
Initial offline discussions lean towards no if possible.
RATIONAL: Not specifying HighFi keeps LongFi simple and easy for third-parties to implement and understand. Additionally, it removes some risk of early decisions leading to unintended consequences.
Q2: What must LongFi specify to support HighFi?
It depends on the semantics of HighFi.
Q3: Does LongFi have the notion of connections (or sessions)?
It appears that LongFi requires sessions from device to its organization's router to operate in a trustless network.
Q4: If LongFi has sessions, how will that work with multiple hotspots?
Sessions are between a device and its organization's router, not with any hotspot in particular. It doesn't matter which Hotspot relays a device packet to a router.
Q5: What about downlink packets?
At a minimum, downlink packets are required for Uplink-ACKs.
Q6: What packets get ACK'd?
Uplink-ACKs are optional, and the conditions on which they are sent are HighFi/application-specific. For example, a device/user/org may only care about receiving Uplink-ACKs occasionally or in response to uplink packets containing critical payloads.
Downlink-ACKs seem to be mandatory. Downlink-ACKs are the only way for a router to detect malicious hotspots who charge for downlink packets but purposely drop them on the floor [1].
TODO
Explain some things that came up at lunch today:
The text was updated successfully, but these errors were encountered: