@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.

1. +1. I will replace webfinger address recommendation with a warning about possible compatibility issues.
2. I think observers (and other Application actors on the server) should use a shared key.

@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 @pfefferle@mastodon.social's personal blog

This context is working

>@jesseplusplus@mastodon.social 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

@trwnh I didn't say that actors always map to "users", though mapping actors to "accounts" is very common and is a good UI design practice. In my proposal Application actor is recommended, which is not a "user".

The idea of adding inboxes to collections, or that collections could be followed is not supported by the ActivityPub specification. I believe it is also wrong for other reasons, and I already said enough about that in FEP-2277 and in various discussions.

@julian

@scott

Yes, I'd like to subscribe to arbitrary threads. For example, I often subscribe to issues on Github/Codeberg, or watch selected topics on SocialHub.

Another reason is client to server ActivityPub. Even if we implement thread subscriptions in a non-federated way, clients still need to tell servers about subscriptions somehow.

@julian If these limitations don't prevent us from implementing any features, why they should be addressed?

The entire network is built around the idea that only actors can have inboxes and outboxes. I don't see what problem we solve by challenging this, but I can easily see how that makes things worse.

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

Section 5.3 Representing Places in ActivityStreams Vocabulary: https://www.w3.org/TR/activitystreams-vocabulary/#places

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

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