Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • P pleroma-meta
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 49
    • Issues 49
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • PleromaPleroma
  • pleroma-meta
  • Issues
  • #2
Closed
Open
Issue created Sep 29, 2019 by rinpatch@rinpatch

Revert subscription functionality refactoring and think of a better refactoring

I think we should revert pleroma!1664 (merged) for a few reasons.

  1. Subscriptions were intended for getting notifications from certain people, but now they are just another timeline. If users want just another timeline for more important follows, they should use lists.
  2. It has it's own set of endpoints even though everything could be done as a mastoapi extension. This results in clients needing to specifically support them, and having to request two endpoints and do merging on the fe. The main reason this is done is so you can flip between subscriptions/regular notifications, however this can be accomplished without a separate endpoint and breaking functionality for unsupported clients. All we need to do is introduce a new notification type called subscription and if the client adds subscription_supported=true in query params, we return the notification as is, if not, we rewrite the type to a regular mention.
  3. They are stored in a separate table now and I honestly don't see any benefit to that, filtering by an indexed type is not at all expensive, however this complicates the existing code that matches on Notification structs

cc @kaniini @lanodan @feld @lambadalambda

Assignee
Assign to
Time tracking