Notices by Feral Thoughts (feralthoughts@union.place)

@silverpill

I had completely forgotten to mention that allowing a user to narrow the scope of replies seems to enable a particular form of harassment, predominantly employed for racist abuse of black users.

Described here:
https://gts.sadauskas.id.au/@aj/statuses/01K6Z6ZAXY1SB46X6PAFDKM9S9

And in a thread I wrote earlier:
https://union.place/@feralthoughts/115345717793512758

(continues)

@silverpill

Have you thought of some (technical) solution to prevent this?

Or is it a matter of choosing between the pathology you described (possible because Mastodon and others lack conversation containers) and this harassment vector enabled by scope narrowing?

@silverpill

And a Mitra user's reply post will include implicit addressing (in future?) copied from parent post, so the user is free to delete the recipient list from the text of the message - correct? But if the @ mentions are missing, the recipient application (Mastodon or whatever else) may or may not notify the recipients, depending on their own design – right?

@jupiter_rowland

@silverpill

Thank you for the explanations.

So...

Irrespective of @ mentions, Mitra will always notify a user if that user is addressed in a post - would that be a correct statement?

And Mitra's threading routine depends only on the sender and the recipient addresses in the posts in a conversation, not at all on @ mentions in those posts?

@jupiter_rowland

(continues)

@silverpill

Even mentions copied from the parent will count as characters, and eat up the limited character quota, no?

@jupiter_rowland

(continues)

@silverpill

By the way, I didn’t get the point you had made earlier:

> You're notified only when you're directly addressed ... I think the way notifications work will be the same when we switch to containers

@jupiter_rowland

(continues)

@silverpill

If I understood correctly, conversation containers ensure that all replies in a thread are routed through the OP’s server on their way to other participants in a conversation. So once conversation containers for public conversations are implemented, it should be possible for at least a Mitra OP to get notified of every single reply in a thread, even if they are not tagged. Isn’t that correct?

@jupiter_rowland

@silverpill

Still have few doubts, but they don't matter.

For the average fedizen, the present design of Mitra's nomadic identity seems very difficult to use.

Are there future plans to make Mitra's nomadic identity design similar to Forte's? Or maybe simpler than that?

(I have never used Forte, but I am assuming that its nomadic identity design is similar to Hubzilla's, which I know can be activated from the regular web interface.)

@silverpill

Hmm - ok.

So... if OP is not a follower of B, and B's follower-only reply to OP's public post does not tag OP, then OP won't receive B's reply? Or if B does tag OP, but C's reply to B's post doesn't tag OP, then OP won't receive C's reply? Seems undesirable, if that would be the case.

I feel restricting all replies to OP's privacy level will prevent many possible pathologies.

Either way, in future, do you plan to apply conversation containers to public conversations?

@silverpill

Regarding notifications: I am not sure, but I think a Hubzilla OP starting a thread receives notifications of every single reply, including those that do not tag the OP. And I am far less certain here, but maybe the behaviour is similar in case of a Hubzilla user participating in a thread started by someone else?

But I could be wrong. Maybe we should ask some Hubzilla veteran. @jupiter_rowland , can you please tell us how this works on Hubzilla?

(continues)

@silverpill

One reason I have been asking about notifications without @ mentions: today, if lot of users join a conversation, then the @ mentions can take up 100-200 or more characters, and significantly reduce the characters available for the actual text (I know Mitra has ten times Mastodon’s character limit, but even then...). In addition, a poster may allot characters for hashtags and groups. That leaves even fewer characters for the actual text.

@jupiter_rowland

(continues)

@silverpill

If all participants in a thread received notifications even without @ mentions, this problem would not occur. In that case, @ mentions will only be required for adding new participants. Once added, they too should automatically receive all subsequent posts in the thread, without anyone having to @ mention them.

If some participant doesn’t want those notifications, they should have the option to unsubscribe from the thread.

@jupiter_rowland

@silverpill

So... some posters randomly start deleting the @ mentions of one or two or three or more recipients, leading to fragmented sub-threads and sub-sub-threads with random subsets of participants.

This is very counter-productive; it prevents inclusive, participatory conversations.

@jupiter_rowland

(continues)

@silverpill

Also: allowing respondents to narrow the visibility will run into the well-known problem of each reply being visible to a different set of followers.

Say user B replies followers-only to the OP. User C then replies followers-only to B’s post. In this case, B’s post will only be visible to B’s followers, while C’s post will only be visible to C’s followers, with further downstream replies inheriting the problem.

(continues)

@silverpill

Thank you for all the responses.

Personally, I think the Streams/Forte behaviour, of every single reply inheriting the OP’s privacy status, is the one that matches social expectations.

If the OP is starting a conversation, they should get to decide the contours for the entire thread, a respondent should not be able to change those. If some respondent wants to respond with a different privacy status, they can always start a new conversation and link to the OP.

(continues)

@silverpill

To address this problem, it may be worth applying conversation containers also to public conversations? And applying them so that all replies inherit the privacy status of the OP?

@silverpill

Can a user without admin access do this?

And once the CLI action is done, either by user or admin, can the user then use their account's web interface normally on either site, with no further command line interventions required? The cloning will just happen in the background?

@silverpill

I read that Mitra experimentally supports nomadic identity. Does this feature make it possible to simultaneously have the same account on two or more Mitra instances, with new activity in any of those getting mirrored on the clone accounts?

Basically, does nomadic identity in Mitra work in a fashion similar to that in Hubzilla?

@silverpill

Can a Mitra user follow hashtags and groups?

(continues)

@silverpill

Can Mitra instance admins subscribe to ActivityPub relays?

(continues)