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

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.