NodeBB-ActivityPub Bridge Test Instance

Recent context collection news, in case you've missed:

- Mastodon: PR open
- Lemmy: PR merged

>the association of an as:announce activity with an as:target pointing to an as:Group actor.

I was thinking about adding target on Announce to bring FEP-1b12 and Conversation Containers closer to each other (in CC we have Add with target).

Can't Group simply be in to of Announce?

@julian The problem with mainstreaming is that everyone wants a piece of cake. Some people come to build, and I think that's fine, even if they take away something from existing projects. But there are also charlatans and scammers, and unfortunately faking achievements is very easy in Fediverse.

The good thing about grassroots / DIY spaces is that the latter category is non existent.

@julian Sure, I will add context to replies. Maybe in the next release

@angus @mario @jupiter_rowland @kopper

@julian @johnonolan @angus @evan

Why 301 and not 302?
I am using 302. Probably chose it because everyone else was using it.

@julian I implemented collection of posts in mitra. For now it is only attached to top-level posts (via context).

Here, for example: https://mitra.social/objects/019529ff-7a45-9752-16f2-a3e780746c1c

@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

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.

@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

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

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

@julian FEP-171b has its own way to backfill, also via context, but it is a collection of activities (such as Create).
I am currently trying to figure out how to make Containers compatible with NodeBB and others.

@julian

>Contexts can provide a thorough, comprehensive way to backfill an entire conversation. This is the biggest step we can take towards tackling the “fediverse is quiet” problem.

Sure, context is useful for backfilling, but is it the biggest step? I don't think so.

With FEP-1b12 or Containers, conversations are synced by default, so there is no need for backfilling. This is more efficient too: you don't need to retrieve context periodically to get an up-to-date view.

@julian Fixed: https://github.com/Chocobozzz/PeerTube/commit/038c41030858a98071200cdbb2b134aeaac7be9a

@julian I am affected by it as well, which is strange because previously federation with PeerTube worked fine. Perhaps they broke it in a recent release

@julian Did you report this bug to PeerTube?

@stevebate I'm using the term "origin" as defined in RFC-6454. This is also what FEP-fe34 refers to.

FEP-fe34 doesn't require embedded object to have same origin as the containing object (but it says that embedded object with a different origin shouldn't be trusted).

FEP-fe34 doesn't mention actor/key relationship because location of an actor document is not important for authentication via HTTP signatures. Only location of a key is important.

However, the actor/key relationship is important for authorization: "Can that actor own this public key?". FEP-fe34 currently doesn't provide a direct answer to this question, but it recommends the same origin policy as a general principle. According to this principle, actors shouldn't own objects on different servers, and therefore public key should have same origin as actor. As far as I know, all existing implementations behave in this way and don't put public key on a different server than actor. I also don't see any reason to do otherwise.

If some document contradicts both FEP-fe34 and implementer consensus, it is probably not correct and should be fixed. I can look into it if you point to a specific paragraph or sentence.

@NodeBB