Federated private groups (Announce vs Add)
Technical Discussion
6
Posts
3
Posters
7
Views
-
@sk@utsukta.org 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.
@silverpill@mitra.social did further comparisons in thr text of 171b itself:
>
Announceactivity is used instead ofAdd. 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
Addin addition toAnnounce, would that satisfy basic synchronization (not backfill) requirements laid out by 171b? - Is there any reason why
Announcecould 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...
- If threadiverse software federated out an
-
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
AddwithAnnouncein FEP-171b. It is nice thatAddhas aRemovecounterpart, butRemoveis not used in practice. Of course, this can only happen if Hubzilla and Forte devs agree, since these are reference implementations -
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
AddwithAnnouncein FEP-171b. It is nice thatAddhas aRemovecounterpart, butRemoveis not used in practice. Of course, this can only happen if Hubzilla and Forte devs agree, since these are reference implementations@silverpill imo usingAnnounceinstead ofAdddoes not make any sense for conversation containers. You add/remove items to a collection right?
@julian @z6MkhPXNfiHDh2qSNjFzZ9yY27C1iHnHVbb1eaxuoiEe4tjk/actor" rel="nofollow noopener">Mike Macgirvin -
@silverpill imo using
Announceinstead ofAdddoes not make any sense for conversation containers. You add/remove items to a collection right?
@julian @z6MkhPXNfiHDh2qSNjFzZ9yY27C1iHnHVbb1eaxuoiEe4tjk/actor" rel="nofollow noopener">Mike Macgirvin@mario Yes, activities are supposed to be added to
Add.target.Announcewithtargetis kind of weird, but will be compatible with other federated forums.Alternatively, they can start using
Addinstead ofAnnounce, like we do. @julian Does that sound feasible? Your personal inbox still 404s but maybe the group inbox will work. -
@mario Yes, activities are supposed to be added to
Add.target.Announcewithtargetis kind of weird, but will be compatible with other federated forums.Alternatively, they can start using
Addinstead ofAnnounce, like we do. @julian Does that sound feasible? Your personal inbox still 404s but maybe the group inbox will work.> @silverpill@mitra.social said:
>
> Your personal inbox still 404s but maybe the group inbox will work.Unrelated to the topic at hand there was a regression in the codebase for the past month that caused the inbox to return a 404 even with a valid content type header.
I think that was the cause of the inbox 404
-
@mario Yes, activities are supposed to be added to
Add.target.Announcewithtargetis kind of weird, but will be compatible with other federated forums.Alternatively, they can start using
Addinstead ofAnnounce, like we do. @julian Does that sound feasible? Your personal inbox still 404s but maybe the group inbox will work.> @silverpill@mitra.social said:
>
> Alternatively, they can start usingAddinstead ofAnnounce, 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 @nutomic@lemmy.ml 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.)
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@scottjenson In my opinion, encryption is moot as long as the behaviour of not having a distinction between “recipients” and “mentioned accounts” persists.
@gracjan
-
> @silverpill@mitra.social 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 @nutomic@lemmy.ml 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.)
-
> @silverpill@mitra.social said:
>
> Your personal inbox still 404s but maybe the group inbox will work.Unrelated to the topic at hand there was a regression in the codebase for the past month that caused the inbox to return a 404 even with a valid content type header.
I think that was the cause of the inbox 404
-
What’s up with delivery addressing being in both #activitypub activities and objects? If my app publishes a nonpublic Create with different direct delivery targets than the created Object, what happens? What is supposed to happen? I know the spec recommends against it (suggests duplicating the addresses in both), but why was this considered a feature to allow? I think there should have been a non-AS2 envelope for addressing rather than embedding it (twice) into the content. You know, like email.
-
I hear you.
I guess for me, I'm not going to use social media for that kind of thing, but I've exchanged snail mail addresses with online acquaintances and not sure if I would ever do that via the Fediverse with the current implementations.
I can also see that in my head, my implementation would never have the private key server-side on a shared server, which would make it useless via the web. Honk and snac have spoiled me. But I could see having a private key in one of the mobile clients and never on a server.
-
@knapjack I understand where you are coming from. I might have agreed a few years ago. But encrypted messages need to be rock solid. Recently many governments the world over have shown they are more than willing to use the courts to subvert encrypted communications. Including forcing service providers like your friendly Masto admin to both hand over data and backdoor encryption.
-
I'm probably just one more vote on a "me too" pile, but it's not critical to me that social timeline 1:1 messaging be *encrypted*. It's important that I (the generic user) *understand* whether it is or isn't and behave accordingly.
If you have to pick a focus, I do strongly prefer that 1:1 or 1:few comms have a distinct workflow apart from regular/public timeline appearances, though. It makes mishaps less likely, like forgetting or mis-clicking "private" in that dropdown.
-
@scottjenson I'm excited that you're asking this question!
My preference is for usability improvements first. Other platforms already do encrypted private messages, and adding it won't make Mastodon easier to use. I think that's the core problem for the platform: removing barriers to sticking around without taking the cop-out of just copying what people are familiar with on other platforms.
My primary use of private messages is to ask people for email or Signal addresses when I only know how to contact them on Mastodon.
Secondary would occasionally be a “You OK?” message in reply to someone's post.
Apart from those, I think of Mastodon as a public space. Private communication isn't what it's for, and the UI shouldn't centre it.
