listProtocols (nobilis/src/rpc/methods.rs:161) publishes which protocols this daemon
speaks and which are only planned, so a client can grey out the ones that are not there
yet. Its comment says the settings pane already does exactly that.
The settings pane does do that, from a list of its own
(src/renderer/src/components/settings/SettingsPanel.tsx:83), hardcoded with available flags. It never asks the daemon.
Nothing is broken today because the two happen to agree. The exposure is that nothing
makes them agree, and the daemon is the half that knows - a frontend and the daemon it
adopted are built and deployed separately, and either can be older than the other with
nothing looking wrong, which is the reason listProtocols exists at all.
This is the same shape as the IMAGE_EXTENSIONS comment fixed in 2786014: two lists
that must agree, with no mechanism making them.
Found by a September 2026 sweep of all 182 daemon RPC methods against every string
literal in src/. setKickChatMode was excluded on purpose: it is unreachable too, and
says so in its own comment (#167). The methods listed as superseded by that sweep - uploadFile, listDiscordCommands, setMatrixIgnored, openIrcQuery, setMatrixRoomState, unsubscribe - are fine and want nothing.
`listProtocols` (`nobilis/src/rpc/methods.rs:161`) publishes which protocols this daemon
speaks and which are only planned, so a client can grey out the ones that are not there
yet. Its comment says the settings pane already does exactly that.
The settings pane does do that, from a list of its own
(`src/renderer/src/components/settings/SettingsPanel.tsx:83`), hardcoded with
`available` flags. It never asks the daemon.
Nothing is broken today because the two happen to agree. The exposure is that nothing
makes them agree, and the daemon is the half that knows - a frontend and the daemon it
adopted are built and deployed separately, and either can be older than the other with
nothing looking wrong, which is the reason `listProtocols` exists at all.
This is the same shape as the `IMAGE_EXTENSIONS` comment fixed in 2786014: two lists
that must agree, with no mechanism making them.
---
Found by a September 2026 sweep of all 182 daemon RPC methods against every string
literal in `src/`. `setKickChatMode` was excluded on purpose: it is unreachable too, and
says so in its own comment (#167). The methods listed as superseded by that sweep -
`uploadFile`, `listDiscordCommands`, `setMatrixIgnored`, `openIrcQuery`,
`setMatrixRoomState`, `unsubscribe` - are fine and want nothing.
The settings rail's copy went with https://git.salastil.com/Salastil/moho/commit/a23c8bb, when that pane started showing the
protocols somebody has accounts on rather than a hardcoded list with available
flags on it.
This closes the other: ADDABLE in the account picker named five services while the
daemon named seven with a flag on each, and nothing made them agree. The picker now
asks listProtocols.
The window still knows which services it can draw a sign-in form for, and that is
deliberate — it is the half only the window can answer. A protocol the daemon speaks
is not addable from a window with no form for it, and a chip that opens nothing would
be worse than no chip. What gets offered is the intersection, in the daemon's order,
with the daemon's names (which is why XMPP can be called XMPP while its id stays jabber).
Checked against the running daemon: addable comes out irc, matrix, discord, sneedchat, kick, and jabber/slack stay hidden. Two visible consequences — the
picker's order changes, since the daemon lists Matrix second where this file listed
it fourth; and an older daemon that cannot answer leaves the window with the list it
can draw, exactly as before it asked.
Also corrected the daemon's own comment, which claimed the settings pane greys out
unavailable protocols. It does not and now never will — which is the same class of
stale-comment bug this session opened by fixing.
Finished — https://git.salastil.com/Salastil/moho/commit/4d2480d, https://git.salastil.com/Salastil/nobilis/commit/d584492
There were two copies, and they went separately.
The settings rail's copy went with https://git.salastil.com/Salastil/moho/commit/a23c8bb, when that pane started showing the
protocols somebody has accounts on rather than a hardcoded list with `available`
flags on it.
This closes the other: `ADDABLE` in the account picker named five services while the
daemon named seven with a flag on each, and nothing made them agree. The picker now
asks `listProtocols`.
The window still knows which services it can draw a **sign-in form** for, and that is
deliberate — it is the half only the window can answer. A protocol the daemon speaks
is not addable from a window with no form for it, and a chip that opens nothing would
be worse than no chip. What gets offered is the intersection, in the daemon's order,
with the daemon's names (which is why XMPP can be called XMPP while its id stays
`jabber`).
Checked against the running daemon: addable comes out `irc, matrix, discord,
sneedchat, kick`, and `jabber`/`slack` stay hidden. Two visible consequences — the
picker's order changes, since the daemon lists Matrix second where this file listed
it fourth; and an older daemon that cannot answer leaves the window with the list it
can draw, exactly as before it asked.
Also corrected the daemon's own comment, which claimed the settings pane greys out
unavailable protocols. It does not and now never will — which is the same class of
stale-comment bug this session opened by fixing.
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.
listProtocols(nobilis/src/rpc/methods.rs:161) publishes which protocols this daemonspeaks and which are only planned, so a client can grey out the ones that are not there
yet. Its comment says the settings pane already does exactly that.
The settings pane does do that, from a list of its own
(
src/renderer/src/components/settings/SettingsPanel.tsx:83), hardcoded withavailableflags. It never asks the daemon.Nothing is broken today because the two happen to agree. The exposure is that nothing
makes them agree, and the daemon is the half that knows - a frontend and the daemon it
adopted are built and deployed separately, and either can be older than the other with
nothing looking wrong, which is the reason
listProtocolsexists at all.This is the same shape as the
IMAGE_EXTENSIONScomment fixed in2786014: two liststhat must agree, with no mechanism making them.
Found by a September 2026 sweep of all 182 daemon RPC methods against every string
literal in
src/.setKickChatModewas excluded on purpose: it is unreachable too, andsays so in its own comment (#167). The methods listed as superseded by that sweep -
uploadFile,listDiscordCommands,setMatrixIgnored,openIrcQuery,setMatrixRoomState,unsubscribe- are fine and want nothing.Finished — https://git.salastil.com/Salastil/moho/commit/4d2480d, https://git.salastil.com/Salastil/nobilis/commit/d584492
There were two copies, and they went separately.
The settings rail's copy went with https://git.salastil.com/Salastil/moho/commit/a23c8bb, when that pane started showing the
protocols somebody has accounts on rather than a hardcoded list with
availableflags on it.
This closes the other:
ADDABLEin the account picker named five services while thedaemon named seven with a flag on each, and nothing made them agree. The picker now
asks
listProtocols.The window still knows which services it can draw a sign-in form for, and that is
deliberate — it is the half only the window can answer. A protocol the daemon speaks
is not addable from a window with no form for it, and a chip that opens nothing would
be worse than no chip. What gets offered is the intersection, in the daemon's order,
with the daemon's names (which is why XMPP can be called XMPP while its id stays
jabber).Checked against the running daemon: addable comes out
irc, matrix, discord, sneedchat, kick, andjabber/slackstay hidden. Two visible consequences — thepicker's order changes, since the daemon lists Matrix second where this file listed
it fourth; and an older daemon that cannot answer leaves the window with the list it
can draw, exactly as before it asked.
Also corrected the daemon's own comment, which claimed the settings pane greys out
unavailable protocols. It does not and now never will — which is the same class of
stale-comment bug this session opened by fixing.