I'm so tired of reading takes on moderation that begin and end with "decide what content I see". That's not even half the question.
-
helge@mymath.rocksreplied to jenniferplusplus@hachyderm.io last edited by
I agree that this an issue that should be pushed. Now technical comments:
Local only posts are implemented and AFAIK the only option that one can get to work well.
Regarding Followers Only Posts: Mastodon breaks addressing to the followers collection with how it handles replies. If Alice makes a followers only post and Bob replies. Bob's reply is addressed to his followers collection and not to Alice's.
-
dahukanna@mastodon.socialreplied to helge@mymath.rocks last edited by
@helge @jenniferplusplus
Current mental model for conversation thread: Alice posts to her followers-only and expects replies only from this set of people that intersects with Alice = (Alice ⋂ followers only), not to the followers of her followers=(Alice ∪ (each follower’s followers * infinity)).
Otherwise, what is the purpose and point of posting to followers only? It should be called “post to followers’ network”. -
jenniferplusplus@hachyderm.ioreplied to dahukanna@mastodon.social last edited by
@dahukanna @helge
Followers only works the way you're describing. The problem is the way it intersects with replies. It doesn't expand to include the OPs followers. In the simple case, that's annoying because it fragments the conversation. But it also feeds into abuse cases, where bad actors use it to isolate their targets.This is a solvable problem, but somehow the spec never considered it, and mastodon just refuses to do anything about it.
-
dahukanna@mastodon.socialreplied to jenniferplusplus@hachyderm.io last edited by
So the visibility scope of a reply post to another post is determined by the person creating the reply, not the originating/root note of the conversation?
See actual and expected conversation graph follower-only post+replies visibility scope. -
helge@mymath.rocksreplied to dahukanna@mastodon.social last edited by
Yes, that it is true. It also says so pretty clearly in the UI "Followers; only your followers".
I don't think think that the red reply happens very often. Mastodon doesn't show everything that arrives in the ActivityPub inbox in the home timeline. So there is a good chance that E would not see B's post, and not reply.h
The worse problem here is that if D does not follow B, they will not see B's post and possibly write the same thing.
-
dahukanna@mastodon.socialreplied to helge@mymath.rocks last edited by
@helge @jenniferplusplus
“Worse problem-if D doesn’t follow B, D won’t see B's post & possibly write the same thing”: so that’s the source of not seeing replies to posts!
If post0(start of a conversation graph) has replies(nodes) then post0 creator & followers should see all replies unless exclusion rules apply to any nodes(posts & replies) by specific account (person) e.g.
- temporarily mute.
- permanently mute (block) & deny access to my nodes(posts & replies).
Use graph theory & sets maths. -
jenniferplusplus@hachyderm.ioreplied to dahukanna@mastodon.social last edited by
@dahukanna @helge
Preferably, post0 would define a collection that is the set of all posts in the conversation. Then B, C, and D would request to add their posts to that collection, which would have the same visibility as post0. Everyone could fetch that collection, and everyone could have the same view of the conversation as person A. So no missing replies, no hidden abuse, no weird fragments of conversation that can't connect back to a root. -
trwnh@mastodon.socialreplied to jenniferplusplus@hachyderm.io last edited by
> it's even more baffling that no major implementation has actually taken advantage of that
i blame sharedInbox. its mere existence seems to constrain people's imaginations on what is possible... they don't realize it was designed only for Public activities. using it for anything else means that you are giving control to the remote server to decide who can see it (which is a Very Bad Idea). what we need is a mechanism that lets you explicitly declare which inboxes to deliver
-
trwnh@mastodon.socialreplied to jenniferplusplus@hachyderm.io last edited by
@jenniferplusplus @dahukanna @helge this is exactly how i view `context` and it's why i wrote https://w3id.org/fep/7888 -- to enable exactly this kind of representation of a "conversation". A owns the collection, A gets to Add posts into it. B, C, D can fetch by id, but M who is blocked will fail whatever access control mechanism you're using.
-
jenniferplusplus@hachyderm.ioreplied to trwnh@mastodon.social last edited by
@trwnh I actually don't hate Sharedinbox the way other people do. You were always going to depend on the way the recipient server distributes your messages. The SharedInbox is just honest about that, which allows the protocol to make a meaningful and critical performance optimization.
My position on that is generally that we have to trust our peers to act in good faith, and we shouldn't deal at all with peers we can't trust in that way.
-
trwnh@mastodon.socialreplied to jenniferplusplus@hachyderm.io last edited by
@jenniferplusplus well, the remote server has no idea what any given collection contains. that's the real issue.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@jenniferplusplus like, it should be possible to silently remove a follower without notifying any remote servers and without leaving the remote server in a state where it will blindly continue to deliver your activities to the actor you remove silently.
-
jenniferplusplus@hachyderm.ioreplied to trwnh@mastodon.social last edited by
@trwnh I agree that the near impossibility of knowing the contents of a collection is the source of the problem. But saying you should be able to update the collection, not inform anyone, and have them act in accordance with the update seems like magical thinking.
-
trwnh@mastodon.socialreplied to jenniferplusplus@hachyderm.io last edited by
@jenniferplusplus if there were a multibox endpoint where i could explicitly say "deliver this activity to inboxes B,C,D only", then the remote server doesn't have to know the contents of the collection. It could at most guess what the local subset is, sure.
-
jenniferplusplus@hachyderm.ioreplied to jenniferplusplus@hachyderm.io last edited by
@trwnh I would instead suggest that we need a way to distinguish between inboxes that are self administered vs administered by a third party. For a lot of reasons. Sending a block or flag or removing a follower is a different dynamic depending on whether it's going straight to the subject's inbox, or will be processed by some 3rd on their behalf. You can trust 2nd parties not to be indifferent, but 3rd parties usually are.
-
trwnh@mastodon.socialreplied to jenniferplusplus@hachyderm.io last edited by
@jenniferplusplus i'm toying with the following approaches re: this
a) declare an `endpoints.abuseReports` or similar for the express purpose of server-wide abuse communications or other activities that aren't meant to be seen by the actor you are reporting/blocking/etc
b) formalize servers as actors with their own inboxes and use these inboxes for all manner of "system messages". this would in effect work like xmpp, except xmpp goes even further and sends *all* messages to a server directly.
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@jenniferplusplus in any case it would probably be a good idea to take a hard look at the exact nature of the relationship between any given actor and their server. there ought to be a way to signal that an actor is being "managed" by some server, where the server is doing more than simply hosting their inbox and outbox and doing deliveries.
-
dahukanna@mastodon.socialreplied to trwnh@mastodon.social last edited by
@trwnh @jenniferplusplus @helge
Thanks for sharing, will take closer look later.
Initial impressions after reading:1. I’d need to absorb & model Information Architecture {IA) for entire ActivityStream specification to put the context placeholder in context of base-class/object/implementation for actor, collection, etc.- https://www.interaction-design.org/literature/topics/information-architecture
2. Question: Is the context collection a bag abstract data type (https://algs4.cs.princeton.edu/13stacks/) or a graph with nodes & edges (https://ocw.mit.edu/courses/6-042j-mathematics-for-computer-science-fall-2010/f471f7b7034fabe8bbba5507df7d307f_MIT6_042JF10_chap05.pdf)?
-
trwnh@mastodon.socialreplied to dahukanna@mastodon.social last edited by
1. activity streams has an object model where everything mostly inherits from as:Object. the FEP recommends specifically as:Collection (or as:OrderedCollection which inherits from it) because then you can as:Add items into it
2. datawise, as:Collection is basically a Set, as:OrderedCollection is roughly analogous to a List. but it is represented in AS2 using graphs. a Collection has a directed edge `items` or `orderedItems` which points to a JSON array that is either a set or a list
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@dahukanna more precisely, you also have to account for the possibility of paging. so the path to any given member of an as:Collection is:
as:items | as:first/as:next*/as:items
where | means "or", "union"
and / means "following an additional edge"
and * means "0 or more times"