FEP-d36d: Sharing Content Across Federated Forums

Standards Fediverse Enhancement Proposals
, ,
1

Hello!

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.

2 Likes
2

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?

3

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?

4

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

3 Likes
5

Related:

2 Likes
6

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

7

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

8

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

3 Likes
9

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?

10

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.

2 Likes
11

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
1 Like
12

Yes, I guess my proposal is to update FEP-D36D to contain both

13

Relevant recent discussions from the threadiverse:

14

I’ve put out a call for Rust/Lemmy devs to implement this FEP:

1 Like
15

@0x1C3B00DA would you consider updating this FEP with some clarifications? I think there’s some risk of confusion due to the History section of the fep, which refers to a Reddit feature that is actually distinct from the type of group-to-group following you are proposing.

I go into some detail about these distinctions in my blog post above, which also includes several use case stories that could be added as references in this fep. Feel free to repurpose any of my writing for the fep.

I also think a better title for this fep would be ‘Group to Group Follows’.

16

Hi all. Sorry for my delay but I’m trying to devote some time to resolving some of the issues with this FEP.

The general consensus seem to be to merge this FEP with FEP-2100, but I’m having a bit of trouble understanding parts of 2100. There seem to be some conflicts between the prose describing gs:unbound and the specific examples given in the Some scenarios section:

The prose seems to indicate that

If gs:unbound: false or not present, then if !lug@gnusocial.net accepts the Follow request, it will Announce{*} entering its inbox to !hackers@instance.gnusocial.test.
If gs:unbound: true, then !lug@gnusocial.net will both accept the Follow request and submit a Follow request of its own to !hackers@instance.gnusocial.test.

But the first scenario given indicates that if Group B has gs:unbound: false, it should not be followable

  1. Group A follows Group B which has gs:unbound = false
  • A SHOULD NOT attempt to Follow B;
  • If B receives a Follow from A, it SHOULD reject.

Also, the prose indicated that gs:unbound: false is equivalent to no gs:unbound attribute present but there is a separate scenario given:

  1. Group A follows Group B which has no gs:unbound attribute
  • A SHOULD send a Follow to B;
  • B MAY Accept.

Since the lack of a gs:unbound attribute will be the most likely scenario (since most software hasn’t implemented FEP-2100), it makes sense to me that the lack of the attribute should be handled differently from a gs:unbound: false and scenario 3 still matches the behavior I described in FEP-d36d.

I don’t really understand the intent of gs:unbound so I’m not sure how to resolve this conflict (treat missing gs:unbound the same as gs:unbound: false vs treating them as separate cases). Does anybody have advice on this? Maybe @diogo?

@trwnh

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

My proposal was specifically about Group actors on servers implementing 1b12 so it assumes 1b12 as a starting point. It overrides some Follow behavior and some validation logic that happens upon receiving an activity in the inbox (though a lot of ppl seemed to miss this so maybe I should expand on it). I’m not sure how you make this more generic or how valuable it would be if a server is using Group actors differently than specified in 1b12.

@erlend_sh

I think there’s some risk of confusion due to the History section of the fep, which refers to a Reddit feature that is actually distinct from the type of group-to-group following you are proposing.

Yes, multireddits are distinct from this proposal (which I repeatedly tried to point out on kbin/lemmy) but a lot of users said this seemed like multireddits to them so I thought it was worth mentioning. I’ll add some text to further clarify how they’re different

I also think a better title for this fep would be ‘Group to Group Follows’.

:person_shrugging: Maybe. Your suggestion is explicit about the mechanism the proposal is defining, while my title was more indicative of the motivation/use case. But since a FEP’s slug and identifier is computed from its title I don’t think it’s a good idea to change it now.

1 Like
17

ID can be changed by an author, this is not prohibited by FEP rules. We can even put a markdown document with a redirection link on the old path.

I agree with @erlend_sh that “Group to Group Follows’” sounds better

18

FYI we dont have any plans to implement such functionality in Lemmy. Instead FEP-2100: Unbound Group and Organization seems much more promising.

From what I can tell the author of this FEP is also not associated with any other Fediverse project, so it is doubtfulthat this will ever get implemented. Under those circumstances it makes little sense to finalize it and make it appear official. I think that FEPs should only be approved if there is at least one real-world implementation.

19

FYI we dont have any plans to implement such functionality in Lemmy. Instead FEP-2100: Unbound Group and Organization seems much more promising.

Could you expand on this? Everyone in this thread seems to agree that this FEP and 2100 overlap and I’m working on merging the two. What about 2100 seems more promising than this FEP?

From what I can tell the author of this FEP is also not associated with any other Fediverse project

I didn’t know that was a requirement. For what it’s worth, i’ve made small contributions to multiple fediverse projects, including lemmy

20

Could you expand on this? Everyone in this thread seems to agree that this FEP and 2100 overlap and I’m working on merging the two. What about 2100 seems more promising than this FEP?

With 2100, if an instance goes down the community can still continue working based on a different instance. So it provides a level of redundancy and can also be used for migrating a community to another instance. With d36d its nothing more than automated crossposts and will break if an instance goes down. So theres not much benefit to implementing it.

I didn’t know that was a requirement. For what it’s worth, i’ve made small contributions to multiple fediverse projects, including lemmy

Its not an official requirement, just my personal opinion. Fact is that implementing such a feature will reveal cases where it doesnt work in practice like the FEP says, so the FEP should be changed to account for that. Such feedback isnt possible if there is no real-world implementation. Though I am probably hypocritical here because 2100 also doesnt seem to have any implementation. Though its marked as draft, so a compromise would be that an implementation must exist in order to mark an FEP as final.