"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

Mario Vavti

@silverpill

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

The user has to be logged in at his home instance before starting an OWA attempt to another instance.

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

Actor is the remotely via OWA logged in actor., the HTTP requesti is signed by the thread owner.

julian

@[email protected] said in "FEP-171b: Conversation Containers" finally has been published::

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.

@[email protected] I wouldn't go as far as trusting the context owner either. I definitely subscribe to the principle of least privilege. I wouldn't trust any full object received unless actor === sender or a proof is supplied.

julian

@[email protected] said in "FEP-171b: Conversation Containers" finally has been published::

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.

Yeah, y'all keep making new FEPs and all I'm trying to do is consolidate them or recommend one.

@[email protected]

Scott M. Stolz

@julian

Yeah, y'all keep making new FEPs and all I'm trying to do is consolidate them or recommend one.

On the bright side, if we can come to some agreement on how to implement this stuff now, we won't have to make major changes later.

FenTiger

@silverpill

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

It checks whether the user has a session cookie. Hubzilla doesn't show a login form here; it could, but that wouldn't work so well for eg image fetches.

And then, after login, which instance generates activities?

FEP-61cf only covers authenticating the user. It doesn't tackle the question of what happens when the now-authenticated user writes a post. How should that post federate outwards, in such a way that other instances can trust it? I don't know how Hubzilla approaches this; maybe @Mario Vavti can comment.

Mario Vavti

@julian i get your point. But maybe in this case the trust question is more philosophical: do we want to trust the one we have the connection with - in this case the context owner or do we want to trust the author with which we are not connected at all and whose messages might be forged too - even with proof?

@silverpill

silverpill

@fentiger @mario

>It checks whether the user has a session cookie.

Ah, I see. Consider adding this information to the description of step 2.

silverpill

@mario

>Actor is the remotely via OWA logged in actor., the HTTP requesti is signed by the thread owner.

This violates same origin policy, but I will mention in the FEP that implementations may accept such activities if conversation owner is trusted.

julian

@[email protected] Some thoughts:

In this model conversations are managed by the actor that created the initial post of a conversation thread. Such conversations take place within a specific audience and may be moderated.

Would you consider relaxing this to allow for situations (e.g. forums) where the conversation thread starter is not necessarily the manager of the container?

In forums, topic participants (including OP) are equals, and the container would be managed by a separate actor (in my case, currently a 1b12 actor referred to in objects with audience).

Collection SHOULD have collectionOf property with value Activity.

I haven't seen collectionOf in the wild before, what purpose does it serve here?

silverpill

@mario @julian In FEP-fe34 security model the root of trust is the server. Messages are produced by servers, not by users, and server operator can impersonate any local user. We have to live with it because this is how ActivityPub works (unless the user is nomadic and uses FEP-ae97 client, but this is a different story).

From this perspective, someone I have a connection with is equal to any other user. Sure, I might trust servers used by my connections more than other servers, but I think this assessment is not reliable and shouldn't be used as an input to authentication procedure.

silverpill

@julian @mario @jupiter_rowland @benpate @fentiger @scott

>Would you consider relaxing this to allow for situations (e.g. forums) where the conversation thread starter is not necessarily the manager of the container?

As far as I know, in Streams OP and owner are identical, but you are right - they might as well be different. I'll mention this in the FEP.

>I haven't seen collectionOf in the wild before, what purpose does it serve here?

Again, this is what Streams does, I'm guessing this is because some context collections contain posts and not activities, and collectionOf tells you how to parse the collection without resorting to duck typing.

I would prefer to use an outbox property for containers.