Moving topics/contexts between communities

[julian@activitypub.space]

Moving contexts (aka topics/threads) between audiences (aka categories/communities) should be something that can be communicated outward.

NodeBB is experimenting with using the Move activity 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 Move activity with the resolvable context as object, and with origin and target referring 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/1 doesn'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 contextRoot pointing to the root-level object be useful for implementors?

If target is null, theoretically this could signify the removal of a context from its audience. null values are apparently a no-no in AP so Remove activity 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.

[silverpill@mitra.social]

@julian If context is a collection, Move is problematic for the same reason as Delete. 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@activitypub.space]

Would update work better?

Move is 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.)

[silverpill@mitra.social]

No, Move is a good choice, but I do have a problem with its object being a collection. I am not sure if I can implement this in my ActivityPub client application.

Are you opposed to adding a companion object?

[julian@activitypub.space]

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.

[silverpill@mitra.social]

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@activitypub.space]

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

[silverpill@mitra.social]

I was proposing a new shape, not a new type. It won't be backwards-compatible if existing implementations do pagination of context (I think some of them do)

[silverpill@mitra.social]

>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.

[julian@activitypub.space]

Specifically with sending Update, I have no real objections except one cannot simply assume that two groups being addressed constitutes a cross-post.

... for the simple reason that Mastodon conflates addressing with mentions.

For that reason and that reason alone I cannot infer community for any given object based on to and cc.

Now, audience, on the other hand... is a good signal.

So I am totally on board with multiple audiences being updated.

[silverpill@mitra.social]

For that reason and that reason alone I cannot infer community for any given object based on to and cc.

Could you elaborate on this?

I think both to and audience are not reliable signals. The object should be present in context in order to be considered published in the community.

>Now, audience, on the other hand... is a good signal.

I thought Lemmy devs decided to address community in to instead of audience. Any news on that front?

[julian@activitypub.space]

silverpill@mitra.social said in Moving topics/contexts between communities:
> I thought Lemmy devs decided to address community in to instead of audience. Any news on that front?

You're right. I'm going to want to talk to nutomic@lemmy.ml about that one. I think it was a mistake to remove setting that property explicitly.

As for audience being a more reliable signal, I mean that when I receive a Create(Note), I cannot reliably tell whether it was made to a community or not. Mastodon users may tag communities in a mention, and they may intend to post the topic there, but they may also just be tagging to community as a reference in post content.

[julian@activitypub.space]

silverpill@mitra.social I have been reflecting on the use of Remove/Move vs Update and I am thinking that Update isn't explicit enough.

If I am removing a topic from a category, I'd be sending an Update with the group actor removed from the audience property.

However recipients wouldn't know which audience was removed, merely the new state of that context's audience.