Email or username:

Password:

Forgot your password?
Top-level
Gregory

@mariusor I specifically didn't mention Add/Remove because they assume that the object is capable of existing outside of a collection. In my case, it is not. IMO they're better suited for things like blog-style tags, where a tag is a collection and you can Add/Remove something from it.

Suppose you Remove a post from a wall. Where does it go? Or you Remove a photo from a photo album, where does it go?

5 comments
marius

@grishka I understand now, it makes more sense now.

I didn't see this clarified in the document[1]. Maybe it would be helpful to mention this information and why you want Create/Delete for this case. :)

[1] Now that I know what you mean, I understand it from "should only be considered in its context." I still believe you should clarify further what it means.

marius

@grishka to your other questions: "where does an object that doesn't make sense outside a collection go?" I would reply that you shouldn't have such an object. Each object should have a unique IRI that can be referred by, independent of the collection (or collections) that it is a part of.

That's why in FedBOX I have generic read-only collections for objects: federated.id/objects

That collection is (I imagine) the same thing as you describe in the FEP.
1/2

@grishka to your other questions: "where does an object that doesn't make sense outside a collection go?" I would reply that you shouldn't have such an object. Each object should have a unique IRI that can be referred by, independent of the collection (or collections) that it is a part of.

That's why in FedBOX I have generic read-only collections for objects: federated.id/objects

marius

@grishka

The only objects that can't be referenced through that /objects collection are the ones that are not addressed to either the shared inbox of the server, or the ActivityPub public namespace. (ie, objects generated by private Activities - addressed only to specific actors' inboxes)

I'm still not 100% sure this is the way I want to keep things, but for now it serves me well, and lowers the complexity of managing objects' IRIs.

Gregory

@mariusor they do have unique URIs, but when they aren't in any collection, nothing links to them from anywhere, so they're kinda just floating there in the ether. Knowing that URI becomes the only way to discover them.

marius

@grishka so, I think that answers your question of where it goes: nowhere. The object remains, only the reference to it in the collection is removed. :D

Delete on an IRI transforms the object it refers to into a Tombstone, it does not remove it. That's why I think a Remove is needed for removing it from a collection.

Anyway, I think I'll stop pestering you with my feedback, mastodon is not the proper place for it. :D

If I ever get the time, I'll try to send you a better detailed document.

Go Up