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.
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,
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
What happens next in this FEP process? Does one of these proposals ‘win’?
Does someone just start writing code to implement one of them or is there a more formal process?
Link to FEP-2100
I consider FEP’s task to be:
- 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”.
Given their similarity does just merging the language and examples from FEP-2100 into FEP-D36D work?
They seem to be the same to me? Or are there any functional differences?
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.
There is nothing like “just merging” in FEP. The closest thing I can imagine is:
- Withdraw one of the proposals
- Update the other one to contain both proposals
Yes, I guess my proposal is to update FEP-D36D to contain both
Relevant recent discussions from the threadiverse:
I’ve put out a call for Rust/Lemmy devs to implement this FEP: