Mastodon 4.3 introduced notification requests / junk. Users set a policy for rejecting notifications, like if the actor is a new account or doesn't follow you etc. and when they send you a notification, it ends up in a dedicated space where you can see them, dismiss them or accept them.
This PR adds the whole feature: Dedicated space for them, approving/declining and policy settings
This is undocumented so far, but I did write the spec to keep track of it myself, in case any other fellow fedidevs need it:
Policy Entity
Attributes:
filter_not_following : Bool
Whether you are filtering people you don't follow
filter_not_followers : Bool
Whether you are filtering people that do not follow you
filter_new_accounts : Bool
Whether you are filtering accounts created the past 30 days
filter_private_mentions : Bool
Whether you are filtering private mentions unless the author is replying to you or you follow them
summary : SummaryEntity
Stats of the filter inbox
Summary Entity
One account can send you multiple filtered notifications, so they don't always match.
Attributes
pending_requests_count : Int
Amount of filter accounts
pending_notifications_count : Int
Amount of filtered notifications
Request Entity
Attributes:
id : String
Request ID
created_at : String
DateTime of the request creation
updated_at : String
DateTime of the request update (this is not null if the request hasn't been updated, but it will match created_at)
notifications_count : String
The amount of notifications the request includes (remember, 1 request = 1 user but >= 1 notifications). This is a string cast from an int, e.g. "2"
account : Account
The account that made the request
last_status : Status
I assume this is option but haven't done a thorough test. The last status attached to the request.
GET/api/v1/notifications/policy
Call this when you need to check if there's any filtered notifications or get the active policies.
Mastodon 4.3 introduced notification requests / junk. Users set a policy for rejecting notifications, like if the actor is a new account or doesn't follow you etc. and when they send you a notification, it ends up in a dedicated space where you can see them, dismiss them or accept them.
This PR adds the whole feature: Dedicated space for them, approving/declining and policy settings
This is undocumented so far, but I did write the spec to keep track of it myself, in case any other fellow fedidevs need it:
Policy Entity
Attributes:
filter_not_following
:Bool
Whether you are filtering people you don't follow
filter_not_followers
:Bool
Whether you are filtering people that do not follow you
filter_new_accounts
:Bool
Whether you are filtering accounts created the past 30 days
filter_private_mentions
:Bool
Whether you are filtering private mentions unless the author is replying to you or you follow them
summary
:SummaryEntity
Stats of the filter inbox
Summary Entity
One account can send you multiple filtered notifications, so they don't always match.
Attributes
pending_requests_count
:Int
Amount of filter accounts
pending_notifications_count
:Int
Amount of filtered notifications
Request Entity
Attributes:
id
:String
Request ID
created_at
:String
DateTime of the request creation
updated_at
:String
DateTime of the request update (this is not null if the request hasn't been updated, but it will match
created_at
)notifications_count
:String
The amount of notifications the request includes (remember, 1 request = 1 user but >= 1 notifications). This is a string cast from an int, e.g.
"2"
account
:Account
The account that made the request
last_status
:Status
I assume this is option but haven't done a thorough test. The last status attached to the request.
GET
/api/v1/notifications/policy
Call this when you need to check if there's any filtered notifications or get the active policies.
Returns:
PolicyEntity
Example:
PUT
/api/v1/notifications/policy
Update policies.
Returns:
PolicyEntity
Params:
filter_not_following
:Bool
[OPTIONAL]filter_not_followers
:Bool
[OPTIONAL]filter_new_accounts
:Bool
[OPTIONAL]filter_private_mentions
:Bool
[OPTIONAL]Example:
GET
/api/v1/notifications/requests
Get the 'filtered notifications' inbox aka requests. This is a timeline, so the usual query params are available.
Returns:
RequestEntity[]
Example:
POST
/api/v1/notifications/requests/<id>/accept
Accept a request. There's no error if the request has already been accepted.
Returns:
{}
Query Params:
id
The request ID you are accepting.
POST
/api/v1/notifications/requests/<id>/dismiss
Dismiss a request. There's no error if the request has already been dismissed.
Returns:
{}
Query Params:
id
The request ID you are dismissing.