FEP-1b12: Group federation

[SorteKanin]

@trwnh

something like this might work?

I meant how would the actor be written using the custom type approach that I proposed, if the way I wrote it before wasn’t quite right . I’m not really familiar with JSON-LD.

@trwnh

type represents the “is a” relation, and is in some ways a statement of class or category. using a property like constrainedBy is more precise.

I don’t agree really. This seems to be some object-oriented way of thinking about it (inferring from the usage of the word “class”), but I don’t think it really fits. Since there can be multiple types for a single object, it is much less akin to the object-oriented class and much closer to the concept of a type class or trait as seen in languages like Haskell or Rust. Seen in that light, it is perfectly natural to consider the type field to be a behavior-defining property.

@trwnh

imagine saying in plain english <this> <is a> <1b12 group>. now we need to know more about what <1b12 group> means.

Wouldn’t you need to know about FEP-1b12 in any case, even if you signified it through some other field, like constrainedBy? I mean you can’t get around the fact that you need some prior knowledge to understand a specific FEP.

@trwnh

how would you define that class? does that definition grant any useful logical properties? what happens if you want to break up 1b12 into specific behaviors?

I would define it through this FEP, which describes very usefully how I can expect that actor to behave.

I don’t see the problem in breaking it up into more specific behaviors - you just add more entries to the type field. Translated to programming-language lingo, adding an entry is akin to implementing a trait for an object in Rust, i.e. adding a set of behaviors. Traits/type classes can be arbitrarily specific and broken up.

[silverpill]

@SorteKanin

Seen in that light, it is perfectly natural to consider the type field to be a behavior-defining property.

In my experience, relying on type works great for activities, but for actors and objects defining behavior with properties is preferable. Because unless you’re developing a very specialized application, it needs to support all possible actors, and provide fallback representations for many kinds of objects.

[SorteKanin]

I’m not sure I understand entirely what you mean - why do I need to support all possible actors, but not activities? Why isn’t it the same? I.e. there is no expectation that an implementation covers all possible activities, why is actors different? Could you elaborate a bit perhaps?

[silverpill]

Activity represents an action, and software can’t perform action that it doesn’t understand.
Actors are entities that all behave in a certain way, so all of them can be supported.

There is no expectation to support all possible actors, and today many implementations have a hard-coded list of supported actor types. I am just saying that this is not necessary. My implementation duck-types actors and objects and it works great.

[SorteKanin]

@silverpill

Actors are entities that all behave in a certain way, so all of them can be supported.

I mean, I wouldn’t say that’s true seeing as this FEP defines an actor that works in a particular way. Not all actors work the same. And any FEP could define a new actor that may work entirely differently. But anyways.

@silverpill

In my experience, relying on type works great for activities, but for actors and objects defining behavior with properties is preferable.

@silverpill

My implementation duck-types actors and objects and it works great.

Is this to say that you just look for certain properties and if those properties exist, you expect certain behavior? That kinda comes back to what I said at the start:

@SorteKanin

But I don’t think you should use the presence of those fields to decide that a Group actor follows this FEP - an explicit signal in the type would be preferable.

I mean it can certainly work, but that feels very brittle and I could imagine it would easily lead to confusing behavior for actors that work differently than others.

But okay, with this duck-typing approach, how would you handle deciding between the Group that this FEP describes and another kind of group? Like, say FEP-example described a group similar to a Facebook group, with a list of members, a feed of posts that you can add to and maybe some events or something in a calendar. Perhaps unlike an FEP-1b12 Group, you need to be invited to this kind of group or something (point is, this group behaves differently).

I would say that it would be very confusing if you treated an FEP-1b12 Group actor the same as a FEP-example Group actor. From a UX perspective, I feel that you’d need to treat these groups differently. But I feel that a duck-typing approach would have a hard time figuring out that these groups are in fact distinct types of actors. Or maybe you have a way that would work?

[silverpill]

@SorteKanin

I mean, I wouldn’t say that’s true seeing as this FEP defines an actor that works in a particular way. Not all actors work the same. And any FEP could define a new actor that may work entirely differently.

Not entirely differently. All ActivityPub actors:

• Can be addressed in activities (via to and cc properties)
• Have inbox to which those activities should be delivered.
• Can perform activities (the actor property).
• Have outbox where activities performed by them are collected.

@SorteKanin

But okay, with this duck-typing approach, how would you handle deciding between the Group that this FEP describes and another kind of group? Like, say FEP-example described a group similar to a Facebook group, with a list of members, a feed of posts that you can add to and maybe some events or something in a calendar. Perhaps unlike an FEP-1b12 Group, you need to be invited to this kind of group or something (point is, this group behaves differently).

The group in FEP-example will probably have some property like members which we can use as capability indicator.
For FEP-1b12 groups I would use a boolean flag.

[SorteKanin]

@silverpill

For FEP-1b12 groups I would use a boolean flag.

Right, you did mention that before, that’s fair. I wouldn’t really call an explicit boolean flag like that duck typing, but sure.

Still curious what the Lemmy devs think of adding an explicit signal like this

[how]

I’m not sure how that disqualifies my proposal. If you take it into the larger context of all FEPs, you could imagine defining terms in those FEPs, that can then be used as intended, to define specific terms. FEP-1b12 could then define a version of group matching specific behavior defined in the FEP. Other FEPs could extend this behavior, or fork it into another meaning. But since the FEP would bring proper context, interactors would be able to use the right behavior, without having to invent new specific terms that would soon clutter the namespace into something beyond human understanding.

[trwnh]

If there were terms defined, and there was a context document resolvable, then yes, maybe.

For example, if this context were resolvable at https://w3id.org/fep/xxxx:

{
  "@context": {
    "Foo": "https://term.example/foobar/SomeType"
  }
}

You could then reference it like so:

{
  "@context": [
    "https://w3id.org/fep/xxxx",
    "https://www.w3.org/ns/activitystreams"
  ],
  "type": ["Object", "Foo"]
}

Where Foo maps to the IRI https://term.example/foobar/SomeType and therefore the document is equivalent to:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": ["Object", "https://term.example/foobar/SomeType"]
}

But this is irrelevant if the FEP-xxxx doesn’t define any terms or doesn’t make a context document available via FEP-888d.

The other problem is that you’re not allowed/supposed to override terms defined in the normative https://www.w3.org/ns/activitystreams context. So you can’t expect to define a Group term that is anything other than https://www.w3.org/ns/activitystreams#Group without it breaking things.

For example, this is forbidden:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "Group": "https://w3id.org/fep/xxxx/Group"
    }
  ]
  "type": "Group"
}

But this is allowed:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "GroupThatAnnouncesActivities": "https://w3id.org/fep/xxxx/Group"
    }
  ]
  "type": ["Group", "GroupThatAnnouncesActivities"]
}

You just run into ambiguity issues where there are infinitely many possible ways to express the same thing in plain JSON. So either you require all consumers to understand and expand according to context declarations… or you do not use any additional contexts.

Hence, the unambiguous document below:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": ["Group", "https://w3id.org/fep/xxxx/Group"]
}

Can also be equivalently expressed with any arbitrary prefix:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "foo": "https://w3id.org/fep/xxxx/"
    }
  ]
  "type": ["Group", "foo:Group"]
}

Or it can be equivalently expressed with any arbitrary term:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "1b12Group": "https://w3id.org/fep/xxxx/Group"
    }
  ]
  "type": ["Group", "1b12Group"]
}

So putting this stuff in type is just opening up a lot of unnecessary complexity, by making the values vocab-relative and therefore subject to IRI expansion according to context declarations.

For further examples of using or not using additional context, see https://w3id.org/fep/1985/orderType which has examples of both.

[stevebate]

@SorteKanin

Right, you did mention that before, that’s fair. I wouldn’t really call an explicit boolean flag like that duck typing, but sure.

I agree it’s not duck typing. It’s just an alternate ad hoc explicit typing technique. I think multityping is a better (and standard) approach.

[SorteKanin]

@trwnh

So putting this stuff in type is just opening up a lot of unnecessary complexity, by making the values vocab-relative and therefore subject to IRI expansion according to context declarations.

Isn’t that true for any field in JSON-LD?

The unambiguous version you wrote seems intuitively the best and most obvious way to do it, I really don’t see why you need to abbreviate or redefine the term.

[trwnh]

Not entirely; for document-relative IRIs you only need to worry about prefixes and base.

{
"@context": {"thisDoesNothing": "https://foo.example/something-that-doesnt-end-in-a-hash-or-slash"},
"@id": "https://foo.example/object",
"https://foo.example/property": {"@id": "https://foo.example/value"}
}

On the other hand…

{
  "@context": {
    "prefix-that-works": "https://foo.example/"
  },
  "@id": "prefix-that-works:object",
  "prefix-that-works:property": {
    "@id": "prefix-that-works:value"
  }
}

In the simplest case, the sum of both proposals (type and property) is this (with no additional context):

{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "something"
"type": ["Group", "https://w3id.org/fep/xxxx/Group"],
"https://www.w3.org/ns/ldp#constrainedBy": {"@id": "https://w3id.org/fep/1b12"}
}

This translates to the following statements (with some label substitution):

<something> <is a> <https://www.w3.org/ns/activitystreams#Group>.
<something> <is a> <https://w3id.org/fep/xxxx/Group>.
<something> <is constrained by> <https://w3id.org/fep/1b12>.

Note that the two latter statements serve loosely the same purpose, but the “is a” type declaration is not directly semantically useful. The “is constrained by” relation directly relates to FEP-1b12 in this case. You don’t need to define additional terms or classes. You don’t need to modify FEP-1b12 either.

I still need to think about the best way to orchestrate these kinds of constraint or profile definitions while writing a FEP, but for now you can say that the “is constrained by” relation is mostly human-meaningful for now, and maybe it can be machine-described later (using some profile vocabulary or ontology).

[SorteKanin]

@trwnh

The “is constrained by” relation directly relates to FEP-1b12 in this case. You don’t need to define additional terms or classes. You don’t need to modify FEP-1b12 either.

Ah so you mean the https://www.w3.org/ns/ldp#constrainedBy term is kind of a global way of signifying that an object is constrained by an FEP, without having to define anything about that in the FEP itself? I guess I can see the value in that. I think the type solution would have been preferred if the FEP was not already final.

Well in any case it’d be great if Lemmy and co. could implement some kind of solution as proposed here to more explicitly signal that the groups used in those implementations are of the kind defined in this FEP. Right now an ad-hoc duck-typing approach by examining arbitrary fields is the only option to figure out if a group is actually an FEP-1b12 group.

[nutomic]

Changing the type of groups is definitely not possible because that would completely break backwards compatibility. It would be possible to add a field like "isFEP1b12Group": true but that wouldnt help you with older Lemmy versions or other platforms that dont bother adding it.

If you want to implement a different group type with member list, post feed or similar then you need to add new attributes to your group for those anyway. So what you do is check that the group has these attributes, and ignore it if not. For Ibis Im going to do the same. It uses FEP-1b12 so that data can be fetched from Lemmy, but to prevent Ibis from fetching Lemmy groups it will reject any groups without articles json attribute.

[SorteKanin]

@nutomic

If you want to implement a different group type with member list, post feed or similar then you need to add new attributes to your group for those anyway. So what you do is check that the group has these attributes, and ignore it if not.

This doesn’t sound particular scalable, if we imagine more group implementations coming - and what if I want to support both FEP-1b12 groups and another group implementation at the same time? I’d need to decide on the group types according to some ad-hoc rules of which groups have which properties? Again, I really think an explicit signal is preferable here.

@nutomic

Changing the type of groups is definitely not possible because that would completely break backwards compatibility.

Strictly speaking it is only adding a type (and retaining the existing Group type), which should be totally backwards-compatible. The type field has always been polymorphic and any implementation should be prepared for the possibility that there is more than 1 type in that field.