This is a discussion thread for the proposed FEP-d36d: Sharing Content Across Federated Forums.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.
Summary
New instances on the threadiverse (servers that implement ActivityPub with FEP-1b12) are often seeded with forums for common interests, leading to multiple servers having similar forums. Users may dislike having to follow what they perceive to be “duplicate” forums or keep up with multiple discussions on the same topic across multiple servers. This document describes a method for allowing Group actors to share content to reduce posting of a single link multiple times, which reduces what users see as “duplicate” posts and fragmented conversations across multiple forums.
This seems conceptually similar to FEP-2100 but there’s no mention of that. Likewise, there is Streams and its copiedTo property, which signals a similar replication strategy (albeit tied more closely to “nomadic identity”). Were these considered by the authors of this FEP?
Hey, author here. I wasn’t aware of either of these examples. I’ll take a closer look at FEP-2100 later though after a quick skim it does sound pretty similar. Do you have a link for any documentation of the copiedTo property you mentioned?
There is streams/FEDERATION.md at dev - streams - Codeberg.org and you could also get in touch with @macgirvin about this. It seems like the general idea across all three systems is to Follow all other replicas. It would be worth collaborating on this if the use cases can be addressed by a common proposal. (Off the top of my head, copiedTo or unbound might actually overlap partially with alsoKnownAs as well.)
Yes, came here to mention that. Note that the discussion thread for this FEP is found under its original name and started by @diogo at: FEP-8485: Unbound Actor
Allow people to publish their designs on how stuff can be done
Collect feedback
In particular, it’s job is not to mandate something should be implemented in a particular way across the Fediverse. Instead it offers options. So there is no winner decided within FEP, instead the FEP with implementations “wins”.
you could use any or all of the properties. based on a cursory look at it, it looks like unbound is a boolean that hints you should respond with a reciprocal follow request, while copiedTo specifies the actor id(s) for which replication is occuring. this FEP doesn’t seem to specify any related signals.
also this FEP makes reference to 1b12, while the other mechanisms do not. i’m not sure that the core of this proposal actually depends on 1b12 in any way, except to override some of its behaviors around Follow. otherwise, it looks like it forces 1b12 handling for no good reason. it could be made more generic by describing only the Follow logic, but at that point it starts to be very similar to 2100. although 2100 is a bit underspecified with regards to the LD context.
if i had to write a synthesised FEP for this use case, i’d consider using alsoKnownAs or some similar property for pointing to replicated actors, as well as some other mechanism to know that you should send a reciprocal follow request… or perhaps the reciprocal follow request can always be sent? unsure, haven’t thought about this deeply yet. and for alsoKnownAs it’s implied that resolving those identifiers will return the exact same resource/subject, which might not be exactly the case if you are dealing with ad-hoc replication rather than something with stricter guarantees.
