NodeBB

@julian @julian @shauna Federated private groups? The solution is conversation containers / FEP-171. Streams and Hubzilla have private groups, even Mitra has subscribers-only channels which technically are groups.

FEP-1b12 also supports private groups but there are no implementations yet.

@julian Mitra can backfill from Streams and Hubzilla, but it doesn't publish any collections yet.

Streams and Hubzilla have interoperable FEP-171b implementations, but I don't know about pulling the collection. They are more focused on private conversations where backfilling is not needed.

@julian

Streams and Hubzilla also implement context collection. They attach context to activities, it is an OrderedCollection, and its items are activities.

@angusmcleod @pfefferle @jesseplusplus @nutomic @rimu

The problem with duplicated remote comments seems to be gone (I am writing this comment from my own server).

However, I discovered another issue with remote comments like this one: https://socialhub.activitypub.rocks/t/1b12-vs-guppe-groups/5032/13.

Its ActivityPub ID is

https://socialhub.activitypub.rocks/ap/object/07746fd71af9af4f0789f9e4798f33ec

and its attributedTo property has the value of

https://oisaur.com/users/renchap

meaning "actor from oisaur.com created object on socialhub.activitypub.rocks", which generally shouldn't be allowed (unless this actor is explicitly authorized to do so).

I think Discourse should show the original ActivityPub ID of the remote comment when user clicks on the "ActivityPub" button. This probably affects federated activities as well.

@mikedev

>So now the default context is objects for Create|Update|Delete Note|Article and activities for everything else

Shouldn't Create|Update|Delete also have activities in context?
My understanding is that context collection is supposed to contain things that have collection ID as their context property.

If entity is an activity, its context is a collection of activities.
If entity is a post, its context is a collection of posts.

@julian @pfefferle @jesseplusplus @trwnh @mario @harmonicarichard @reiver @aslakr @Fitik

@julian Yes, I tested against NodeBB and other implementations mentioned in FEP-f228. Will add WordPress and Frequency to the list

@julian @pfefferle @jesseplusplus @harmonicarichard @trwnh

>yes, but they serve objects because we're radical implementors who don't do the whole activities thing sorry in advance.

My server can retrieve both kinds of collections I had concerns about diverging / conflicting implementations in the past, but the solution was found...

>We were testing against these URLs from @[email protected]'s personal blog

This context is working

>@[email protected] had a test URL but NodeBB fell over because it encountered an Object in next instead of a URL

I have a problem with this one because the first page doesn't have an id. I can adjust my code but the absence of id is unusual. For example, there is a next page (currently 404), and if we navigate to it, how prev would look like if the first page is anonymous?

>All top level or mid-level objects should report a resolvable context

Do you mean replies made by the context owner specifically? I think remote mid-level replies should not be required to have context (that would prevent non-implementing servers from participating).

@julian @pfefferle @jesseplusplus @trwnh +1 for chronological order requirement.
Are those implementations public? I'd like to test my context resolver against them too

@julian FEP-1b12 only works with activities,
but Lemmy also announces Page objects for (micro)blogs.

https://socialhub.activitypub.rocks/ap/object/443fb143373ebc5a4df190cddcd2da1f