How do we handle Groups (Reconciling FEP-400e and FEP-1b12)?
-
Absolutely! We're not trying to create a different implementation. We all have adopted FEP-1b12 already The goal is to understand how that works with the other standards which handle different, but related, concepts.
-
I'm not sure what all of this has to do with the original topic (reconciling FEP-400e and FEP-1b12). If you want to use FEP-1b12, that's fine. Others might prefer a different mechanism if it works better for their application. My question was specifically about private groups. Implementations based on FEP-400e already exist in the Fediverse. As far as I can tell, private groups based on FEP-1b12 exist only in a form of an RFC. So, unless there is some architectural flaw in FEP-400e, I don't real…
-
silverpill: Regarding FEPs: they do not describe how things are handled in practice. FEPs are proposals, and can be about anything, as long as it is related to Fediverse. I think what @nutomic meant was that FEP-1b12 attempts to summarise the most widely used approach to federation by Group actors, which I think it does. Nevertheless, as an implementor you're still faced with some questions like @silverpill's (i.e. about private groups), or how to deal with Mastodon's pending implementation, or how to think about this with respect to FEP-400e and FEP-7888. Navigating that thicket in a consistent way across the various implementations in #meeting:threadiverse-wg is the goal here. We definitely don't want to create another standard (que xkcd comic about a standard to standardise the existing standards).
-
It is true that many implementations of public groups used Announce activity to distribute posts before FEP-1b12, but FEP-1b12 also introduced additional protocol features. I don't know how widely these features are implemented today (perhaps this is something the working group could include in the report?).
-
angus: Navigating that thicket in a consistent way across the various implementations in #meeting:threadiverse-wg is the goal here. We definitely don’t want to create another standard silverpill: I don’t know how widely these features are implemented today (perhaps this is something the working group could include in the report?). devnull: we should conduct surveys to make sure we know what the implementation landscape looks like at current before attempting to write any guidelines. So I have to raise a tangential point here, which @devnull will probably be interested in as well: this is kind of what I set out to do in the WIP FEP i set out to start writing a week or two ago; at first it was 9988 "Federated Forums" to try to develop UX guidelines and map them to protocol affordances, but this eventually morphed into 8007 "A conformance profile for social networking services" (both titles pending of course). The general idea is that we all do certain things, and they map onto certain concepts, so we should map those common abstractions and primitives and try to concisely bound behavior of implementations such that you can actually know what to expect. I talk about this in 7888 a bit more, but there isn't actually a difference between the various spins of fediverse software. They're all just specific presentations of generic data. Or at least, on a protocol level, the abstractions of one specific presentation shouldn't leak in. What you have is objects or links, activities, collections. Those building blocks are then transformed into local entities, sure, but the primary focus should be on the protocol level building blocks and not on what any one platform assumes at a UX level. This is how you build commonalities. Practically speaking, a Note can be presented as a social media status or microblog entry or chat message or forum post or comment or whatever. And a Collection of Notes can be presented as a profile, thread, timeline, category, chat room, topic, et cetera. If the grouping is done with an explicit purpose, it ought to be declared as the context. With that said, there isn't really anything to "reconcile" about contextual grouping and distribution of activities. They're mostly orthogonal. The one point of intersection is whether any given actor will send out an Add or an Announce. And given that this is a working group for threaded conversations, it makes sense to me that the working group ought to describe how conversations are constructed. My personal opinion is that these conversations should be explicit based on context rather than implicit based on inReplyTo. Case in point: Consider the common forum use-case of "splitting a thread", which involves moving a post to another thread. That post may be a reply to a post from the original thread. It's important to be able to specify the intended grouping as a separate thing from who you're responding to.
-
-
@[email protected] said:
My personal opinion is that these conversations should be explicit based on context rather than implicit based on inReplyTo.
Yes, that makes a lot of sense. The building of a context via
inReplyTo
is decently reliable but suffers from scaling issues. Given a superior method of deriving context (that is, having one provided by the object) would make things simpler, and more complete, if combined with a good backfill method. -
@trwnh Thanks, this is very helpful. I agree with pretty much everything you've said. So from a practical perspective, for the purposes of implementation, this topic (i.e. reconciling FEP-400e and FEP-1b12) essentially boils down to trwnh: The one point of intersection is whether any given actor will send out an Add or an Announce I think it would be helpful to work through an example of where this particular point of intersection may become an issue. trwnh: Consider the common forum use-case of “splitting a thread”, which involves moving a post to another thread. That post may be a reply to a post from the original thread. It’s important to be able to specify the intended grouping as a separate thing from who you’re responding to. So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that?
-
Yeah, pretty much. angus: I think it would be helpful to work through an example of where this particular point of intersection may become an issue. Say you encounter an actor of type Group. You Follow the actor. You can't expect it to behave in any one particular way, but it will generally behave in one of these ways: It is a "normal" publishing actor. You will receive Create Object, Announce Object, Like Object, and so on. It is a boost bot. You will receive Announce Object for any object sent to it, mentioning it, etc. It is a 1b12 actor. You will receive Announce Activity, and other activities described in 1b12. It is a Smithereen-style actor. There will be a wall property, and it will send out Add activities where the target is that wall. The Add.object will also have a target, and this will match the Add.target as per 400e. Bonus: It is a context moderator. You will receive Add activities where the target is the object.context. It may also additionally be a "normal" publishing actor. So for any given "post", it might be a Create/Add/Announce/Announce-Create. This isn't limited to Group actors, but it is most prevalent in Group actors because of the popular (erroneous) interpretation of Group as equivalent to Facebook Groups. One final thing to note is that "normal" publishing actors and context moderators may be any type, not just Group -- there is no specific type dependency for these mechanisms, as they are the intended mechanisms. angus: So, this would result in something like: You receive Note 2 (with context A, a collection) which is inReplyTo Note 1 (with context A) You receive an Update to Note 2 and it now has context B (a collection)? OR perhaps you receive an Add of Note 2 to context B? In both 2 and 3, the inReplyTo would still be to Note 1, which would still have context A. @trwnh something like that? Yup. id: type: Note attributedTo: context: content: "I'm posting in a thread" --- id: type: Note attributedTo: inReplyTo: context: content: "This post is in a different thread but still replying to the first" --- id: type: Article attributedTo: inReplyTo: name: "Some Article" summary: "In which I reply to a forum post with an entire blog post. This is not part of any context." content: "
Lorem ipsum dolor sit amet...
"
Copyright © 2024 NodeBB | Contributors