Email or username:

Password:

Forgot your password?
Gregory's posts Post Back to profile
Top-level
marius

@grishka

I see no mention of Add/Remove activities. Those, in my opinion (and according to the spec[1], [2]), are more suitable than Create/Delete activities for operations on collections.

Also I feel like this sentence should be generalised (emphasis mine) to "any" inbox:

> When an ActivityPub server receives in *its* inbox

We need to stop assuming all activities in AP should be sent _only_ to a shared inbox.

@activitypub

[1] w3.org/TR/activitypub/#add-act

[2] w3.org/TR/activitypub/#add-act

12 Feb 2021 at 12:08 | Wall-to-wall | Open on metalhead.club
6 comments
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?

12 Feb 2021 at 16:54 | Open on mastodon.social
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.

12 Feb 2021 at 17:00 | Open on metalhead.club
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

12 Feb 2021 at 17:06 | Open on metalhead.club
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.

12 Feb 2021 at 17:10 | Open on metalhead.club
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.

12 Feb 2021 at 17:25 | Open on mastodon.social
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.

12 Feb 2021 at 17:48 | Open on metalhead.club
Go Up