Moving topics/contexts between communities
Technical Discussion
8
Posts
2
Posters
3
Views
-
Moving contexts (aka topics/threads) between audiences (aka categories/communities) should be something that can be communicated outward.
NodeBB is experimenting with using the
Moveactivity to communicate this to other instances.When a context is moved from one audience to another, the object and all of its descendants go with it. This is communicated with a
Moveactivity with the resolvable context asobject, and withoriginandtargetreferring to the outgoing and incoming audience, respectively.An example
Move:{ @context: <... snipped>, id: "https://activitypub.space/topic/123#activity/move/1761362910015", type: "Move", actor: "https://activitypub.space/uid/1", to: ["https://www.w3.org/ns/activitystreams#Public"], cc: [ "https://activitypub.space/category/1/followers", "https://activitypub.space/category/2/followers", ], object: "https://activitypub.space/topic/1", origin: "https://activitypub.space/category/1", target: "https://activitypub.space/category/2", }The object
https://activitypub.space/topic/1doesn't necessarily mean anything to most implementors, so unless the object domain is yours, you are expected to resolve it to find the root object (and associated context if necessary.)Would adding a new property like
contextRootpointing to the root-level object be useful for implementors?If
targetisnull, theoretically this could signify the removal of a context from its audience.nullvalues are apparently a no-no in AP soRemoveactivity is recommended instead.rimu@piefed.social and nutomic@lemmy.ml melroy@kbin.melroy.org I wanted to ping you all as I am interested in your feedback as I move toward drafting this FEP.
-
undefined NodeBB shared this topic on
-
@julian If context is a collection,
Moveis problematic for the same reason asDelete. I think users shouldn't move server-managed views.It would be better to introduce a companion object (or an actor) for context collection. I guess I need to say something that in FEP-f228.
-
@julian If context is a collection,
Moveis problematic for the same reason asDelete. I think users shouldn't move server-managed views.It would be better to introduce a companion object (or an actor) for context collection. I guess I need to say something that in FEP-f228.
Would
updatework better?Moveis pretty self explanatory, and I don't have any issue with a collection being moved from a collection to another collection (despite how odd that sounds.) -
No,
Moveis a good choice, but I do have a problem with itsobjectbeing a collection. I am not sure if I can implement this in my ActivityPub client application.Are you opposed to adding a companion object?
-
No,
Moveis a good choice, but I do have a problem with itsobjectbeing a collection. I am not sure if I can implement this in my ActivityPub client application.Are you opposed to adding a companion object?
Not particularly, but I am worried about adding additional complexity since it affects developer buy-in.
I'll bring it up at the next ForumWG for debate.
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g.
isClientManaged: true. And they shouldn't be paginated.I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g.
isClientManaged: true. And they shouldn't be paginated.I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
If we're going to be publishing activities regarding resolvable context collections then it may be time to introduce a new object type.
It would be backwards compatible with f228
OrderedCollections... using the new type would signify support for the various activity types perhaps...?Edit: if this is what you were proposing with client managed collections, then my apologies 😅 the naming threw me off
-
No,
Moveis a good choice, but I do have a problem with itsobjectbeing a collection. I am not sure if I can implement this in my ActivityPub client application.Are you opposed to adding a companion object?
>Would update work better?
On a second thought,
Updateis better because posts and conversations could be addressed to multiple groups. A common example of this is a post that @-mentions two or more groups.I think updating a single property (
tooraudience) is more straightforward thanMovewith multiple origins and multiple targets.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
This is not an issue if you are rebuilding the instance wide deny list every time it is updated.
In that case, whenever the list is rebuilt any removed entries will simply not appear in the new list.
-
@julian you might want to check out what GoToSocial does on this front -- it seems very well thought out
-
The problem with the CSV format, is that it doesn't tell you what was removed, only the current state of the data, so you'd need to store previous CSV files to detect removals by diffing new versus old.
-
NodeBB has a very simple allow/deny list capability at present. You paste in a bunch of newline-separated domains, and we block (or optionally, only allow) them all.
On the road to more fine-grained controls, I discovered that IFTAS publishes a Do Not Interact list in an importable CSV format.
As maintenance of these lists is important (adding new entries as well as handling removals), it looks to be increasingly important that I add into NodeBB the functionality to follow these lists automatically and update as necessary.
-
>Would update work better?
On a second thought, Update is better because posts and conversations could be addressed to multiple groups. A common example of this is a post that @-mentions two or more groups.
I think updating a single property (to or audience) is more straightforward than Move with multiple origins and multiple targets.
-
If we're going to be publishing activities regarding resolvable context collections then it may be time to introduce a new object type.
It would be backwards compatible with f228 OrderedCollections... using the new type would signify support for the various activity types perhaps...?
Edit: if this is what you were proposing with client managed collections, then my apologies 😅 the naming threw me off
-
Another solution: introduce a new object class, client-managed collections. These collections should have a property that differentiates them from server-managed collections, e.g. isClientManaged: true. And they shouldn't be paginated.
I think this would be compatible with client-side signing.
But companion object solution seems to be cleaner.
-
@julian that might be it, yeah. languages outside of javascript generally don't make a distinction between null and undefined, and even in javascript these are used inconsistently. for example localStorage.getItem will return null for a missing key. practically speaking, the "intentionally" distinction is a distinction without a difference in most processing contexts.
