Anytype Desktop 0.55.0 – Let’s Discuss

Hi all @n7cgu4sxyjzl @Code-Jack @Astro-L @ogokcocoball — thanks for raising this, and apologies the change wasn’t well communicated in the release notes. Quick clarification, then I’d like your input.

Why this was added

To stop orphaned objects piling up after you archive a parent — pasted images, files, etc. that nobody links to anymore. Many users have asked for this over time. The behaviour is non-destructive: children are moved to the Bin, not deleted, with an Undo in the toast and a hierarchical view in the Bin so you can see what came from where. Fair point that it becomes effectively destructive if you don’t notice the toast and later empty the Bin - we need to improve this flow to decrease the chance of accidental removal.

What changed in 0.55.0

This behaviour already existed in earlier releases for images and files created inside a page. In 0.55.0 we extended it in two ways:

  • from just images/files to all objects — anything you create inside another object via the slash menu’s Create object action;
  • to files, images, and objects created inside Collections — which is exactly the case you’ve been flagging in this thread.

That’s the scope change behind the surprise here.

How the rule works today

A child is cascaded only if both:

  1. It was created through a parent — as a block on a page, inside a Collection, or via a property — i.e. not at root level via the global “New” button.
  2. It has no other active backlinks.

This is tracked by a Created in context property that’s currently hidden. We’ll unhide it — the invisibility is the main reason the rule feels unpredictable.

@n7cgu4sxyjzl — the Origin = Drag’n’Drop pattern you noticed is a side effect of this rule, not the cause: dragging into a Collection sets that Collection as the creation context, so those images cascade; images created elsewhere and later added to the collection don’t.

Where we’d like your help

The core question is where the parent → child hierarchy feels natural, and where it doesn’t.

For blocks it seems clear-cut: an image you created inside a page is intuitively part of that page. For Collections, this thread suggests the opposite — a Collection feels more like a curated list of independent objects. Properties sit somewhere in between.

We’re leaning toward always asking for confirmation when cascade is about to happen — it’s the simplest rule and keeps you in control — but a per-container rule is also on the table.

A few quick scenarios — your answers will shape what ships next:

  1. Page with pasted images, then archive the page → cascade to Bin, or leave images in library?
  2. Object with an image as a property/cover, then archive the object → same question.
  3. Collection with added objects, then archive the Collection → cascade, or leave objects?
  4. Confirmation dialog every cascade, or only for some containers (which)?

Thanks for the engagement!