Pre-Alpha ActivityPub-related bug reports
-
@julian I reported this to you because one user asked me by "why I can't discover this NodeBB thread from my instance?". I think this is going to happen quite often across the Fediverse.
Maybe in the future we will figure out how to deal with these collections, but right now this leads to a bad user experience@silverpill @evan@cosocial.ca @erincandescent @julian @evan@community.nodebb.org I'd prefer impls update to support showing threads/collections, rather than NodeBB being held back. UX will get better as other impls update.
At the very least, browser.pub can do it!
-
@evan @erincandescent @julian @silverpill I don't think a thread *has* to be a tree -- it's a set. The "reply tree" is a separate structure. Threads can be forked out of other threads.
(I also dislike "reverse chron" and heavily favor "forward chron", but custom sorting of collections is not well-specced rn so that's a future step.)
@trwnh @evan @erincandescent @julian +1 for forward chron, that way you can start displaying posts without fetching the whole thread
-
@trwnh @evan @erincandescent @julian +1 for forward chron, that way you can start displaying posts without fetching the whole thread
@silverpill @trwnh @erincandescent @julian Use the `last` property to start with the oldest page.
-
@silverpill @trwnh @erincandescent @julian Use the `last` property to start with the oldest page.
@silverpill @trwnh @erincandescent @julian Also, I think you're imagining some kind of pre-order traversal sorting. If you want that, it's a lot easier to just walk the `replies` tree.
-
@silverpill @evan@cosocial.ca @erincandescent @julian @evan@community.nodebb.org I'd prefer impls update to support showing threads/collections, rather than NodeBB being held back. UX will get better as other impls update.
At the very least, browser.pub can do it!
@trwnh @silverpill @evan @julian @evan so, truthfully, I'm ambivalent to whether a thread object exists. But if it does, I feel like it should probably be reified distinctly from the thread collection primarily because I don't think treating collections as objects is a good idea. Maybe I'm wrong, but that's my strongly held opinion!
And yeah, then we can give threads a following collection and let people follow them as they wish. -
@trwnh @silverpill @evan @julian @evan so, truthfully, I'm ambivalent to whether a thread object exists. But if it does, I feel like it should probably be reified distinctly from the thread collection primarily because I don't think treating collections as objects is a good idea. Maybe I'm wrong, but that's my strongly held opinion!
And yeah, then we can give threads a following collection and let people follow them as they wish. -
@silverpill @trwnh @erincandescent @julian Use the `last` property to start with the oldest page.
@evan @silverpill @erincandescent @julian just seems backwards to me, for no real reason. if you wanted reverse chron viewing of a forward chron collection, then it makes sense to fetch `last` and page backwards.
at the very least, `startIndex` as a property of OrderedCollectionPage makes **way** more sense with a forward chron presentation.
-
@evan @silverpill @erincandescent @julian just seems backwards to me, for no real reason. if you wanted reverse chron viewing of a forward chron collection, then it makes sense to fetch `last` and page backwards.
at the very least, `startIndex` as a property of OrderedCollectionPage makes **way** more sense with a forward chron presentation.
@trwnh @silverpill @erincandescent @julian
It's bad for caching to do forward chron, which is why we don't do it anywhere else.
Also, it does not help you build a tree structure; older nodes are not necessarily at the top of the tree.
-
@trwnh @silverpill @evan @julian @evan so, truthfully, I'm ambivalent to whether a thread object exists. But if it does, I feel like it should probably be reified distinctly from the thread collection primarily because I don't think treating collections as objects is a good idea. Maybe I'm wrong, but that's my strongly held opinion!
And yeah, then we can give threads a following collection and let people follow them as they wish.@trwnh @evan @evan @julian @silverpill and to be clear my ambivalence about whether there should be a thread object comes primarily because I don't think this is a point on which we will ever get universal agreement
It's an area where I feel the only real route is the "why not both?" compromise that doesn't really make anyone happy -
@trwnh @evan @evan @julian @silverpill and to be clear my ambivalence about whether there should be a thread object comes primarily because I don't think this is a point on which we will ever get universal agreement
It's an area where I feel the only real route is the "why not both?" compromise that doesn't really make anyone happy@erincandescent @julian @evan@community.nodebb.org @trwnh @silverpill Standards are about making arbitrary decisions in the pursuit of uniformity.
-
@trwnh @silverpill @erincandescent @julian
It's bad for caching to do forward chron, which is why we don't do it anywhere else.
Also, it does not help you build a tree structure; older nodes are not necessarily at the top of the tree.
@evan @silverpill @erincandescent @julian why is it bad for caching? it seems like the opposite to me -- reverse-chron means that pages are constantly updating and are almost never consistent! each new item in the collection pushes everything else behind it, and the last item of the page overflows into becoming the first item of the next page. if you did forward-chron, you could freeze "page 1" as soon as it got full, and move onto "page 2".
also, a viewer can easily tell where they left off.
-
@evan @silverpill @erincandescent @julian why is it bad for caching? it seems like the opposite to me -- reverse-chron means that pages are constantly updating and are almost never consistent! each new item in the collection pushes everything else behind it, and the last item of the page overflows into becoming the first item of the next page. if you did forward-chron, you could freeze "page 1" as soon as it got full, and move onto "page 2".
also, a viewer can easily tell where they left off.
@trwnh @silverpill @erincandescent @julian oh, yes, that's true, if you do "volatile paging" (last 20 pages).
If you have reified pages (item goes in one page and stays there), once the pages are full, they don't change (except for `Remove` activities).
Don't do volatile paging.
If you use reified pages, an add to a reverse-chron collection will typically have changes to `first` and the Collection itself.
-
@trwnh @silverpill @erincandescent @julian oh, yes, that's true, if you do "volatile paging" (last 20 pages).
If you have reified pages (item goes in one page and stays there), once the pages are full, they don't change (except for `Remove` activities).
Don't do volatile paging.
If you use reified pages, an add to a reverse-chron collection will typically have changes to `first` and the Collection itself.
@trwnh @silverpill @erincandescent @julian
If you have bidirectional links (`first` and `last`) you can have stable collections with rev-chron or forward-chron. So, fair point.
-
@evan @silverpill @erincandescent @julian why is it bad for caching? it seems like the opposite to me -- reverse-chron means that pages are constantly updating and are almost never consistent! each new item in the collection pushes everything else behind it, and the last item of the page overflows into becoming the first item of the next page. if you did forward-chron, you could freeze "page 1" as soon as it got full, and move onto "page 2".
also, a viewer can easily tell where they left off.
-
@trwnh @silverpill @erincandescent @julian
If you have bidirectional links (`first` and `last`) you can have stable collections with rev-chron or forward-chron. So, fair point.
@evan @silverpill @erincandescent @julian Yeah, my point is that it seems almost entirely conventional whether to have "reverse" mean first.next.next... or last.prev.prev... -- and I favor the latter approach because it makes more sense imo, no double-inversion ("reverse-reverse chron", anyone?)
-
@evan @silverpill @erincandescent @julian Yeah, my point is that it seems almost entirely conventional whether to have "reverse" mean first.next.next... or last.prev.prev... -- and I favor the latter approach because it makes more sense imo, no double-inversion ("reverse-reverse chron", anyone?)
@trwnh @silverpill @erincandescent @julian Except for most interfaces, your first page is the current stuff, and you go back in time to find earlier stuff.
-
@trwnh @silverpill @erincandescent @julian Except for most interfaces, your first page is the current stuff, and you go back in time to find earlier stuff.
@evan @silverpill @erincandescent @julian This is what I meant by "conventional". On a forum thread, you generally read forward. On social media like Twitter, there is a heavy bias toward going reverse. And some interfaces even let you choose ascending or descending order.
-
I may regret creating this topic but here goes.
If you experience a bug or other unexpected behavior while using NodeBB and its related ActivityPub integration, please post it here so it can be tracked and resolved.
No formal process as of yet, and we're still at pre-alpha so expect many things to be broken or unavailable
I received an activity with this ID:
https://community.nodebb.org/post/100125#activity/create/1719328808532#activity/announce/1719328833687It has two #-signs. I think it is not a valid URI: https://datatracker.ietf.org/doc/html/rfc3986#section-3.5
A fragment identifier component is indicated by the presence of a number sign ("#") character and terminated by the end of the URI.
