"FEP-171b: Conversation Containers" finally has been published:

silverpill

fep/fep/171b/fep-171b.md at main

fep - Fediverse Enhancement Proposals

Codeberg.org (codeberg.org)

Conversation Containers are conceptually very similar to FEP-1b12: activities are sent to a conversation owner, who manages the conversation and synchronizes it between participants. Differences are mostly superficial and may disappear in the future.

#FEP #ConversationContainers #ActivityPub

Ben Pate 🤘🏻

@silverpill

I’m super interested in all of these efforts to improve conversations and relies.

This looks like it’s pulled from Streams, yes? Which means it’s not related to the Forums and Threaded Discussions Working Group, is that right?

There are some cool ideas in here. Hopefully we can consolidate all of them to arrive at a single standard to implement.

silverpill

@benpate Yes, this is a description of what Streams does with some minor additions of my own. It is not officially produced by the Working Group but they are aware of this FEP and we are trying to figure out how to arrive on a single standard.

Conversation Containers help bridge the gap between the "threadiverse" (which mostly uses FEP-1b12) and the micro-blogging space, where this mechanism can be used to implement reply controls and followers-only posts.

Jupiter Rowland

@Ben Pate

This looks like it’s pulled from Streams, yes? Which means it’s not related to the Forums and Threaded Discussions Working Group, is that right?

Conversation Containers were originally built on and for (streams), yes. They were pretty much done some nine months ago.

#FediMeta #FediverseMeta #CWFediMeta #CWFediverseMeta #Streams #(streams) #ConversationContainers

Mario Vavti

@silverpill in regard to authentication: isn't it sufficient to trust the sender at last? In this case the context owner?

Let's assume this situation: an actor is remotely authenticated at a server via OpenWebAuth and comments on a post there. No proof can be added and the object is not yet available at the actors origin server. In this case the message will be rejected allthough its authenticity is verified.

silverpill

@mario If conversation participants do not perform authentication procedure described in the FEP, the owner will be able to impersonate other participants (or anyone, if conversation is public) by sending an Add(Create(Note)) activity where Create(Note) is forged.

The argument can be made that if you participate in a conversation, you necessarily trust the owner (Lemmy et al operate with this assumption), but I'm not convinced that it is true.

>In this case the message will be rejected allthough its authenticity is verified.

How other servers can verify messages made by remotely authenticated actor? I'm not familiar with OpenWebAuth

Mario Vavti

@silverpill

How other servers can verify messages made by remotely authenticated actor? I'm not familiar with OpenWebAuth

Basically the visitor is authenticated by exchanging an encrypted token: #^https://codeberg.org/fediverse/fep/src/branch/main/fep/61cf/fep-61cf.md

silverpill

@mario 61cf explains how to log in to "target" instance using "home" credentials, but I can't follow the algorithm past this step:

>2. The /magic endpoint at the user's home instance first checks that the user is logged in.

How does it check that the user is logged in? Does it present a login form?

And then, after login, which instance generates activities?

What URI is being put into actor field of activity, and what URI is being put into keyId parameter of HTTP signature?

cc @fentiger