Email or username:

Password:

Forgot your password?
Gregory's posts Post Back to profile
Gregory

I made my first FEP! It's about walls and any other similar experiences where people add things to someone else's collections.

git.activitypub.dev/ActivityPu

@activitypub #activitypub

11 Feb 2021 at 21:42 | Open on mastodon.social
16 comments
Groosha

@grishka @activitypub

Дуров: *убирает стену*
Гришка: *возвращает стену*
Тоже Гришка: *предлагает сделать стену повсеместной*

Офигенно!

11 Feb 2021 at 21:57 | Open on mastodon.ml
Gregory

@groosha вообще не предлагаю сделать повсеместной, предлагаю единый стандарт для тех, кто хочет в своём проекте реализовать стены)

12 Feb 2021 at 2:23 | Open on mastodon.social
a1ba-nyan
@grishka красивое число.
12 Feb 2021 at 2:25 | Open on expired.mentality.rip
Gregory

@a1batross ага, мне тоже понравилось, при том, что это sha256 от названия

12 Feb 2021 at 2:25 | Open on mastodon.social
a1ba-nyan
@grishka я даже прочитать пропозал не могу.

Какой-то у них сервер тормозной. ._.
12 Feb 2021 at 2:31 | Open on expired.mentality.rip
smallcircles (Humane Tech Now)

@grishka @activitypub nice, congrats!

Not directly part of your FEP, but I am wondering about the insertion point of items in an OrderedCollection. Assume this is implementation specific (e.g. alphabetically or just last in line). There's no 'index' property to specify desired location, correct?

12 Feb 2021 at 6:02 | Open on mastodon.social
Gregory

@humanetech well, if it's not an OrderedCollection, then it doesn't have an order (duh), so implementations sort items upon displaying it however they see fit 🤔

12 Feb 2021 at 16:48 | Open on mastodon.social
Sebastian Lasse, redaktor.me
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

@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

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