Pre-Alpha ActivityPub-related bug reports
-
@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 -
@[email protected] you're the first person to have noticed!
It's by design, but of course, can — and maybe should — change. It's part of @[email protected]'s FEP-7888 and its concept of a resolvable collection.
Mapping the topic URL to the top post (or perhaps a redirect to it) would ensure compatibility with Mastodon, but I am unsure of whether that is the best path forward.
-
@julian @silverpill why would anyone expect a Note/Article when fetching the URL for an entire thread/topic?
-
@trwnh @julian @silverpill I'd only expect a Note/Article when explicitly requesting the first post in a thread/topic, not when fetching the topic itself
-
@[email protected] @[email protected] that was my thought as well, and why NodeBB currently responds as it does.
Ideally it could be both an Article and a Collection, but now we're really committing to incompatibility there lol
-
@julian @trwnh @silverpill I mean... theoretically ActivityPub allows for multi-typed objects due to json-ld
But will anyone understand that correctly? No idea.
-
@thisismissem @julian @silverpill you could generate a document that is both an Article and a Collection but i'm gonna go out on a limb and say that this is probably *not* what you want. it's a thread. a thread is a Collection of posts. it's already "ideal" to represent it as a Collection and not an Article.
i suspect the source of confusion is that most other projects don't have threads/topics, they have reply trees which they show below the "top level" post. The URL there is for the post.
-
@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
-
@[email protected] 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 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
-
@[email protected] Got it, thanks!
fix: id on 1b12 announces · NodeBB/NodeBB@047d599
Node.js based forum software built for the modern web - fix: id on 1b12 announces · NodeBB/NodeBB@047d599
GitHub (github.com)
-
@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.
-
@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
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@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.
-
Evan Prodromoureplied to infinite love ⴳ on last edited by
@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 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.
