Plugin support

[timonsku]

I wanted to ask for some feedback if you would be open to the general idea.
I understand that typically one would say to just create a custom client if you want different features but I'm more thinking about niche interests that just would not warrant their own client and also would not warrant a change in the app itself due to its niche nature.
That would also help with getting spammed with niche feature requests and endless feature discussions if they can just be implemented as a plugin for those who care.

My initial motivation: I'm currently writing a userscript for the browser app that helps a bit with dealing being in a hellthread and still have usable notifications for non hellthread activity without leaving hellthread. That is an insanely niche application and would be a perfect fit for a plugin and I can see a ton more things like this in the future where someone like me would like to spend too much time on a feature that interests maybe 300 people.

Given that the app is based on react-native for all platforms it seems very feasible to support loading externally provided modules via React.lazy "fairly easily" without needing to build crazy boiler plate and needing to write modules for each platform individually.

In a really minimal case one could have a hidden UI in the settings with a big fat "Use at your own risk. Bluesky is not responsible for third-party content" warning label that contains a list of plugins that point to a URL or local folder that contains the plugin code and the app loads these at startup into a scope that would allow a plugin total control. That is chaotic without a bit more management but would likely be fine for an initial power user type feature.

There are of course quite a few implications here like what if a plugin prevents the app from starting and you can't remove it anymore. Needing plugins to stay up to date with app interface changes etc. but those are solvable.
The main question is whether the devs are open to this in concept and would accept a PR.

[pfrazee]

Plugins are pretty challenging. Some issues I can point to off the top of my head:

• I'm told by other companies with plugin systems that apple's app store requires that all plugin authors sign the terms of service. This requires coordination with the app publisher (us).
• Security perimeters need to be designed while also creating a flexible system for extension.
• The performance problem: the tendency for crapware to accumulate and slow down the application in ways that are difficult for us to debug.
• The coordination problem: the app needs to coordinate with plugin developers on all app changes.
• The resale problem: plugin authors get emailed with offers for large sums of cash to sell the plugin. The buyer then typically implements spyware or other forms of malware.

IMO This kind of thing is a really strong candidate for a community fork to try, but wouldn't be a great focus for this implementation right now.

[timonsku]

Apple policy are indeed probably the biggest headache there and something I'm also not entirely familiar with when it comes to plugins. I'll have a dig at that.

In terms of security and performance I would go the Browser extension route, e.g. its up to the user to determine if a plugin is a good or bad idea to use. The only responsibility I see here on the app side would be to educate the user about this risk with a very clear disclaimer. At the end the risk profile for trusting a plugin is the same as trusting any other third party client (in my mind at least).

I would very much start it as a technical pro user kind of thing that is not "easy single click install from a plugin store" kind of deal to keep it from taking off in a too casual manner. Might even need some non-obvious action akin to Android Developer mode activation.

Making such a feature in a very user friendly way is indeed really hard and not something I would suggest anyone attempting in a first pass to see if it makes sense for users.

Right now I'm thinking to start along the lines of what you can do with Tampermonkey in a browser, same way as many Twitter extensions for the browser work, it just would make it for devs a ton easier if you don't have to "inject" yourself and if you can do this also on mobile apps and not just the browser app.

In terms of coordination, a few simple additions like version numbers as auto updated constants would at least make it possible to run compatibility checks before executing in an incompatible environment.
I wouldn't expect much here from the app devs, the majority of tasks can and should probably be handled through the api library. The main issue would be UI I guess, though something that naturally would be somewhat stable down the line. I don't think you would need to coordinate here much in a first stab of the feature, that would become only important if you start to have some load bearing plugins that a large chunk of the user base rely on.

My tldr; I think its totally reasonable for things to be a bit annoying for everyone but the app devs.

Totally get you with the fork though and that is either way probably the best starting point to test the viability. Thanks for the feedback!