Federated private groups (Announce vs Add)

technical-discussion·Technical Discussionbyjulian

Federated private groups (Announce vs Add)

@[email protected] mentioned in another thread that the way Hubzilla and threadiverse software handle group discussions is incompatible.

It got me thinking about whether that is true. At its core both FEPs (171b and 1b12, respectively) rely on a central "distributor" node to send activities to recipients.

@[email protected] did further comparisons in thr text of 171b itself:

> Announce activity is used instead of Add. Conversation and related activities are synchronized between participants, but conversation backfilling mechanism is not specified.

The questions here are:

If threadiverse software federated out an Add in addition to Announce, would that satisfy basic synchronization (not backfill) requirements laid out by 171b?
Is there any reason why Announce could not be used to facilitate private federated group discussions as well? Assuming visibility maintains scoped to addresses, I don't see any immediate reason why not...

View original on activitypub.space

Comments10

Nutomic

lemmy.ml

Is there any reason why Announce could not be used to facilitate private federated group discussions as well? Assuming visibility maintains scoped to addresses, I don’t see any immediate reason why not…

Private communities are already implemented in Lemmy 1.0 using Announce. Here is the RFC with details, and you can test it on voyager.lemmy.ml.

julian reply

activitypub.space

Thanks @[email protected]! I was wondering about that, so good to know it's possible.

silverpill

mitra.social

@julian @sk

I wouldn't want to send two activities because that doubles the number of delivery requests. But I think implementations can easily accept both types of activities (mitra already does that).

Also, I don't mind replacing Add with Announce in FEP-171b. It is nice that Add has a Remove counterpart, but Remove is not used in practice. Of course, this can only happen if Hubzilla and Forte devs agree, since these are reference implementations

cc @mario @highlander

Mario Vavti reply

hub.somaton.com

@silverpill imo using Announce instead of Add does not make any sense for conversation containers. You add/remove items to a collection right?

@julian @Mike Macgirvin

silverpill reply

mitra.social

@mario Yes, activities are supposed to be added to Add.target. Announce with target is kind of weird, but will be compatible with other federated forums.

Alternatively, they can start using Add instead of Announce, like we do. @julian Does that sound feasible? Your personal inbox still 404s but maybe the group inbox will work.

@mike @sk

julian reply

activitypub.space

> @[email protected] said: > > Alternatively, they can start using Add instead of Announce, like we do. @julian Does that sound feasible?

I personally have no problem with it (after all, I advocated in OP to just send both activities)

But I know @[email protected] will absolutely veto the discussion because it is a breaking change for the entire threadiverse, and he is not wrong.

There is a third option... and that is to send a single multi-typed activity 🤣 maybe this is the turning point for adoption of multi type activities! (Of course I'm only half joking because I'm sure that'll be ruled breaking and unfeasible too.)

cc @[email protected]

silverpill reply

mitra.social

@julian I think Lemmy can keep sending Announce, but accept Add(Activity) as equivalent. FEP-171b implementers can do the reverse. That's easy and doesn't require any breaking changes. @nutomic @mario

Please don't use multi-typing :]

Nutomic reply

lemmy.ml

Yes that would be doable, feel free to open an issue.

julian reply

activitypub.space

Is this what Mitra does now for 171b/1b12 cross-compatibility?

silverpill reply

mitra.social

@julian @mario Yes, it supports both Add and Announce. However, wrapped activities are simply added to a conversation, there is no concept of "group" yet.