271110c1a5
This feature was both conceptually broken and through bitrotting the implementation was also buggy with the handling of certain list-post interactions just crashing. Remote servers had no way to know who belongs to a list and thus posts basically showed just up as weird DM threads with different participants on each instance. And while on the local instance addition and removal from a listed grated and revoked post access retroactively, it never acted retroactively on remotes. Notably our "activity_visibility" database function also didn’t know about "list visibility" instead treating them as direct messages. Furthermore no known client actualy allows creating such messages and the lack of complaints about the accumulutaed bugs supports the absence of any users. Given this there seems no point in fixing the implementation. To reduce complexity of visibility handling it will be dropped instead. Note, a similar effect with less federation weirdness can already be achieved client-side using the explicit-addressing feature originally introduced in https://git.pleroma.social/pleroma/pleroma/-/merge_requests/1239. Ref: https://akkoma.dev/AkkomaGang/akkoma/issues/812
14 lines
422 B
Elixir
14 lines
422 B
Elixir
# Pleroma: A lightweight social networking server
|
|
# Copyright © 2017-2021 Pleroma Authors <https://pleroma.social/>
|
|
# SPDX-License-Identifier: AGPL-3.0-only
|
|
|
|
defmodule Pleroma.Web.ApiSpec.Schemas.VisibilityScope do
|
|
require OpenApiSpex
|
|
|
|
OpenApiSpex.schema(%{
|
|
title: "VisibilityScope",
|
|
description: "Status visibility",
|
|
type: :string,
|
|
enum: ["public", "unlisted", "local", "private", "direct"]
|
|
})
|
|
end
|