Revert subscription functionality refactoring and think of a better refactoring
I think we should revert pleroma!1664 (merged) for a few reasons.
- 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.
- 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
subscriptionand if the client adds
subscription_supported=truein query params, we return the notification as is, if not, we rewrite the type to a regular
- 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
To upload designs, you'll need to enable LFS. More information