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.
-
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" -
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by trwnh@mastodon.social
@dahukanna i guess you could also do as:last/as:prev*/as:items if you wanted to page backwards.
last thing to note is that `orderedItems` is just an alias (JSON-LD "term definition") for `as:items` except with a `@`type of `@`list
-
trwnh@mastodon.socialreplied to trwnh@mastodon.social last edited by
@dahukanna hope that helps!