scopeCopy → true by default
The current default is a regression and a surprise when updating.
(or might just be completely broken since the setting doesn't seem to be honored anyway)
Merge request reports
Activity
btw, looking at https://git.pleroma.social/pleroma/pleroma/blob/develop/config/config.exs#L148, it seems we DO set it to true in the BE. @scarlett are you running a custom FE and this hit you because of that?
DMs' scopes are ALWAYS copied. It's even stated so in UI. Do i need to make it 48pt in UI for better visibility?
it only affects unlisted/followers-only posts, which are problematic. DMs' scopes are SO MUCH always copied, they were even copied when setting was broken and not honored.
Defaulting it to
false
solves several problems:- someone has their default to "unlisted" because they are running an instance and don't want to make it look like they're are the only one there, replying to them would make your own replies unlisted, which might be undesireable
- not sure put i think the inverse of above is also applicable, but if you keep your posts followers-only, replying to a public post would make your reply a public post.
- same as (1) but followers-only, and followers-only posts are just plain cancer altogether, or rather an STD-cancer, and I don't want it to spread.
Overall, i feel like user's posts should ALWAYS be the same scope as user's default, except for DMs.
@shpuld setting would change if user didn't touch the setting at all, at least that's how it is right now.
Made an issue about it so that wodn't pollute someone's MR with flood #245 (closed)
It's not an easy one so please read the description, i've stated my point there.
I checked on kawen.space and my account had scope copying disabled (while still saying 'default: true'). The BE config also returned true for it. It seems like it was somehow set to false? Was this a bug we had for a while?
On a newly setup instance I didn't encounter any problems with scope copying, it worked as expected.
@lambadalambda yes there was a bug that made it act as if it's
false
because it'sundefined
, not inheriting the instance setting. It was fixed in !429 (merged)mentioned in commit a974d2ab