You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should figure out what modifying an already-existing object's audience looks like. Yes, this will be really tricky to do (especially given the way delivery works), but people will want to do it. In particular, they may want to change whether posts are addressed to Public or not.
The text was updated successfully, but these errors were encountered:
Ah yes, the "horse is already out of the barn" problem. There isn't any perfect solution. At best you can come up with something that's less flawed than other ways. We've experimented with sending delete requests to anybody that was in the original distribution and isn't now, and update requests to those that are existing or new to the conversation. The problem is usually trying to retroactively figure out exactly who precisely was included in the "public" list originally. You also might get away with this on a pure activitypub network, but it doesn't work very well with federated networks that don't honour delete requests (some older OStatus/GNU-Social instances) or once something has gotten into the wild via a public RSS/Atom feed. Going the other way (private to public) is trivial.
We should figure out what modifying an already-existing object's audience looks like. Yes, this will be really tricky to do (especially given the way delivery works), but people will want to do it. In particular, they may want to change whether posts are addressed to Public or not.
The text was updated successfully, but these errors were encountered: