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

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

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?

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.

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

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)

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

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.

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?

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.

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.