Julian Fietkau@julian@fietkau.social: @mariusor @silverpill If your first example is allowed, then I don't know what “Clients MUST NOT embed non-anonymous collections in objects” means.

Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @julian@fietkau.social
marius@mariusor@metalhead.club (2026-04-04 19:45:43)
@julian I'm not sure if you're getting confused by a collection that is embedded into an object as a way to reduce request numbers, but still has a dereferenceable ID, and an anonymous collection/object that has no dereferenceable ID, so it can't be independently retrieved.

The first is a representation convenience that shouldn't be impacted by this FEP, and the second is well... unspecified... which leaves us in the same place as before this FEP was created by @silverpill
---Reply---
Julian Fietkau@julian@fietkau.social (2026-04-04 19:54:39)
@mariusor @silverpill If your first example is allowed, then I don't know what “Clients MUST NOT embed non-anonymous collections in objects” means.


---Replies---

Julian Fietkau@julian@fietkau.social (2026-04-04 20:04:42)
@mariusor @silverpill Wait – is that restriction only applicable to collection creation? With the context of the surrounding section, I could see that making pragmatic sense.

If so, I might prefer having that be clarified by rewording to e.g. “Clients MUST NOT attempt to create new collections by embedding non-anonymous collections in objects”. Substitute “create or modify” if existing collections should be restricted as well.