Andymck/verify hb cell type #379
Conversation
andymck
force-pushed
the
andymck/verify-hb-cell-type
branch
from
1ac4ca2
to
16ada19
Compare
| } | ||
|
|
||
| message gateway_info { | ||
| // The public key binary address and on-chain identity of the gateway | ||
| bytes address = 1; | ||
| // The gateway metadata as recorded on the blockchain | ||
| gateway_metadata metadata = 2; | ||
| // the asserted device type of the gateway | ||
| device_type device_type = 3; |
There was a problem hiding this comment.
why did you move this out of gateway_metadata?
There was a problem hiding this comment.
when I added this originally, i had thought the device type was added upon assertion of the gateway. That is not the case and device type will always be available whether the gateway is asserted or not. Metadata currently only holds the location field which is obviously only set upon assertion and mixing in optional and always available fields in the same sub struct doesnt sit well.
There was a problem hiding this comment.
the device metadata is also always available right? It's only the individual fields that are modified with assertions. And perhaps I'm misunderstanding but I thought the device type was going to go on chain as part of metadata?
There was a problem hiding this comment.
Internally metadata is an Option which makes accessing fields a lil more cumbersome but you are right in that the device_type is onchain as part of the metadata. I can move it back, no big deal
There was a problem hiding this comment.
After discussing we decided to revert/keep the device type in the top-level GatewayInfo. Key reasons were:
- it's similar to
is_full_hotspotin that it should be an intrinsic aspect of the hotspot instead of a fungible element like asserted location - it makes the handling of the data easier with fewer nested "options"
jeffgrunewald
force-pushed
the
andymck/verify-hb-cell-type
branch
from
634f360
to
867ca9c
Compare
No description provided.