S
@trwnh @steve @raucao If this issue causes an imaginary software to produce invalid documents, then it is not a real issue.
Regarding hacky workarounds: no one is forced to use JSON-LD. The need for a workaround actually suggests that there is a bug in JSON-LD processors, which for some reason mess with property values when they are URIs. That doesn't make any sense.
@trwnh @steve @raucao I am not convinced that there is a problem in the first place.
ActivityPub says the identifier is https://www.w3.org/ns/activitystreams#Public. JSON publishers use full URI. Server implementations that perform JSON-LD processing (e.g. Iceshrimp) also produce full URI, they figured it out. Then, why make a change?
If this issue is purely theoretical, then it must be addressed without changing ActivityPub.
>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
@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.
Streams and Hubzilla also implement context collection. They attach context to activities, it is an OrderedCollection, and its items are activities.
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.
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.
@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.
>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 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?