Moving Nexus intergration to plugin system so other Mod websites can make plugins.

[Kiaos]

Mod Organizer 2 currently treats Nexus Mods as a first-class, hard-coded integration across core logic, UI, authentication, and download workflows.

While this works well for Nexus, it makes it difficult to support additional mod repositories without either:

Forking MO2, or

Re-implementing large portions of the Nexus integration logic for each new site.

As a result, adding support for other popular mod ecosystems (e.g. Thunderstore, ModDB, GitHub Releases) has a high development and maintenance cost.

Proposed Goal

Introduce a generic “mod repository provider” abstraction in MO2 so that Nexus becomes one provider implementation rather than a hard-coded dependency.

This would:

Preserve existing Nexus behavior unchanged

Reduce technical debt in the long term

Allow future repository integrations to be implemented with significantly less effort

Enable repository support via plugins once the abstraction exists

Non-Goals (Important)

This proposal explicitly does not aim to:

Redesign the UI

Remove or replace Nexus functionality

Change any existing Nexus workflows

Immediately add new repositories

The intent is purely architectural and incremental.

Anyone else that wants to work on this or if you have input please post in this issue.

[AnyOldName3]

Note that this was something Tannin started in at the end of the MO1 era, and was what https://github.com/ModOrganizer2/modorganizer-uibase/blob/master/include/uibase/ipluginmodpage.h was supposed to turn into. Obviously, it was never finished. There might be things already on the tracker for this from over a decade ago.

[Kiaos]

Repository Provider Plugin Architecture - Implementation Outline

Context

This refactoring addresses #2319 and builds upon over a decade of community requests (#46, #977, #1169, #1545, #2286).

Historical Note: Tannin started this work at the end of MO1 with IPluginModPage, which was never completed. This proposal builds on those foundations.

Goals

✅ DO:

• Abstract Nexus integration into a generic "repository provider" plugin system
• Allow Nexus to become one plugin implementation among many
• Enable third-party repository plugins (Thunderstore, ModDB, GitHub, etc.)
• Maintain 100% backward compatibility with existing Nexus functionality
• Preserve all current user workflows

❌ DON'T:

• Change any existing UI/UX
• Remove or replace Nexus features
• Force immediate migration of existing code
• Break existing plugins

Proposed Architecture

1. Core Interface: IModRepositoryProvider

Extend or replace IPluginModPage with a comprehensive provider interface:

class IModRepositoryProvider : public IPlugin
{
  // Repository identification
  virtual QString name() const = 0;        // "Nexus Mods"
  virtual QString identifier() const = 0;  // "nexus"
  
  // Capabilities (repositories can opt-in to features)
  virtual bool supportsAuthentication() const = 0;
  virtual bool supportsEndorsements() const = 0;
  virtual bool supportsTracking() const = 0;
  virtual bool supportsDownloads() const = 0;
  virtual bool supportsUpdateCheck() const = 0;
  
  // Bridge creation (for API interactions)
  virtual IModRepositoryBridge* createBridge(const QString& subModule = "") = 0;
  
  // Authentication (optional)
  virtual bool isAuthenticated() const;
  virtual void authenticate();
  
  // Settings UI (optional)
  virtual QWidget* createSettingsWidget(QWidget* parent);
  
  // URL/Download handling
  virtual bool handlesURL(const QUrl& url) const = 0;
  virtual void handleURL(const QUrl& url);
};

2. Repository Manager

Centralized manager for all repository providers:

class RepositoryManager : public QObject
{
  // Register/query providers
  void registerProvider(IModRepositoryProvider* provider);
  QList<IModRepositoryProvider*> providers() const;
  IModRepositoryProvider* getProvider(const QString& identifier) const;
  IModRepositoryProvider* getProviderForURL(const QUrl& url) const;
  
  // Bridge creation
  IModRepositoryBridge* createBridge(const QString& providerIdentifier);
};

3. Nexus as Plugin

Refactor existing Nexus code into NexusRepositoryProvider plugin:

• Wraps existing NexusInterface, NXMAccessManager, NexusBridge
• Initially lives in main codebase, can be moved to separate plugin later
• Implements all current Nexus functionality
• Zero functional changes for users

Implementation Phases

Phase 1: Foundation (No Breaking Changes)

Goal: Create abstractions without changing existing behavior

• Create IModRepositoryProvider interface in uibase
• Create RepositoryManager singleton
• Implement NexusRepositoryProvider wrapping existing code
• Register Nexus provider in RepositoryManager
• All existing code continues to work as-is

Success Criteria: Tests pass, Nexus works exactly as before

Phase 2: Core Integration Points

Goal: Make MO2 core repository-agnostic

• Update OrganizerCore::createNexusBridge() to use RepositoryManager
• Update DownloadManager to be repository-agnostic
  • Remove repository != "Nexus" hard-coding
  • Query provider for file info instead
• Update URL handling to check all registered providers
• Update ModInfo to store generic repository identifier

Success Criteria: Core code doesn't mention "Nexus" explicitly

Phase 3: UI Generalization

Goal: Make UI support multiple repositories

• Create generic repository settings framework
• Allow providers to inject settings widgets
• Update mod info dialog to show repository-specific info
• Update download metadata UI

Success Criteria: UI adapts to available providers

Phase 4: Plugin System Integration

Goal: Enable third-party repository plugins

• Document IModRepositoryProvider API
• Create example repository provider plugin
• Test with existing community plugins:
  • Thunderstore plugin
  • modl:// handler
• Update plugin loading to discover repository providers

Success Criteria: Third-party plugins can implement full repository support

Phase 5: Settings & Authentication

Goal: Generic credential management

• Create generic credential storage system
• Migrate Nexus API keys transparently
• Provider-specific authentication flows

Success Criteria: Users don't need to re-authenticate

Key Technical Decisions Needed

Decision 1: Interface Design

Options:

• A) Extend existing IPluginModPage interface

  • ✅ Builds on Tannin's original design
  • ✅ Interface already exists
  • ❌ Limited functionality (no auth, endorsements, etc.)
  • ❌ May need significant breaking changes

• B) Create new IModRepositoryProvider interface

  • ✅ Clean slate, purpose-built for our needs
  • ✅ Can incorporate lessons from IPluginModPage
  • ✅ Better capability detection
  • ❌ Abandons existing interface

Recommendation: Option B - Learn from IPluginModPage but create purpose-built interface

Decision 2: Nexus Plugin Location

Options:

• A) Keep Nexus integration in main executable initially

  • ✅ Less disruptive migration
  • ✅ Easier to refactor incrementally
  • ❌ Still somewhat coupled

• B) Move to separate plugin immediately

  • ✅ True separation
  • ❌ More risky, larger change
  • ❌ Build system complexity

Recommendation: Option A - Refactor in-place first, extract later if desired

Decision 3: Metadata Storage

Question: How to store repository-specific IDs (Nexus mod ID vs Thunderstore namespace)?

Options:

• A) Generic key-value metadata store per mod
• B) Repository identifier + generic ID field
• C) Provider-specific metadata files

Needs Discussion

Backward Compatibility Guarantees

1. Existing Plugins: All plugins using createNexusBridge() continue working
2. User Settings: Nexus API keys and settings migrate transparently
3. Mod Metadata: Existing mod info files remain valid
4. User Workflows: Zero behavior changes for Nexus users
5. Plugin API: Existing interfaces remain functional (may be deprecated)

Testing Strategy

• Unit tests for RepositoryManager
• Integration tests with mock repository provider
• Full regression testing of Nexus functionality
• Test plugin loading/unloading
• Test with community plugins (Thunderstore, etc.)

Related Work & Resources

Existing Experimental Work:

• isanae/modorganizer-repository_nexus - Experimental Nexus plugin
• ZashIn/modorganizer-thunderstore - Thunderstore WIP
• eddoursul/modorganizer-modlhandler - modl:// protocol

Issue #2286 has comprehensive requirements analysis for:

• Download handling
• Metadata parsing
• Update checking
• Installation workflows

Next Steps

1. Gather Feedback: Post this outline for community/team review
2. Finalize Decisions: Resolve key technical decisions above
3. Create PRs: Implement Phase 1 (foundation)
4. Iterate: Gather feedback, adjust approach
5. Document: Create plugin developer guide

Questions for Discussion

1. Should we extend IPluginModPage or create new IModRepositoryProvider?
2. How should repository-specific metadata be stored?
3. Should authentication be per-provider or have a centralized system?
4. What level of feature parity should we require (e.g., must all repos support updates)?
5. Should we have a "primary" repository concept, or treat all equally?
6. How do we handle repositories without APIs (scraping, manual entry)?

---

Looking for Feedback On:

• Overall approach and phasing
• Technical decisions above
• Missing requirements or edge cases
• Interest in contributing to specific phases

Related Issues: #46, #977, #1169, #1545, #2286