A Registry For Specialized Message Handlers To Allow a Modular Ecosystem Of Clients, For Which I Did Not Find A Catchy Title

Or #ARFSMHTAAMEOC for short.

#scuttleshell got me (re)thinking about an idea for a modular system of independent, specialized clients. This has certainly been brought up already somewhere in the vast scuttleverse, but I'm not aware of any specific thread. So maybe this one can serve as an #invocation.

Imagine each client could specify to some registry process (that could be scuttleshell, or simply an sbot plugin) which message types it can render and interact with. Additionally, it would register a command that can be used to start it and directly present a UI for a given message hash. This would be done persistently.

You could then build clients that only deal with a very focused set of message types, à la git-ssb web-ui. When a more "general purpose" client encounters a message type it does not know about, it could query the registry whether there is a client installed that can deal with these messages, and if so, it can present a UI to open the message type in this specialized client. Opening the handler would simply happen by sending an rpc to the registry with the message's hash to the registry. The registry would then handle things like client startup (and run-or-raise functionality, see below).

Taken to the extreme, you could have a skeleton client that does nothing but process all messages and delegate to dedicated handler clients. Another possible architecture would be a bunch of specialized clients which all delegate to each other.

That's the whole gist of the idea, but there are a few fun avenues to explore here. For example:

• If a handler for a specific client is already running, it probably should not open a different instance, but the message should be opened in the current instance (also focus needs to switch to it). Could be done by registering itself at startup with the registry process and opening a muxrpc channel between the two, so that it can be notified when it should open a message.
• What sort of information should be registered? Aside from the message type and the command to run the handler, it might also be nice to specify a description of the message type, maybe and icon, etc. This also opens up the issue of localization.
• You could also go further and register a web-component (or something equivalent) to display in a general-purpose client. This is js-specific though, so I'd personally prefer something declarative and language-agnostic.
• There might be multiple clients that can handle the same message types, how should this be dealt with?

In addition to this fairly basic form of modularity, you could do some pretty fancy things like self-describing messages, and dynamically discovering, downloading and running message handlers. But these sort of thing lie further in the future (and come with their own large bag of problems).

This #ARFSMHTAAMEOC of locally registered message-handlers however is fairly self-contained, and not terribly unrealistic. It does somewhat rely on oop-plugins though.

this is something I feel like we've been exploring with the scuttle-* + ssb-schema-* patterns

e.g. ssb-schema-poll is all schema associated with the domain of polls (namely poll and position messages)
meanwhile scuttle-poll is the high level helper methods for common database actions (writing, queries).

When @piet and I started scuttle-poll these two were in one place but things got very unwieldy with the logic of handling versions of polls, so we split it out. I'm really happy with the split in this place.

I've also been thinking about how to register things with scuttle-shell, but more like sets of ssb-* scuttlebot plugins that apps you want to run require. Then scuttle-shell finds the minimal set and starts you up.