Client Plug-in API

(#1213) Feature Shipped plugins

Problem

If there is any functionality that someone would like to see in the client, they would presumably have to either petition its implementation (which would be unreasonable if it is an accessibility or QOL tool catering to a minority demographic) or outright maintain a fork of the client to develop and implement their feature. I think it would be beneficial to find a middle-ground.

Proposed solution

Stoat's old Revite client had a very interesting idea in the form of the experimental plugin API which (while not especially great), served as a means of building and installing plugins in the primary client which could modify or provide extra client behavior. I think this sort of thing can be extremely useful if designed carefully, as it could potentially defeat the purpose of many third-party bots that users have to rely on being constantly online. This sort of thing is also extremely popular and well-liked in Discord's third-party client communities like Vencord and BetterDiscord for good reason.

Notes (optional)

I'm mainly looking at this from the perspective of having commissioned and assisted in the development of the Revolt Masquerade plugin, which allowed plural users and roleplayers to make use of Stoat's "masquerade" permission to send per-message profiles, akin to this discussion post. This sort of functionality would let Fluxer developers comfortably add useful functionalities on the backend and API without the added pressure of needing to fully implement everything into the client so anyone can use it.

Comments

Sign in with Fluxer to comment and vote.

No comments yet.