Skip to content

Feature request: allow users to contact project authors directly from the Modrinth web client #5706

@LegendaryGaoZheng

Description

@LegendaryGaoZheng

Please confirm the following.

  • I checked the existing issues for duplicate feature requests
  • I have checked that this feature request is not on our roadmap

What parts of Modrinth is your feature request related too?

Modrinth.com website

Is your suggested feature related to a problem? Please describe.

Summary
I’d like to propose a feature that allows users to contact project authors directly from the Modrinth web interface, in a way that is safe, opt‑in, and easy for maintainers to manage.

Problem / motivation
Right now, if a user wants to ask a question, report a minor issue, or give feedback about a project, they often have to:

  • Search for an external contact method (Discord, GitHub issues, etc.) in the project description.
  • Leave the Modrinth website and switch to another platform.
  • In some cases, there is no clear way to contact the author at all.

This creates friction for:

  • Players/users: harder to ask simple questions (e.g. "Does this work with version X?" or "Is there a plan to support Y?").
  • Authors/maintainers: they may miss useful feedback or bug reports if users don’t know where to go.
  • Modrinth ecosystem as a whole: some communication and feedback happens off‑platform, which makes it harder to build a consistent experience.

Proposed feature (high-level)
Introduce a way for users to initiate contact with a project author directly from the project page on Modrinth, for example:

  • A “Contact author” / “Message author” button on the project page.
  • This opens a simple form (subject + message, maybe optional category like “question/bug/feedback”).
  • The message is then delivered to the author via:
    • An on‑site inbox/notification system, and/or
    • Email/Discord webhook or other configured contact channel.

The key points would be:

  • Opt‑in for authors: authors can enable/disable direct messages for each project, and choose preferred channels.
  • Rate‑limited and moderated: to prevent spam/abuse and protect maintainers.
  • Simple for users: no need to leave Modrinth or hunt for external links.

Optional implementation ideas
I understand there are many possible designs, but here are a few directions that might fit Modrinth’s architecture:

  • Author settings

    • Per‑project setting: “Allow direct messages from Modrinth users”.
    • Configure where messages go:
      • Modrinth internal inbox (if/when available).
      • Email (masked, using Modrinth as a relay to hide the real email).
      • Discord or other webhook endpoint.
  • User experience

    • On the project page, show a “Contact author” button only if the author has enabled it.
    • Use a minimal form:
      • Subject
      • Message body
      • (Optional) Category: Question / Bug / Suggestion / Other
    • Show clear expectations: this is not a guaranteed support channel; response time depends on the author.
  • Abuse prevention

    • Require users to be logged in to send messages.
    • Add rate limiting per sender and per project.
    • Provide authors with:
      • A way to block specific users from contacting them.
      • A simple toggle to disable the feature if it becomes overwhelming.
    • Potentially support a “report abuse” option for problematic messages.

Why this could be valuable for Modrinth

  • Improves the overall developer–user feedback loop on the platform.
  • Keeps more interaction on Modrinth, instead of scattering it across multiple external platforms.
  • Helps smaller or newer projects that don’t have a full Discord server or separate support channels.

Questions for maintainers

  • Is this direction aligned with Modrinth’s long‑term vision (e.g. more on‑platform community features vs. staying minimal)?
  • If yes, would you prefer:
    • A very simple first version (e.g. per‑project contact form that sends email), or
    • A more general “Modrinth inbox/notifications” system that could later be reused for other features?

If the idea is considered reasonable, I’d be happy to help refine the UX and break this down into smaller implementation steps.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions