@lightone Great question! The current form of a plugin is a Ruby gem and quality/security would be up to the community to police similar to other gems. If that becomes an issue specific to Ecko / Magic Stone projects that would be an interesting problem to dig into.

@weex I remember @saper once said that a plugin system for Mastodon might be a very nice and very insecure idea. :) On the other hand, Friendica and Hubzilla isolate a lot of features into plugins. Both projects' core teams archive older plugins that are no longer maintained / supported or were reported to have issues. So, in their case, the security of plugins might be expected to be the responsibility of the core team (aka those who have the right to merge ;) ).

@lightone @saper Yes, as you may know with C4 merging rights are pretty much for adhering to the protocol. Maintainers don't make value judgements on patches but just confirm that they address accurate and valuable problems. </dev laywering>

@lightone @weex I think it would be mostly maintaining like gems, We can increase the community by packaging and maintaining in every aspect like scalability, security and well documented for people to use. When usage increases, community proportionally increases too. Now, only thing that needs is confirming and validating its use.

@Mansh05 @lightone Yes, I really like the way peertube does their plugins through npm with a tag and their website I think does an api call and puts a disclaimer. I'd much rather teach people how to vet their dependencies than to bless anything.