Social
Who the owner is connected to.
This scope says who, never what those accounts hold.
Requests to follow a private account are answered one at a time at
/api/v1/social/follow-requests/{username}, or all at once:
PUT /api/v1/social/follow-requests with {"all": true} accepts, and
DELETE /api/v1/social/follow-requests?all=true declines. all is
required on both, because an emptied queue does not come back.
/api/ v1/ social/ followersAccounts following the owner.
/api/ v1/ social/ followingAccounts the owner follows.
/api/ v1/ social/ blocksWho the owner has blocked. The other direction does not exist: an account reads the blocks it made, never the ones made against it.
Query
| Field | Type | Notes |
|---|---|---|
page | integer | 1 to 1000. |
q | string | Filters by username or display name. |
/api/ v1/ social/ following/ {username}Follow an account, or ask to if it is private. The answer carries following and requested, and only one of them is true. Doing it twice changes nothing.
/api/ v1/ social/ following/ {username}Unfollow an account, or withdraw a request that has not been answered.
/api/ v1/ social/ blocks/ {username}Block an account. That also undoes following in both directions, which is the database's doing rather than this route's.
/api/ v1/ social/ blocks/ {username}Unblock an account. Following is not restored on its own.
/api/ v1/ social/ follow-requestsWho has asked to follow a private account and is still waiting. Only that direction exists: what this account has asked of others is their queue to answer, and listing it here would be reading a decision nobody has made.
Query
| Field | Type | Notes |
|---|---|---|
page | integer | 1 to 1000. |
q | string | Filters by username or display name. |
/api/ v1/ social/ follow-requestsAccepts every waiting request at once and says how many: {"data": {"approved": 3}}. Each one is accepted as the single-request route would, with the same second-factor check when the account requires it. Without all: true in the body it answers 400, because emptying the queue cannot be undone and should not happen by mistake.
Body
| Field | Type | Notes |
|---|---|---|
allrequired | boolean | Must be true. |
/api/ v1/ social/ follow-requestsDeclines every waiting request at once and says how many: {"data": {"declined": 3}}. Without ?all=true it answers 400, for the same reason as the PUT.
Query
| Field | Type | Notes |
|---|---|---|
allrequired | boolean | Must be true. |
/api/ v1/ social/ follow-requests/ {username}Accepts a request. An account that was not waiting answers 404 rather than a silent success: approving a request that was withdrawn should not read as approved.
/api/ v1/ social/ follow-requests/ {username}Declines a request. It leaves the queue either way; only accepting creates the follow.
/api/ v1/ reportsTell moderation about something. There is no read side and there will not be one: a report is a message to the people who handle them, and letting the progress be watched (or letting anyone count how often an account has been reported) turns the queue into a weapon. The answer says it arrived, and nothing else. A person has one open report per thing: reporting the same profile or the same content again while the first is not closed answers 409 conflict, and the first one still stands. ARCADE_APP reports an Arcade game: it needs no username, since the account is the game's publisher, and it has uloggd check the game's URL again, at most once an hour per game.
Body
| Field | Type | Notes |
|---|---|---|
onrequired | string | PROFILE, REVIEW, LIST, SCREENSHOT, DIARY, PROFILE_COMMENT, CONTENT_COMMENT or ARCADE_APP. |
username | string | The account that published it. A report names the account it is about, even when it is about something that account published. Required for every kind but ARCADE_APP, where the database takes the account from the game itself. |
reasonrequired | string | HARASSMENT, HATE_SPEECH, SPAM, IMPERSONATION, SEXUAL_CONTENT, CHILD_SAFETY, SELF_HARM, VIOLENCE, PRIVACY, SPOILER, SCAM or OTHER. Every one applies to any kind except SPOILER, which is for something posted (a review, session, list, screenshot or comment) and is refused with 400 on a PROFILE, and SCAM, which applies to ARCADE_APP only. CHILD_SAFETY, SELF_HARM and VIOLENCE go to the front of moderation's queue, and SCAM moves ahead too. OTHER names no rule, so it asks for details. |
id | string | The content being reported. Required for anything but PROFILE, where the account itself is the subject. With ARCADE_APP, the game's app id. |
details | string | Up to 1000 characters. With OTHER it is required and at least 10 long, not counting spaces at either end: without that it answers 400. |
instance_id | uuid | With ARCADE_APP only, optional: the play the report came from. Moderation gets the release, the origin and the latest check of that moment with it. |