Blessed second-party repositories

[philpax]

Discussion excerpted from Discord:

Franz Renatus — 04/26/2022
But yeah. I'm not huge on Franzbot having to try to determine if a plugin is main or not because 2nd party plugins aren't really handled atm and it's still easy to cheat it or have false positives
We shouldn't tell a dev to fuck off because their not-yet-submitted plugin isn't on main because it builds to devplugins
Or has PR Pending Approval status

Arc/Dis — 04/26/2022
shit take
but I think second party just shouldnt be a thing
it makes things too complicated

Franz Renatus — 04/26/2022
Or just "cache is old" on Franzbot's side

Arc/Dis — 04/26/2022
and is confusing to users
especially when you add a second-party repo in the third-party repos section

wall of text architect — 04/26/2022
I kinda agree with Arc
I think a blessed second-party section is an ok way to handle it

Franz Renatus — 04/26/2022
While Anna might actually like it if we told all Chat2 users to fuck off, that's a bad experience IMO

wall of text architect — 04/26/2022
"these are experimental repos, you can sign up to them to try them out, support will be limited"

Franz Renatus — 04/26/2022
I'd prefer a blessed 2nd party list

Arc/Dis — 04/26/2022
yeah

Franz Renatus — 04/26/2022
Then we could remove them from the 3rd party check

wall of text architect — 04/26/2022
and then you make people (see: devs and people claiming to be devs) hop through hoops to third-party

Arc/Dis — 04/26/2022
just like at tick box to enable testing we could create a tick for "vetted second party repos"

Franz Renatus — 04/26/2022
Expand the troubleshooting blob to say 1st, 2nd, 3rd

Arc/Dis — 04/26/2022
but idk that goat would let himself trust that
wall of text architect — 04/26/2022
and then we're more than able to tell them to fuck off

𓆏 — 04/26/2022
meritocracy

Arc/Dis — 04/26/2022
too security concious

Franz Renatus — 04/26/2022
Ideally, we'd make those decisions on Dalamud and keep Franzbot out of having to validate a pluginmaster

Arc/Dis — 04/26/2022
yeah

wall of text architect — 04/26/2022
yeah

Franz Renatus — 04/26/2022
But if we have 2nd party, then we will for sure have people ask how to apply

Arc/Dis — 04/26/2022
bot shouldnt have to validate shit it should just provide a window to view

wall of text architect — 04/26/2022
if dalamud knows that the user is being naughty it can encode that into the log and franzbot can catch it

wall of text architect — 04/26/2022
"be a trusted community developer who has a good reason to have a blessed repo"
not many people will pass that condition

Arc/Dis — 04/26/2022
Franz Renatus tl;dr of your franzbot license, I can yoink shit as long as I attribute that shit to you?
Im thinking of taking the log parsing code

wall of text architect — 04/26/2022
certified franzcode

Franz Renatus — 04/26/2022
yeah, Franzbot's license is ISC iirc, so you can basically do whatever as long as I'm not liable for it iirc.

I've been thinking about simplifying all the message parsing into modules like I do for FAQs so I can do easier upkeep of them or per-server adjustments without a mess of if statements

Arc/Dis — 04/26/2022
nice
yeah im gonna try to toss together a basic log upload site for otter to post to discord so he can discreetly get dalamud logs from github issues in private and have it attach log as well as post an embed like franzbot
(thanks, @Helios747!)

[KazWolfe]

I added some notes to #22 as well, but I'll bring them there too just so they don't get lost.

The idea of "blessed" repositories are nice, but they come with a few concerns mostly around plugin discoverability. I'd hazard a guess that a pretty significant portion of the plugin population will search for plugins through just "window shopping" and downloading whatever looks interesting to them. Depending on how blessed repositories are implemented, this may remove this discoverability aspect.

I can see a few ways of doing this:

• Blessed Repos are automatically enabled
  This is probably best from the "discoverability" perspective, but plugins in these repositories effectively just become first-party without the same level of security/oversight that are granted in other proposals.
• Blessed Repos are automatically added, but disabled
  This is the most "middle ground" option - they're available in Dalamud, easily enabled, and allow some minor discoverability. From a user perspective, it still feels strange to require someone check a box to enable those things, but it does create a clear distinction and give us ample opportunity to put up warnings that these plugins may not be held to the same rigorous standards as those in mainline.
• Blessed Repos just avoid 3PP "taint"
  Currently, third party plugins are "tainted" with the [3] tag and we don't provide any support to users with these plugins installed/enabled. We could set things up such that blessed repositories just avoid this taint, but still need to be added manually. This is the worst for discoverability, but probably the best from a platform security/safety perspective.

It may also be worth noting that some users running "blessed" repositories may not want discoverability for their plugins; if someone wants their plugin to be visible to everyone it should be in mainline. I'd mostly agree with this notion, but depending on how other DIPs evolve certain classes of plugins (e.g. those that depend on external services or other components) may have no choice but to move to a blessed repo.

[reiichi001]

To me, the primary distinction between a 2PP and a 3PP would be whether or not we will provide support for the plugin and whether or not we'll allow discussion of the plugins in our relevant servers.

The most clear cases are Penumbra and Anna's repo/official plugins, but depending on the implementation, this could see some changes. Perhaps plugins that want to provide support through their own channels would best fit in here, like Sonar?

In terms of discoverability, @KazWolfe brings up some good points, and I think I'd fall most in line with the second, "blessed Repos are automatically added, but disabled." This would ultimately give the repos less automatic discoverability, but would enable users to easily enable them, just like a user currently needs to go into Dalamud Settings in order to enable Testing plugins or to add 3PP.

I'd propose adding a "Repositories" tab in Dalamud Settings for exactly this. First, we'd move our official testing plugin toggle there. Next, we'd have a list of 2PP Repos that a user could enable, with similar warnings. Lastly, we could have our section on custom plugin repos, with the necessary wording that we cannot provide any support for 3PP and that a user should disable them when asking for help in our support channels.

[lokinmodar]

i'd go official/unofficial repos and plugins

[NadyaNayme]

I dislike the idea of "blessed" plugins and think this largely depends on #24 being answered about what exactly are the guidelines to being "first party".

Why are blessed plugins simply not part of the main repo? Is it because a dev is lazy or adamantly against having a Github account? Let them delegate access to someone to manage that aspect then. Don't want to delegate someone as an official liaison? Welcome to being third party/unsupported - better add a support server to your readme.md because Dalamud won't be providing it. Is it because the plugin is against Dalamud first party guidelines? Then we shouldn't be supporting it officially - regardless of who the dev might be. An easy "out" for this last stipulation is to give first party guidelines an "out" for being blessed "as an exception to the general rules" (eg: XivCombo) with reasoning provided. For example - banning XivCombo would just turn people towards all the forks - which is worse than allowing XivCombo. Grandfathering in XivCombo does the least amount of harm even if it would be against Dalamud's current guidelines.

If a plugin is going to be supported it should just be supported and included in the main repo alongside every other plugin. None of this "blessed" nonsense, none of this external repo's business due to dev laziness/distaste of using Github nonsense. Blessed plugins would use the Testing repo like every other plugin.

If the Blessed plugin wants a faster iteration/testing feedback cycle and wish to use their own repo links - they would be de facto treated as third party and their testers should know to go to their provided support channels for support. Just like every other third party plugin. Don't want your testers to have to go to your own Discord server or Github issues? Then test like everyone else with the slower iteration cycles by sending a PR to /Testing/.

This leaves two well-defined categories for plugins:

1. Supported Plugins (main repo plugins - "1st Party")
2. Unsupported plugins (literally all plugins installed through their own repo links without exception including plugins that are also in the main repo - "3rd Party")

Simple and easy to understand.

I'm not sure how this would affect FranzBot's ability to detect 3rd party plugins having to possibly tell between MainRepo/SomePlugin from ThirdPartyRepo/SomePlugin.

E: And "This plugin is large and complex and uses their own Discord server for support." could be solved like how every other partnered Discord servers do it. A locked channel with permanent invite links to partnered servers. Then you refer anyone asking for support to go to the plugin's dedicated server. Still no need for "blessed" status - if it is a supported plugin discussion of it is already allowed it's just the user is more likely to get support through the more-official server. Or we can continue with the practice of redirecting anyone to the proper servers by linking them.

[reiichi001]

Why are blessed plugins simply not part of the main repo?

Here's a perfect example: Penumbra
Because Goat has expressed numerous times that he'd prefer Penumbra to not be on the main repo because it invited modder drama. Despite that, Penumbra is considered a supported plugin and it doesn't make sense to call it an unsupported/third party plugin.

Likewise, it would probably make more sense for plugins that handle their support outside of Goatplace to also be moved to such a section, like Delvui and Sonar. (Maybe others in the future?)

This isn't a matter of dev laziness.

Might I introduce you to the concept of Linux package managers, if you're not already familiar?

The figure above is taken from Ubuntu, which has several official package repositories for different needs and different use cases. In most default installations, only main is enabled, and possibly maybe universe, but as a user, you have to knowing opt in to get restricted or multiverse packages, even through everything is already built and maintained by Canonical.

Technically, we already have a "blessed repo" in the form of the official testing repo. It just happens to share the same PluginMaster URL as main, but that could always change. The concept of adding additional "blessed" repos to Dalamud directly would be that they conform to our plugin guidelines, but are not hosted from the DalamudPlugins repository. As this will most likely be paired with #17 #24 and #28, there are a number of legitimate concerns with trying to force all plugins to be built using a single unified build system, especially for more complex plugins like XIVDeck that needs to bundle additional artifacts with releases. Should it not be able to conform to the build process due to complexity, that should never be a factor for its removal from main, and could also be a contender for a blessed repo.

Or seen another way, we could effectively split the main DalamudPlugins repo into multiple tiers, like "small QOL plugins," "overlays," and "combat modifiers," if we so wanted to, giving a user the access they want to curate which official plugins they may want to see. (Like perhaps streamer-friendly only options)

[NadyaNayme]

I'm actually familiar but honestly it didn't even cross my mind as being an equivalent situation - which it totally is. I think following the Linux model of dubbing the "blessed repos" as Community actually works for Dalamud quite well.

• Dalamud Plugins / Dalamud Supported Plugins ("main" - Enabled by default)
• Community Plugins / Community Supported Plugins ("community" - Must opt in to enable. Support is still provided by the Dalamud Community but is typically done in the plugin's own Discord server which is still a part of the Dalamud Community)
• Unsupported Plugins ('3rd party" - it's in the name. Unsupported and is not part of the Dalamud Community.)

This implicitly states that unsupported/third party plugins are not considered part of the Dalamud Community which is a distinction we already make and stand by but it further hammers it in and excludes them.

...Completely aside - god I hate Canonical's naming scheme. Although I suppose "Arch User Repository" is not much better than "Universe/Multiverse".

[philpax]

That seems pretty reasonable to me. Does anyone want to write the DIP for it?

[philpax]

We've had a back and forth in this Discord thread. Our thoughts on this have evolved and this is the rough consensus we reached:

• Improve our pipeline for introducing new plugins and approval of plugin updates (see Final Comment: Automated build and submit pipeline #17) so that testing through second- and third-party repositories is no longer necessary
• Provide a way to optionally gate plugins that we or their devs consider inappropriate for mainlist for whatever reason. Here are some examples:
  • Penumbra is large, complex and still unstable, but much appreciated by its users. People could opt-in to use it, with the awareness that it is still a work in progress and that Goat Place is unaffiliated.
  • AetherSense Redux is entirely compliant, but we're trying to keep 18+ plugins out of the mainlist. People could opt-in to use it.
• The plugin installer should feature a large, unmistakable help button that will direct you to the most relevant support channel for that plugin. Here are some examples:
  • For mainlist plugins, this is #plugin-issues-help.
  • For testing plugins, this is #plugin-testing.
  • For Penumbra, this is the Penumbra Discord.
• Encourage all existing second-party plugins to move to first-party, with the aforementioned steps making the transition palatable / possible. Anything that does not survive the transition will sadly become third-party.
• The use of third-party plugin repositories will be made more visibly radioactive to the user. Turning it on means you sign away your right to receive any support from Goat Place until you turn it off, and a user doing the "right thing" should never use third-party repositories. If Joe McPlogonUser is adding a third-party repository to use a first-party compliant plugin, something has gone wrong.

The end result of this is that the concept of "second-party repositories" will cease to exist. You are either first-party (reviewed and vetted by us, with optional friction to encourage users to self-select), or you're third-party (officially not our problem).