Discussion
Loading...
Post
How does Mitra work in case of public conversations?
Say, a Mitra user writes a new public post (OP of a thread). Do they get notified of all replies in the thread, including even those reply-to-reply posts that do not tag them?
Can a respondent to the OP’s public post change the status of their reply post to followers-only or mentioned-users-only? If the OP is not a follower of that respondent, and is not tagged, will the reply be visible to the OP?
(continues)
How does Mitra work in case of public conversations?
Similar to how Mastodon and other micro-blogging platforms work. You're notified only when you're directly addressed (this is usually done by @mention).
It doesn't currently use Conversation Containers for public conversations, but I think the way notifications work will be the same when we switch to containers
Can a respondent to the OP’s public post change the status of their reply post to followers-only or mentioned-users-only?
They can reply with narrower visibility. I think narrowing of the scope should be allowed, but not widening. Although, as far as I know, Streams/Forte allow neither.
If the OP is not a follower of that respondent, and is not tagged, will the reply be visible to the OP?
Currently it is not visible.
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)
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.
(continues)
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.
(continues)
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.
1+ more replies (not shown)
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)
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)
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?
@feralthoughts Yes, conversation containers can be used to enforce conversation scope.
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.
This is not a narrowing, it's a change of scope. Narrowing means user C can only reply to B's followers or to B directly.
1+ more replies (not shown)
Say, a Mitra user boosts (reposts) a post in some thread, or posts a reply in that thread. Does the user then get notified of all subsequent posts in that thread?
Basically, is there some way for a Mitra user to “subscribe” to a public thread, or flag in some way that they would like to receive existing posts as well as get notified of all future posts in that thread/conversation?
(continues)
@feralthoughts No, this is not supported.
Hashtags: only if they are ActivityPub actors, e.g. https://relay.fedi.buzz/ hashtags
Groups: yes
Relays: yes, and regular users can subscribe too. Actually, there is no special admin interface for subscribing to relays, we just use regular accounts.
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?
@feralthoughts Yes, mirroring partially works, but nomadic accounts require a special command-line client:
https://codeberg.org/silverpill/fep-ae97-client
It's not possible to create a nomadic account from the web site.
1+ more replies (not shown)
bonfire.cafe
A space for Bonfire maintainers and contributors to communicate
Automatic federation enabled