(Thanks again for Remote Term! Claude helped me write this as I'm trying to implement a !packet command for blorkobot)
The fanout bot dispatcher already computes the canonical MeshCore packet hash for community MQTT uploads (app/fanout/community_mqtt.py:_calculate_packet_hash). It would be useful to pass that same hash into the bot kwargs so fanout plugins can use it without re-fetching raw packets and reimplementing the hash.
Proposed change
Move _calculate_packet_hash to a shared module (e.g. app/path_utils.py).
At the broadcast point that builds the data dict consumed by BotModule._run_for_message (app/fanout/bot.py), compute the hash from the raw packet bytes when available and add data["packet_hash"].
Add packet_hash: str | None = None to execute_bot_code and to the supported kwargs in _analyze_bot_signature so bots can declare it explicitly. Bots using **kwargs get it automatically; legacy bots are unaffected.
Use case
A !packet command that links to public MeshCore packet analyzers (analyzer.00id.net, analyzer.letsmesh.net) for the packet that delivered the command. Currently implemented as a workaround that re-fetches via /api/messages + /api/packets/{id} and reimplements _calculate_packet_hash inline — direct kwarg exposure would cut both the duplication and the extra HTTP round-trips.
(Thanks again for Remote Term! Claude helped me write this as I'm trying to implement a `!packet` command for [blorkobot](https://gist.github.com/statico-alt/a0b3e7b11ee66c4cc5ca97444924ea80))
The fanout bot dispatcher already computes the canonical MeshCore packet hash for community MQTT uploads (`app/fanout/community_mqtt.py:_calculate_packet_hash`). It would be useful to pass that same hash into the bot kwargs so fanout plugins can use it without re-fetching raw packets and reimplementing the hash.
**Proposed change**
- Move `_calculate_packet_hash` to a shared module (e.g. `app/path_utils.py`).
- At the broadcast point that builds the `data` dict consumed by `BotModule._run_for_message` (`app/fanout/bot.py`), compute the hash from the raw packet bytes when available and add `data["packet_hash"]`.
- Add `packet_hash: str | None = None` to `execute_bot_code` and to the supported kwargs in `_analyze_bot_signature` so bots can declare it explicitly. Bots using `**kwargs` get it automatically; legacy bots are unaffected.
**Use case**
A `!packet` command that links to public MeshCore packet analyzers (analyzer.00id.net, analyzer.letsmesh.net) for the packet that delivered the command. Currently implemented as a workaround that re-fetches via `/api/messages` + `/api/packets/{id}` and reimplements `_calculate_packet_hash` inline — direct kwarg exposure would cut both the duplication and the extra HTTP round-trips.
<!-- github-sync-id:4504394780 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
(Thanks again for Remote Term! Claude helped me write this as I'm trying to implement a
!packetcommand for blorkobot)The fanout bot dispatcher already computes the canonical MeshCore packet hash for community MQTT uploads (
app/fanout/community_mqtt.py:_calculate_packet_hash). It would be useful to pass that same hash into the bot kwargs so fanout plugins can use it without re-fetching raw packets and reimplementing the hash.Proposed change
_calculate_packet_hashto a shared module (e.g.app/path_utils.py).datadict consumed byBotModule._run_for_message(app/fanout/bot.py), compute the hash from the raw packet bytes when available and adddata["packet_hash"].packet_hash: str | None = Nonetoexecute_bot_codeand to the supported kwargs in_analyze_bot_signatureso bots can declare it explicitly. Bots using**kwargsget it automatically; legacy bots are unaffected.Use case
A
!packetcommand that links to public MeshCore packet analyzers (analyzer.00id.net, analyzer.letsmesh.net) for the packet that delivered the command. Currently implemented as a workaround that re-fetches via/api/messages+/api/packets/{id}and reimplements_calculate_packet_hashinline — direct kwarg exposure would cut both the duplication and the extra HTTP round-trips.Lemme know if that works for you!