FEP-d36d: Group to Group Follows

[erlend-sh]

https://socialhub.activitypub.rocks/t/fep-d36d-sharing-content-across-federated-forums/3366

ActivityPub Groups following makes it easier for new, small communities to gain a foothold in the threadiverse by counteracting certain ‘winner takes all’ dynamics:

https://blog.erlend.sh/transitioning-r-rust-to-the-threadiverse

Prior kbin discussion: https://codeberg.org/Kbin/kbin-core/issues/65

[BentiGorlich]

Imo implementing it this way is not feasable for us. An easier way to solve the problem would a view where all magazines with the same name (i.e.: "technology") are displayed. Is that something that would fix the problem you're seeing?

[erlend-sh]

implementing it this way is not feasable for us

If you can explain why, preferably in the context of this thread, that’d be very helpful.

An easier way to solve the problem would a view where all magazines with the same name (i.e.: "technology") are displayed. Is that something that would fix the problem you're seeing?

Unfortunately it would not, and I explain why in the Transitioning.. blog post linked above.

[BentiGorlich]

Sorry, I missed that link. I see your problems now and get why just putting the mags together is not the solution you need. However I have a few problems with that proposition:

1. It is a lot of work to implement and then test it.
2. Since Lemmy does not implement it and most big communities are on Lemmy, us implementing it would have very little effect, since there are no big mBin instances, yet. So we would invest a lot of work for a, admittably nice, feature that will be of limited use because no one else is implementing it
3. Right now most software will probably just answer with a "Accept" to a request to follow a group. Which will be a problem if the feature is more widespread, beacause it should be manual accept only
4. What happens when instance A has magazine Y and Z from instance B, but magazine Y follows Z. Then a post to magazine Z will be send to magazine Y, too. Then we have a post that belongs to two magazines. I don't know if our current system allows it and I am also not sure if it should allow it :D
   So the options here are to
   1. have the same post multiple times in the db which would waste space
   2. just have the post once in the "original" magazine (which would kinda defeat the system in the first place, because it would then only work if an instance only follows magazine Y)
   3. remodel the db design to allow a post to have relations to multiple magazines (which is eigher a lot of work or a huge amount of work, depending on how one implements it)

Point 1 and 4 are the biggest ones for me. Right now we just do not have that much dev capacity. We are pretty much just 3-5 devs with limited free time to work on mBin. Take me for example: I have on average one evening per week that I can spend with mBin. If some one has a proposition to solve point 4 we can put this on the roadmap, but unless there is a good solution to that ...

I think most people (or most devs at least) hoped that the biggest/best magazine/community with a specific topic would just drown the other ones out, but that doesn't seem to happen since there are about 4 really big tech mgazines.

[zcdunn]

So we would invest a lot of work for a, admittably nice, feature that will be of limited use because no one else is implementing it

Limited use is better than no use. And the feature doesn't need a ton of implementers to be useful. If one project implements it, any groups hosted by that project can become supergroups, which benefits any user following that group.

Right now most software will probably just answer with a "Accept" to a request to follow a group. Which will be a problem if the feature is more widespread, beacause it should be manual accept only

That's a good point. There's another FEP that has the concept of an unbounded group. Maybe there needs to be a signifier like that to indicate that the hosting software is aware of this FEP and isn't responding automatically.

Then we have a post that belongs to two magazines. I don't know if our current system allows it and I am also not sure if it should allow it :D

But the post shouldn't belong to two magazines. In your example, a post is sent to magazine Z@B so Z owns that post. But Z Announces it to Y@A and Y has a copy. The post still belongs to Z. This should work in the exact same way as announcing a microblog post. My account may see announces from other accounts but it doesn't own those posts. They're still attributed to their original author.

have the same post multiple times in the db which would waste space

But if that's how you store an Announce post, then you're already doing that for microblog posts, right? And the alternative for link posts is current state, i.e. a new post in each community, which isn't any different from a copy of an existing post.

I think most people (or most devs at least) hoped that the biggest/best magazine/community with a specific topic would just drown the other ones out, but that doesn't seem to happen since there are about 4 really big tech mgazines.

Right. I think this view was always flawed. Not every server is aware of every other so we can't get to the point of one magazine dominating for a topic because everybody sees different amounts of content from each magazine/server.

[BentiGorlich]

But the post shouldn't belong to two magazines. In your example, a post is sent to magazine Z@B so Z owns that post. But Z Announces it to Y@A and Y has a copy. The post still belongs to Z. This should work in the exact same way as announcing a microblog post. My account may see announces from other accounts but it doesn't own those posts. They're still attributed to their original author. [...] But if that's how you store an Announce post, then you're already doing that for microblog posts, right? And the alternative for link posts is current state, i.e. a new post in each community, which isn't any different from a copy of an existing post.

Currently each post has one magazine which it belongs to. It is not easily possible to change that. We would need another table which stores the relation between a post and magazines. That would involve a big db change, which we could of course make, but it is not as easy... The "Announce" part is only used while creating the post it is not beeing stored in any way (afaik).

@e-five256 @melroy89 what is your opinion on this?

[zcdunn]

We would need another table which stores the relation between a post and magazines.

Is that how you handle microblog posts? When a user boosts a microblog post, does that store a copy of the original note? Does the original note still belong to its original author and the boosted note belongs to the user that boosted it?

My assumption with this proposal was that Groups and their posts could operate in basically the same way as Users and their posts. If you're handling Groups much differently than Users right now, I can see how that would require a big change.

[BentiGorlich]

I honestly am not sure how handle boosts right now. But as far as I can tell by looking at the code we just treat it as a special upvote. Is that correct @melroy89 @e-five256 ?

[e-five256]

I am certainly no expert at activitypub so excuse this question if it's nonsense. I'm going over the section on deduplication and just have one question:

What I'm not getting is whether an inbox activity from a Group is then meant to be emitted to any followers that are also of type Group.

Using different letters to not confuse things, if X, Y, Z all have linked communities both ways: X ⇆ Y ⇆ Z ⇆ X, and a Person sends an inbox activity to X, it will then send it to Y and Z, neither will have it, so they create it, send it to all their followers, does that include Groups Z and X for Y and Groups X and Y for Z? Perhaps it'd be smart enough to know it came from X, so don't bother sending it back to X, but it wouldn't know the other one is also following X.

It sounded like, it would still send the network traffic, but the original URL would remain the same from the inbox activity made by Person X and not be replaced by the activity being made by the local group? Which, granted, we do have uniques on original URLs, but would still be an activity send and rely on the other Group not changing the original URL

Or am I misunderstanding and Group inbox activities should not be shared with other Group followers?

[zcdunn]

@e-five256

What I'm not getting is whether an inbox activity from a Group is then meant to be emitted to any followers that are also of type Group.

I didn't think about that situation specifically, but I think the answer would be no. The Person submits a Create activity to X and its this create activity that triggers the sending to other groups. X then sends an Announce activity containing the original post to Y and Z. Both Y and Z receive the Announce and (if they already dedupe posts) check if a post with that url exists and store it if it does not. (Again, this is my understanding of how People to People microblogging works and Group to Group posts should function as similarly as possible. I thought that would ease implementation burden)

I may have used the wrong field here and that could be causing the confusion. It was my understanding that a post in lemmy/kbin/mbin has an id, which is a unique url representing that post, and a url which is the remote resource that the post is surfacing to the community. The deduplication should be done on the url of the remote resource, not the post itself. The idea with this is that resources would only be posted to these three Groups a total of once and all discussion for that resource could happen in a single thread for all three Groups. I would expect the entry UI to give some kind of warning if a user is trying to post a url that has already been posted to the set of linked Groups. (For text only posts, the content field could be hashed and used to dedupe in place of url).

[e-five256]

It was my understanding that a post in lemmy/kbin/mbin has an id, which is a unique url representing that post, and a url which is the remote resource that the post is surfacing to the community.

That's true (for us and /kbin, not familiar with lemmy), but normally the outbox of activities from an instance will all have the unique original URL of the instance you're on. I don't think you currently ever send an outgoing activity with a different original URL, just ingest incoming ones. Granted, I'm not trying to say this is a problem, I was just trying to get clarification.

The other thought I had was that if the connection was slow between X and Y in this situation, Z might actually hit Y with the activity before X does, which wouldn't be a concern if the original URL remains the same, but it seems that concern isn't valid if Z wouldn't be forwarding Group inbox activities to Y anyways.

I see FEP-2100 says

B MUST NOT forward this to other groups. If other groups expect to receive this activity, then they must follow !hackers@C as well.

That might be worth saying the same for d36d, it seems like otherwise it'd enter similar situations

[BentiGorlich]

I have thought about this again and in general I quite like the idea of it. My main head scratcher is: how should this be handled UI wise. Imo the forwarded posts by a group should still belong to the other group, however the posts could simply be combined in both cases so that you always see the posts of both groups, when looking at either one of them. I hope this was understandable :sweat_smile:

[zcdunn]

so that you always see the posts of both groups, when looking at either one of them

Yes! This is exactly what I intended. You may be browsing X@example.com and see posts owned by X@example.com and Y@example.com. Clicking on a post owned by Y would take you to the thread in Y. That way, subscribers to X and subscribers to Y see the same thread and comments and aren't having two separate discussions.

[github-actions[bot]]

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 6 days with no activity.

[github-actions[bot]]

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.

[github-actions[bot]]

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.