Pre-Alpha ActivityPub-related bug reports
-
Evan Prodromoureplied to Evan Prodromou on last edited by
-
@julian @silverpill @trwnh So, what about returning the root object, like a `Note` or `Article`, with `replies` and `context` included?
-
Would it make sense to add
Threadas another type? (AP objects can have multiple types). So it'd be"type": ["OrderedCollection", "Thread"], that sort of thing? -
@[email protected] @[email protected] did mention the same, although support for sending an object with multiple types is unknown (to me, at least).
I fully expect some implementations to break when encountering such a thing.
-
infinite love ⴳreplied to Evan Prodromou on last edited by
@evan @julian @silverpill This goes back to a convo from yesterday about how to handle Activity types with content, which conceivably makes them "posts" in the sense of an "activity stream". ("John Created a Note" is a first-class item in much the same way "Sally Liked a Note" is also a first-class item in Facebook's activity feed, or "Alice Added 9 Images to a MediaAlbum" would be.)
If you put content on an Announce, then that Announce is ostensibly its own "post" in addition to being a share.
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@evan @julian @silverpill But yes, in most cases, you will probably be using types such as Note or Article.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @julian @silverpill OK. I mean, we just call that an `Object`.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @julian @silverpill especially in a forum thread, right? It's just not the place you put an `TentativeReject` activity or a `Relationship` object.
-
infinite love ⴳreplied to Evan Prodromou on last edited by
@evan @julian @silverpill In terms of a potential WIP FEP, I would tentatively define a Conversation as a Collection where each item has at least `content`. I would likewise define a MediaAlbum as a Collection where each item is an Image or Video. There are probably other type definitions that could make sense.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @julian @silverpill yeah, I just don't like the ducktyping on the 'content' property.
-
@trwnh @julian @silverpill I think the question here is "does a thread actually have any distinct properties of its own?"
Maybe a title, but that can also be inherited from either the first or most recent post. Many threaded discussion systems don't have thread objects at all, of course (email is perhaps the canonical example)
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
And I think that's better, especially because having significant semantics on collections starts getting confusing when e.g. you have collection pages flying around
Really I think most types which can be represented directly as a collection (e.g. image galleries) are best represented as an object that possess a collection, though not everyone might agree -
@erincandescent @julian @silverpill It makes sense for threads to have not just their own title, but also their own audience and moderators, as well as flags for whether the thread is pinned or locked.
-
@[email protected] said:
So I lean towards the idea that you should just redirect to the first thread in the post, and place the context (which when becomes just a collection of in-thread posts; an implementation detail) at another URL where it mostly becomes invisible to users.
That's why I'm still on the fence about this whole thing. In principle, a thread object can and does exist in software, but in practice there is lots of prior art that says otherwise.
That said, email might be a threaded chain of messages, but most email clients I know have standardized around representing them as a discrete topic, if only in the UI.
-
@trwnh @julian @silverpill (the other option is instead of redirection do
<link>tags, and then you can link to both if you wish; imagine including<link rel="as:context" href="...">) -
@julian @erincandescent @evan @silverpill Let me put it this way: the latter half of FEP-7888 can be summarized as "reifying context as an object, and specifically a Collection". If you *just* want the grouping, then it could be an arbitrary opaque IRI. But what you gain by reifying the context as an object is specifically the ability to give it metadata properties. Particularly things like `attributedTo` or `audience`. Maybe even `followers` or `outbox`. An opaque IRI cannot do this.
-
I think you could also put a summary or name on a Collection and use that for the title of the thread?
-
@trwnh @julian @evan @silverpill I never did the URI should be opaque; what I implied was that perhaps it should be an implementation detail URI as opposed to a directly visible one.
Some of this is that I wonder how decoupled such a thread truly is *semantically* from it's root post -
@erincandescent @julian @trwnh @silverpill a thread is a tree with a root. Every non-root node in the tree has an `inReplyTo` that points to one of the other nodes.
It's represented by a `Collection` in the `context` property of each object. (I don't like this, but it's common so we should just use it).
It's in reverse-chronological order.
If you started at the root node and walked the tree using the `replies` collection, you should visit exactly the same nodes as in the `context` collection.
-
@trwnh @evan @julian @silverpill bear in mind though that my thinking here is very heavily influenced by working with ActivityStreams 1, where Collections were not Objects. I still think that distinction was correct; but there's a lot of stuff that was changed in AS2 unnecessarily that I resent and perhaps I'm still grumpy about it
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@trwnh @julian @erincandescent @silverpill you can also get the whole thing! That's the big benefit of having a `Collection` -- you can retrieve it.
