Topic removal from a category/community
Technical Discussion
29
Posts
5
Posters
116
Views
-
Hey rimu@piefed.social question to you about post removal...
If a remote user posts to a local community, and the local mod deletes it (let's say it's spam of off topic), does the local community federate a delete out?
Technically you're not deleting the content, just removing it from the community.
Is there a different action Piefed takes?
-
Hey rimu@piefed.social question to you about post removal...
If a remote user posts to a local community, and the local mod deletes it (let's say it's spam of off topic), does the local community federate a delete out?
Technically you're not deleting the content, just removing it from the community.
Is there a different action Piefed takes?
-
Hey rimu@piefed.social question to you about post removal...
If a remote user posts to a local community, and the local mod deletes it (let's say it's spam of off topic), does the local community federate a delete out?
Technically you're not deleting the content, just removing it from the community.
Is there a different action Piefed takes?
Yes, a Delete activity is sent to all instances with actors that follow the category/community. Those instances then delete their local copy. In Lemmy/PieFed there is no distinction between deletion and removal.
The deletes are soft so it is possible to un-delete by sending an Undo activity. PieFed keeps soft-deleted posts (topics, in NodeBB language) for a few days then after a week deletes the content from the database.
All of these activities are enclosed in an
Announceand the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author. With that model of ownership the idea of removal redundant - a post without a community is not a post.Tangentially - it would be good to come up with a way to move a topic to another category and federate that so the move can happen on other instances, too. We could go off-piste and create a
Moveactivity, or useRemove(from old topic/comm) followed byAdd(to new topic/comm) to do the same thing. I feel more inclined to go withMoveas it's a single atomic operation that either succeeds or fails, despite it not being in the spec.The AP spec is so badly stretched by various implementation-specific differences that I don't think it's worth being ideological about adherence to it it anymore.
-
Yes, a Delete activity is sent to all instances with actors that follow the category/community. Those instances then delete their local copy. In Lemmy/PieFed there is no distinction between deletion and removal.
The deletes are soft so it is possible to un-delete by sending an Undo activity. PieFed keeps soft-deleted posts (topics, in NodeBB language) for a few days then after a week deletes the content from the database.
All of these activities are enclosed in an
Announceand the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author. With that model of ownership the idea of removal redundant - a post without a community is not a post.Tangentially - it would be good to come up with a way to move a topic to another category and federate that so the move can happen on other instances, too. We could go off-piste and create a
Moveactivity, or useRemove(from old topic/comm) followed byAdd(to new topic/comm) to do the same thing. I feel more inclined to go withMoveas it's a single atomic operation that either succeeds or fails, despite it not being in the spec.The AP spec is so badly stretched by various implementation-specific differences that I don't think it's worth being ideological about adherence to it it anymore.
There are lots of other uses for
Move. A community whole could move instances, a user could move instances, etc. -
There are lots of other uses for
Move. A community whole could move instances, a user could move instances, etc.Yeah you're right,
Movehas some prior art for account migrations so it's worth some thinking through.I'd like to work together on this though. I'm working through context ownership and inheritance first, but once that FEP is drafted I can move on to this.
-
Yes, a Delete activity is sent to all instances with actors that follow the category/community. Those instances then delete their local copy. In Lemmy/PieFed there is no distinction between deletion and removal.
The deletes are soft so it is possible to un-delete by sending an Undo activity. PieFed keeps soft-deleted posts (topics, in NodeBB language) for a few days then after a week deletes the content from the database.
All of these activities are enclosed in an
Announceand the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author. With that model of ownership the idea of removal redundant - a post without a community is not a post.Tangentially - it would be good to come up with a way to move a topic to another category and federate that so the move can happen on other instances, too. We could go off-piste and create a
Moveactivity, or useRemove(from old topic/comm) followed byAdd(to new topic/comm) to do the same thing. I feel more inclined to go withMoveas it's a single atomic operation that either succeeds or fails, despite it not being in the spec.The AP spec is so badly stretched by various implementation-specific differences that I don't think it's worth being ideological about adherence to it it anymore.
rimu@piefed.social said in Topic removal from a category/community:
> All of these activities are enclosed in an Announce and the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author.Oh that's right! That makes sense. Having the community sign the activity (and the
Announcewrapper) would effectively differentiate it from a simple author-initiated content deletion.The impetus for this question was that occasionally I will move topics out of a category for being off topic. Federated copies don't see this change reflected, so both Move and Delete are things I want to federate out in lockstep with Piefed and Lemmy.
-
Yes, a Delete activity is sent to all instances with actors that follow the category/community. Those instances then delete their local copy. In Lemmy/PieFed there is no distinction between deletion and removal.
The deletes are soft so it is possible to un-delete by sending an Undo activity. PieFed keeps soft-deleted posts (topics, in NodeBB language) for a few days then after a week deletes the content from the database.
All of these activities are enclosed in an
Announceand the http POST is signed using the community key. So in a way the content 'belongs' to the community, not to the original author. With that model of ownership the idea of removal redundant - a post without a community is not a post.Tangentially - it would be good to come up with a way to move a topic to another category and federate that so the move can happen on other instances, too. We could go off-piste and create a
Moveactivity, or useRemove(from old topic/comm) followed byAdd(to new topic/comm) to do the same thing. I feel more inclined to go withMoveas it's a single atomic operation that either succeeds or fails, despite it not being in the spec.The AP spec is so badly stretched by various implementation-specific differences that I don't think it's worth being ideological about adherence to it it anymore.
@rimu Still, I think it would be nice to deprecate
Deleteand slowly migrate toRemove(target: context), since both PieFed and Lemmy implement the context collection now.My server rejects
Deleteif its actor is different from object's owner, and I have to treatAnnounce(Delete)as a special case where the normal processing logic doesn't apply. -
@rimu Still, I think it would be nice to deprecate
Deleteand slowly migrate toRemove(target: context), since both PieFed and Lemmy implement the context collection now.My server rejects
Deleteif its actor is different from object's owner, and I have to treatAnnounce(Delete)as a special case where the normal processing logic doesn't apply.Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.
-
Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.
Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.
cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)
-
Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.
cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)
I also think that backfill will have a side effect of connecting the threadiverse and the rest of the fediverse.
Exposing context collections will mean consumers will be able to see both *verses. Once Mastodon starts consuming them I predict you will start seeing much more engagement from the microblogs.
The same would apply if Piefed or Lemmy begin consuming them as well.
That is an angle I had not even considered until now!
-
Personally I think 1b12 doesn't need to be changed or hacked around. It doesn't specifically call for federating out deletes so I'd think any solution we come up with together would work with that FEP, not go against it.
cc silverpill@mitra.social (if your app notifies you of new replies without a direct mention I'll stop tagging you too)
if your app notifies you of new replies without a direct mention I'll stop tagging you too
Inclusion in
toorccis enough to generate a notification. -
Possibly although the differences of federation between the threadiverse and the rest of the fediverse go way beyond deletes. FEP 1b12 is a whole thing, chipping away at it piece by piece would be slow going.
rimu@piefed.social silverpill@mitra.social I gave this a bit more thought and I am coming around to the idea that
Removecould work.I am assuming that when Piefed sends
Announce(Delete(Object))this is only understood by Piefed? Not Lemmy (and certainly not NodeBB, yet)...In that case, a move to a simpler
Remove(target: context)signed and acted on by the community actor, would send a more explicit message that the object was removed from the community.The "1b12-speaking" portion of it would be an
Undo(Announce(Create)), although once again I am not even sure if that action is understood by Piefed/Lemmy. -
only understood by Piefed? Not Lemmy
No, that's a Lemmy thing too.
-
only understood by Piefed? Not Lemmy
No, that's a Lemmy thing too.
Oh okay. I wasn't sure about that since I don't think it's documented in the FEP, though it's been awhile since I've given it a read through.
-
only understood by Piefed? Not Lemmy
No, that's a Lemmy thing too.
rimu@piefed.social Do you send the
Undo(Announce(Create))as well for microblog compatibility? -
Looks like for Mastodon we just do a bare
Delete. -
Looks like for Mastodon we just do a bare
Delete.rimu@piefed.social got it, thanks. How do you reconcile the Delete coming from outside your domain? I would figure Mastodon would drop those Deletes.
Edit: that was confusing wording... I mean — how do you sign a Delete for an object that doesn't belong to your instance?
-
We only federate the deletion if it is in one of our local communities.
The activity is signed by the person who did it, so if Mastodon detects that the person deleting is not the author and doesn't know how to find out if someone is a moderator or not, that's their problem.
Mastodon has been dropping the ball on groups support for years so I didn't even bother to find out if they handle it well - I bet they don't.
-
We only federate the deletion if it is in one of our local communities.
The activity is signed by the person who did it, so if Mastodon detects that the person deleting is not the author and doesn't know how to find out if someone is a moderator or not, that's their problem.
Mastodon has been dropping the ball on groups support for years so I didn't even bother to find out if they handle it well - I bet they don't.
so if Mastodon detects that the person deleting is not the author and doesn’t know how to find out if someone is a moderator or not, that’s their problem.
It is not their problem. If your actor
Deletes an object that is owned by a different server, then your implementation of ActivityPub standard is incorrect:https://www.w3.org/TR/activitypub/#delete-activity-inbox
The side effect of receiving this is that (assuming the
objectis owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the sameid -
so if Mastodon detects that the person deleting is not the author and doesn’t know how to find out if someone is a moderator or not, that’s their problem.
It is not their problem. If your actor
Deletes an object that is owned by a different server, then your implementation of ActivityPub standard is incorrect:https://www.w3.org/TR/activitypub/#delete-activity-inbox
The side effect of receiving this is that (assuming the
objectis owned by the sending actor / server) the server receiving the delete activity SHOULD remove its representation of the object with the sameidI think
Announce(Delete(Object))skirts around that, though. Maybe not if you're being technical about it, but the shape of the activity is different enough to mean something else in 1b12-land:- A community/group-actor announced a
Delete - The object may or may not belong to the same domain as the community/group-actor or
Deleteactor - Verify that the community/group-actor and
Deleteactor are same-origin (might not need this if cross-instance moderation is a thing) - Verify that the
Deleteactor is a moderator of the community/group-actor as per 1b12
- A community/group-actor announced a
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@sk@utsukta.org mentioned in another thread that the way Hubzilla and threadiverse software handle group discussions is incompatible.
It got me thinking about whether that is true. At its core both FEPs (171b and 1b12, respectively) rely on a central "distributor" node to send activities to recipients.
@silverpill@mitra.social did further comparisons in thr text of 171b itself:
> Announce activity is used instead of Add. Conversation and related activities are synchronized between participants, but conversation backfilling mechanism is not specified.
The questions here are:
If threadiverse software federated out an Add in addition to Announce, would that satisfy basic synchronization (not backfill) requirements laid out by 171b? Is there any reason why Announce could not be used to facilitate private federated group discussions as well? Assuming visibility maintains scoped to addresses, I don't see any immediate reason why not...
-
I'm playing around with Offer activities in Fedify. The AP Vocab provides this, easy peasy.
✅ Alice OFFERS Book to Bob
✅ Bob ACCEPTS Alice's OFFEROr:
✅ Bob OFFERS Rotten Tomato to Alice
❌ Alice REJECTS Bob's OFFER----------------
But I'm not clear if this is right:
❓Alice ANNOUNCES OFFER of Labubu to Followers?
❓Bob OFFERS $10 for Labubu to Alice?
❓ Alice ACCEPTS Bob's OFFER of $10 for Labubu?
✅ Alice OFFERS Labubu to Bob
✅ Bob ACCEPTS Labubu
-
Your Home Feed is the inbox of an ActivityPub actor — in particular YOUR ActivityPub actor.
There could be an actor for each hash-tag, too.
You could even do Del.icio.us like things — and have actors for intersections of hash-tags, too.
These hash-tag actors' inboxes would need to be readable by anyone.
...
This could be a more ActivityPub like API alternative to Mastodon's "GET /API/v1/tags/{name}" API.
#ActivityPub #FediDev #FediDevs #Fediverse #HashTag #HashTags
-
@hongminhee How hard would it be for a future version of ActivityPub to simply back out JSON-LD support? Would there be a downside to this?
-
@julian Yes, POST to personal inbox sends a 404, POST to group inbox sends a 202 (I guess group inbox is how we communicate now).
-
@silverpill@mitra.social POSTing that inbox sends a 404?
-
@julian @liaizon https://activitypub.space/uid/1/inbox still returns 404. Perhaps group's inbox is working?
UPD: yes https://activitypub.space/category/5/inbox returns 202
