Delete activities for a Note are only federated to followers, mentioned users and relays #190

Closed
opened 2022-10-10 17:15:17 +00:00 by helene · 8 comments
Contributor

This means that notes federated to instances that do not follow these criteras (but are federated with the instance otherwise), e.g. via renotes, will never get deleted, as the Delete activity is never sent to them.

Ideally, the Delete activity should be federated to all known instances.

This means that notes federated to instances that do not follow these criteras (but are federated with the instance otherwise), e.g. via renotes, will never get deleted, as the Delete activity is never sent to them. Ideally, the Delete activity should be federated to all known instances.
Owner

I'm not sure about 1) how this would impact performance, especially on "well federated" instances and 2) how this would impact queues clogging up because of suddenly trying to contact instances that have been dead for a while.

Of course (2) is just a symptom of a differen problem, but since that's not (yet) fixed...

I'm not sure about 1) how this would impact performance, especially on "well federated" instances and 2) how this would impact queues clogging up because of suddenly trying to contact instances that have been dead for a while. Of course (2) is just a symptom of a differen problem, but since that's not (yet) fixed...
Owner

I guess implementation wise we should go by this paragraph from the AP spec:

Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.
-- https://www.w3.org/TR/activitypub/#shared-inbox-delivery

I guess implementation wise we should go by this paragraph from the AP spec: > Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known `sharedInbox` endpoints on the network. -- https://www.w3.org/TR/activitypub/#shared-inbox-delivery
Author
Contributor

Addendum: it seems deletes for DMs do not federate from FoundKey.

Addendum: it seems deletes for DMs do not federate from FoundKey.
Owner

I guess implementation wise we should go by this paragraph from the AP spec:

Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known sharedInbox endpoints on the network.
-- https://www.w3.org/TR/activitypub/#shared-inbox-delivery

While this is a MAY, I think that most of our users expect deletes to, well, do a best-effort to delete the post across the network.

> I guess implementation wise we should go by this paragraph from the AP spec: > > > Additionally, if an object is addressed to the Public special collection, a server MAY deliver that object to all known `sharedInbox` endpoints on the network. > -- https://www.w3.org/TR/activitypub/#shared-inbox-delivery While this is a MAY, I think that most of our users expect deletes to, well, do a best-effort to delete the post across the network.
Owner

Addendum: it seems deletes for DMs do not federate from FoundKey.

If you can please check that case also with the linked PR. This might have been caused by the instance panicking when trying to deliver to followers which are not allowed to see the post. Delivering to followers should now also only happen in the appropriate cases, but the check was missing before.

> Addendum: it seems deletes for DMs do not federate from FoundKey. If you can please check that case also with the linked PR. This might have been caused by the instance panicking when trying to deliver to followers which are not allowed to see the post. Delivering to followers should now also only happen in the appropriate cases, but the check was missing before.
Johann150 added a new dependency 2022-10-11 09:01:42 +00:00
Author
Contributor

I'm not sure about 1) how this would impact performance, especially on "well federated" instances

One could look at how Mastodon handles it (or Pleroma, or others), mastosoc seems to be doing fine on that regard, though. Pleroma isn't a shining example in performance or code quality, so that can be set aside somewhat (but it still manages fine).

and 2) how this would impact queues clogging up because of suddenly trying to contact instances that have been dead for a while.

I believe Misskey/FoundKey regularly fetch nodeinfos and keep information as to which instances are up-to-date, in database. Re-using that information shouldn't be a problem.

> I'm not sure about 1) how this would impact performance, especially on "well federated" instances One could look at how Mastodon handles it (or Pleroma, or others), mastosoc seems to be doing fine on that regard, though. Pleroma isn't a shining example in performance or code quality, so that can be set aside somewhat (but it still manages fine). > and 2) how this would impact queues clogging up because of suddenly trying to contact instances that have been dead for a while. I believe Misskey/FoundKey regularly fetch nodeinfos and keep information as to which instances are up-to-date, in database. Re-using that information shouldn't be a problem.
Owner

I believe Misskey/FoundKey regularly fetch nodeinfos and keep information as to which instances are up-to-date, in database. Re-using that information shouldn't be a problem.

As far as I saw there is nothing in the vein of "update instance info in a regular time interval", more like "whenever a post federates from/to an instance".

If I recall correctly, "automatically stop federating with dead instances" has been requested multiple times, which is what I was alluding to here and is a separate problem in my opinion. (Although I don't think there is an issue for it yet?)

> I believe Misskey/FoundKey regularly fetch nodeinfos and keep information as to which instances are up-to-date, in database. Re-using that information shouldn't be a problem. As far as I saw there is nothing in the vein of "update instance info in a regular time interval", more like "whenever a post federates from/to an instance". If I recall correctly, "automatically stop federating with dead instances" has been requested multiple times, which is what I was alluding to here and is a separate problem in my opinion. (Although I don't think there is an issue for it yet?)
toast closed this issue 2022-10-16 13:46:24 +00:00
Owner

Reopening this as it seems the performance hit is very big. We have to reconsider if this is a good idea and if so how the performance could be improved.

Reopening this as it seems the performance hit is very big. We have to reconsider if this is a good idea and if so how the performance could be improved.
Sign in to join this conversation.
No Label
feature
fix
upkeep
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: FoundKeyGang/FoundKey#190
No description provided.