Clarification about changing the audience in non public posts

[annando]

Technically it is possible to comment publicly on non public posts or to include other receivers. This can lead to some very bad situations when someone starts a non public conversation with three people and someone silently includes other people to the thread without notifying the other people.

I would like to know whether this is the expected behaviour or whether this should be avoided.

For technical reasons, Friendica is always inheriting the audience for comments from the starting post. Only for public posts we can add additional receivers.

[trwnh]

I think that would be up to the software implementation to not "silently" change the recipients? A new message can have a different audience, so if the audience on a reply to a private post includes more people, it might be a good idea to notify the user. Otherwise I think this is expected.

[nightpool]

see also https://github.com/w3c/activitypub/issues/319 for discussion on the more general issue of "allowing" replies

On Fri, Nov 2, 2018, 8:10 AM trwnh notifications@github.com wrote:

I think that would be up to the software implementation to not "silently" change the recipients? A new message can have a different audience, so if the audience on a reply to a private post includes more people, it might be a good idea to notify the user. Otherwise I think this is expected.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/327#issuecomment-435358623, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV1hLakNd395O6se1sh_Fx357Beu7ks5urDYggaJpZM4YGUca .

[annando]

I will read that issue later (when I have got more time). The most important reason why I would like to define that the audience cannot be changed on non public posts (and that you shouldn't be able to answer a public post with a non public comment) is that there are not only post based, but also thread based systems out there in the wild. Systems like Friendica, Hubzilla, SocialHome and GangGo (and Diaspora) are defining the audience in the starting post. Mostly they aren't even able to display a single post but the whole thread. So the audience have to be public - or mustn't be changed.

[nightpool]

we can't privilege one type of system over another here. ActivityPub doesn't really define "visibility"—all objects are visible only to the users they are delivered too, unless they're public. It would make no sense to add an arbitrary restriction like this based solely on the "inReplyTo" value, that's a consideration that many implementations can reasonably disagree on. It would make no sense to add restrictions like this to the spec just because some systems don't like it.

On Fri, Nov 2, 2018, 10:06 AM Michael Vogel notifications@github.com wrote:

I will read that issue later (when I have got more time). The most important reason why I would like to define that the audience cannot be changed on non public posts (and that you shouldn't be able to answer a public post with a non public comment) is that there are not only post based, but also thread based systems out there in the wild. Systems like Friendica, Hubzilla, SocialHome and GangGo (and Diaspora) are defining the audience in the starting post. Mostly they aren't even able to display a single post but the whole thread. So the audience have to be public - or mustn't be changed.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/w3c/activitypub/issues/327#issuecomment-435390996, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV32Ta5fHynRorLZ6A_kl73jRJROpks5urFF5gaJpZM4YGUca .

[annando]

In my eyes it has something to do with privacy. The thread starter defined the audience, so this should be respected.

[trwnh]

re: privacy, the thread starter can only control the audience of their own post, not the audience of any replies. To do otherwise would veer into the territory of allowing/rejecting replies, as #319 deals with. If you are doing proper cryptography, then changing the audience of the reply will lead to a situation where someone can see the reply, but not the original post. This isn't necessarily something you can avoid, unless the original post's host is responsible for distributing replies (at which point OP's server can enforce whatever logic the software desires).

[annando]

There are many things that cannot be prevented, but could be discouraged.

There will be side effects of changing the audience of single posts in a thread: For example it is possible in Mastodon to reply to a public post with a non public comment. For technical reasons, Friendica can only discard such a comment - or make it visible for everyone, since it will inherit the thread audience. This could lead to some ugly situations.

[jaywink]

There will be side effects of changing the audience of single posts in a thread: For example it is possible in Mastodon to reply to a public post with a non public comment.

IMHO this is a completely valid use case, especially in a microblogging environment. Unlike in Diaspora protocol, ActivityPub doesn't specify a "comment" as a separate object. Additionally in AP each object has audience defined directly. As such it would be odd to somehow encourage on the protocol specification that if a Note is a reply to another Note, it shouldn't be able to define its own audience.

Socialhome currently does the same as Friendica due to Diaspora protocol but when implementing AP I'm going to change it in a way that replies are only shown to the people who can see them through the object audience. Sure this will mean some replies are not visible to all in the thread, or even the original author, but I don't see a problem with that. The original post just indicates the context for discussion, unlike in Diaspora protocol it doesn't mean that the whole thread needs to be the same for every user.

[trwnh]

Non-public replies to public posts are perfectly valid in the same way that you might make a private comment to your friend at a party, targeted only at them, not to the entire room. I don't think it makes sense to prevent this kind of usage, since it models an existing pattern. The argument might make more sense for public replies to non-public posts, but eh...

Ultimately it still comes down to who owns the post. ActivityPub's model has Actors responsible for their own posts using their Outbox. The concept of a "comment" is not really defined outside of inReplyTo. You can't delete someone else's post.

To do otherwise would require granting ownership of all replies to the OP, as explained above. That way, the OP's server is responsible for redistributing to the proper audience. That would make more sense in a "moderated comments" model as put forward in #319, where Notes inReplyTo your Note are delivered to you first and foremost, and then you respond with an Accept or a Reject (perhaps automatically, perhaps manually).

[annando]

"ownership of replies" and deleting someone else's comment is another topic. I guess that we (Friendica) will have some things to discuss and decide at our upcoming hackathon this month.

[trwnh]

It's "another topic" but also technically the same topic, since you want to restrict changing the audience later in a thread, right? There's no real way to do that except to discard that only in your software (invalid to the model), or rewrite the audience (bad, violates user expectation). You can't stop people putting whatever audience they want on their own posts, regardless of what audience the inReplyTo post has.

[janbruns]

What about some way to roughly describe an audience, for which a server owning some post is willing to add replies to it's replies collection?

Wouldn't such a description typically be a subset of that post's audience?

[evanp]

We discussed this in issue triage and think it has several layers. The first layer is a social one: this is an impolite thing to do to your correspondents, with the exception of tagging new actors into an existing conversation.

At the implementation level, it's not clear whether this is something that implementations should filter on, either as clients (say, by limiting the UI for replies to prevent adding broader addressees) or as federation servers (say, by rejecting activities that include broader addressees). This seems like a lot of interference on the part of implementation, without clear rules and with a lot of exceptions.

At the specification level, this seems like it doesn't belong in the specification at all.

I'm going to leave this open. I think if we decide to make a recommendation at the implementation level, it should go into a Primer page.

[evanp]

Dropped WFC since it's been open for 6+ years.