@steve 2.5GB of activitypub data out of a total of 3.4GB is not waste when I haven't seen the Creates that generated those Deleted entities?

@nick

@steve yes, the actor ones are the most egregious, because additionally to just wasting disk space, they waste resources when the instances try to dereference the actors that own the HTTP-Signature that signed the Delete and find them gone.

@nick

@mariusor @nick I don't know. See my comments about *boosting* where you may have cached entity without receiving a Create. Nick mentioned other examples (manual activity fetch, etc.).

@steve@social.technoetic.com @mariusor@metalhead.club @nick@hhmx.de Most deletes happen soon after posting, before many non-followers have fetched the object. Most posts are never boosted anyway. So maybe: if a post has never received an Announce, send the Delete only to followers; once it has, fall back to the current wider delivery.

The obvious race is a boost arriving just before the delete, but I think that still mostly works. The server receiving the Announce has to fetch the original, and by then it should get a 404 Not Found.

That would avoid a lot of unnecessary Delete fanout.

@hongminhee to me that's too much logic to stuff in an already complicated machine.

Just send the Delete to the smallest set of parties you absolutely **know** as being directly interested: the people that would send something your way: your following list. As a courtesy you can do it to the people that follow you, so they know to purge you from their list.

Everyone else will suffer a 404 and deal with it to the best of their abilities, which should be way less complicated than the rube goldberg'esque setups you guys seem to favour.

@steve @nick

@steve in my perspective designing a dissemination strategy on "what ifs" is a sure way to overcomplicate things, because in something as complex as ActivityPub you can come up with many corner-cases, and dealing with them all is a fool's errand.

See my sibling answer to Hong about why following/followers lists should be the default.

@nick

@mariusor @nick I saw that answer. I'm always skeptical when someone claims they have a trivial solution to a complex problem without providing any details. I agree that it seems superficially less complicated. Not federating Deletes at all is even simpler with less edge cases, but I wouldn't recommend it. As I suggested earlier, I think an FEP or even a blog article is a better medium for supporting your suggested approach with analysis, tradeoff identification, examples, risks, and so on.

@steve why do you consider this to be a "complex problem"?

From where I stand Deletes are a courtesy signal to the network that a node is gone, nothing more.

Only a fool would base their network consistency logic around Deletes only. (I would go one further and say this applies to all received activities, not just deletes)

And as long as an adjacent mechanism (which is fetching the node itself) exists, why make a big deal out of the situation?

@nick

@steve Also I'm not a theoretician, I don't like to think ahead 10 moves, analyse things, and put them on paper. That's just not how my brain works.

As you can probably infer from my previous comments, I speak about stuff when they affect me in a pragmatic way.

My basic thesis about my work on ActivityPub is: when you participate in a network make your participation the least disruptive for the other nodes: don't overshare, don't force them to process things when they don't expect them. (Another expression of the first part of Postel's law, if you will)

Being asked to justify it seems bonkers to me, it feels to be as self evident as any axiom.

@hongminhee @steve @nick

I think the claim being made is that Delete shouldn't be widely federated in the first place.

What you propose can help reduce the load from "everyone I know" toward "everyone I know who should have a copy", but at some point we really ought to consider that maybe a Create activity or an HTTP GET shouldn't result in indefinite syndication. In the case of HTTP GET you can use an HTTP cache, at least -- and the default lifetime shouldn't be "forever".