# Yet Another Cyphal Textual User Interface

**URL:** <https://forum.opencyphal.org/t/yet-another-cyphal-textual-user-interface/2428>\
**Category:** Applications & Usage\
**Created:** [November 12, 2025, 8:27pm UTC](https://forum.opencyphal.org/t/yet-another-cyphal-textual-user-interface/2428 "2025-11-12T20:27:27Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![erik.rainey](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/erik.rainey/32/20_2.png) [@erik.rainey](https://forum.opencyphal.org/u/erik.rainey)\
**Post date:** [November 12, 2025, 8:27pm UTC](https://forum.opencyphal.org/t/yet-another-cyphal-textual-user-interface/2428/1 "2025-11-12T20:27:28Z")

</div>

I’m making a simple TUI for Cyphal which is a little different than `yakut monitor` and I wanted to gather some suggestions beyond what I was already going to do:

- Subscriptions
  - Heartbeats
  - Time Sync (as backup master / peer)
  - diagnostic Records (writes to log)
  - portlist

- Publishes
  - Time Sync (when master)

- Clients
  - GetInfo
  - Transport Statistics

I’m using `textual` the Python framework to render the UI elements in the terminal itself, enabling remote viewing over ssh without forwarding traffic.

> **[GitHub - emrainey/yactui: Yet Another Cyphal Textual User Interface](https://github.com/emrainey/yactui)**
>
> Yet Another Cyphal Textual User Interface

The initial demo has a space for Cyphal/UDP + CAN + Serial all together. Are we still at a point with pycyphal that it can’t operate all 3 transports at once?

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [November 13, 2025, 12:24pm UTC](https://forum.opencyphal.org/t/yet-another-cyphal-textual-user-interface/2428/2 "2025-11-13T12:24:00Z")

</div>

Neat.

A few months back we discussed the idea of dropping the application layer in Cyphal v1.1 completely. Per that proposal, which originated from me but IIRC @scottdixon seemed at least somewhat aligned with, we will have just two standard types: the heartbeat and a generic CRUD input/output service on raw bytes. The v1.0 types will stay as a legacy (them being in the old `uavcan` namespace is a good reminder of their status).

Given that, I think that maybe there is value in replacing special-case pub/sub/clients with generic ones that work on any type?