Pre-Alpha ActivityPub-related bug reports
-
@julian @silverpill why would anyone expect a Note/Article when fetching the URL for an entire thread/topic?
@trwnh @julian Because it is not clear how client should display this collection. Searching for URL is a common UI pattern: user expects to see a post or a profile as a result (this is not unique to Mastodon).
Server can attempt to fetch the first item in a collection, but NodeBB's FEP-7888 collection doesn't identify itself as a "thread". It has "OrderedCollectionPage" type and properties that many other collections also have
-
@trwnh @julian Because it is not clear how client should display this collection. Searching for URL is a common UI pattern: user expects to see a post or a profile as a result (this is not unique to Mastodon).
Server can attempt to fetch the first item in a collection, but NodeBB's FEP-7888 collection doesn't identify itself as a "thread". It has "OrderedCollectionPage" type and properties that many other collections also have
@silverpill@mitra.social said:
NodeBB's FEP-7888 collection doesn't identify itself as a "thread".
That's because I am not aware of a clear way to signal that my collection is a thread.
Lemmy uses
as:Page, which is far too generic of an object type to signal as a thread. Mastodon doesn't even have an external concept of a conversation (oStatus conversation notwithstanding) -
@julian The URL of this topic is https://community.nodebb.org/topic/17867/pre-alpha-activitypub-related-bug-reports
When I make a request with AP Accept header, the server responds with aCollection. Technically, this is not wrong, but I think most people would expect a top-level post (Note / Article) when making such request@julian Another report: when NodeBB generates an
Announce(Create)activity, the ID ofAnnouncehas wrong origin. Here's an example:{ "@context": "https://www.w3.org/ns/activitystreams", "actor": "https://community.nodebb.org/category/30", "id": "https://mitra.social/objects/01920059-5b7c-203f-fc4e-285ec442c032#activity/announce/1726582718443", "object": ... "type": "Announce" }ID indicates that activity has originated on my server, but this is not possible
-
@trwnh @julian Because it is not clear how client should display this collection. Searching for URL is a common UI pattern: user expects to see a post or a profile as a result (this is not unique to Mastodon).
Server can attempt to fetch the first item in a collection, but NodeBB's FEP-7888 collection doesn't identify itself as a "thread". It has "OrderedCollectionPage" type and properties that many other collections also have
@silverpill @julian Searching for the URL should give you what that URL represents. If you want the post, search for the URL of the post specifically.
-
@silverpill@mitra.social said:
NodeBB's FEP-7888 collection doesn't identify itself as a "thread".
That's because I am not aware of a clear way to signal that my collection is a thread.
Lemmy uses
as:Page, which is far too generic of an object type to signal as a thread. Mastodon doesn't even have an external concept of a conversation (oStatus conversation notwithstanding)@julian @silverpill We could define a dedicated type for Thread or Conversation or whatever you want to call "a Collection that contains only "post" objects", but it would still be a Collection as well. I think this was something I was considering for a FEP that I ended up never really writing because it felt unnecessary and also very premature. The general idea is to define some way to know what a Collection "contains" -- is it a Conversation or a MediaAlbum or whatever. The problem is taxonomy
-
@julian @silverpill We could define a dedicated type for Thread or Conversation or whatever you want to call "a Collection that contains only "post" objects", but it would still be a Collection as well. I think this was something I was considering for a FEP that I ended up never really writing because it felt unnecessary and also very premature. The general idea is to define some way to know what a Collection "contains" -- is it a Conversation or a MediaAlbum or whatever. The problem is taxonomy
@julian @silverpill Really we need to take a step back and first define what a "post" object is. I'm tentatively leaning toward "any object that has content", but I'm sure there are plenty of edge cases I haven't accounted for that will pop up when thinking more deeply about the issue.
-
@julian @silverpill Really we need to take a step back and first define what a "post" object is. I'm tentatively leaning toward "any object that has content", but I'm sure there are plenty of edge cases I haven't accounted for that will pop up when thinking more deeply about the issue.
@trwnh @julian @silverpill Content types? Note, Article, Image, Video, Audio, Document? That should cover most Web content collections.
If you want to add an extension (Listicle, say) you could multi-type with the most appropriate Activity Vocabulary content type (`type`: ['buzz:Listicle', 'as:Article']`).
-
@trwnh @julian @silverpill Content types? Note, Article, Image, Video, Audio, Document? That should cover most Web content collections.
If you want to add an extension (Listicle, say) you could multi-type with the most appropriate Activity Vocabulary content type (`type`: ['buzz:Listicle', 'as:Article']`).
-
@julian @silverpill @trwnh So, what about returning the root object, like a `Note` or `Article`, with `replies` and `context` included?
-
@trwnh @julian @silverpill Content types? Note, Article, Image, Video, Audio, Document? That should cover most Web content collections.
If you want to add an extension (Listicle, say) you could multi-type with the most appropriate Activity Vocabulary content type (`type`: ['buzz:Listicle', 'as:Article']`).
@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.
-
@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.
@evan @julian @silverpill But yes, in most cases, you will probably be using types such as Note or Article.
-
@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.
@trwnh @julian @silverpill OK. I mean, we just call that an `Object`.
-
@evan @julian @silverpill But yes, in most cases, you will probably be using types such as Note or Article.
@trwnh @julian @silverpill especially in a forum thread, right? It's just not the place you put an `TentativeReject` activity or a `Relationship` object.
-
@trwnh @julian @silverpill OK. I mean, we just call that an `Object`.
@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 @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.
@trwnh @julian @silverpill yeah, I just don't like the ducktyping on the 'content' property.
-
@julian @silverpill We could define a dedicated type for Thread or Conversation or whatever you want to call "a Collection that contains only "post" objects", but it would still be a Collection as well. I think this was something I was considering for a FEP that I ended up never really writing because it felt unnecessary and also very premature. The general idea is to define some way to know what a Collection "contains" -- is it a Conversation or a MediaAlbum or whatever. The problem is taxonomy
@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 -
@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.
-
@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@akko.erincandescent.net 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@mastodon.social @evan@cosocial.ca @silverpill@mitra.social
-
@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@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="...">) -
@erincandescent@akko.erincandescent.net 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@mastodon.social @evan@cosocial.ca @silverpill@mitra.social
@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.
