Moving topics/contexts between communities
Technical Discussion
7
Posts
2
Posters
1
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
Gli ultimi otto messaggi ricevuti dalla Federazione
-
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.
-
trwnh@mastodon.social undefined and perhaps that's why we're disagreeing on our interpretations of how these values should be handled.
null in JavaScript is very explicitly a declaration that there is no value or "intentionally empty".
null and undefined are two separate things here at least.
-
@julian what does js return instead? in most cases i'm familiar with, programming languages use null or nil or None for anything that doesn't have a value, or any reference which doesn't point anywhere. hence a null pointer exception when you try to dereference a null. if you try to get a value for a key that isn't in the dictionary, you get null by default because there is no value for a missing key. how would you consume a null value? if you have nothing to say, why say anything?
-
trwnh@mastodon.social I'm coding in js, which has all sorts of footguns, but even that won't return null when I attempt to access the non-existent property of an object... 😛
-
@julian this wouldn't be your AP lib, it would be your programming language itself
-
trwnh@mastodon.social as someone working on the consuming side, that is not correct.
If my AP lib automatically assumed null when requesting an object property that didn't exist I'd consider that a bug.
