FEP-c648: Blocked Collection

[eprodrom]

The value of the blockedOf property of a collection is the actor for whom the collection is the value of its blocked property. It is the inverse property of blocked . As with other ActivityPub properties, the blockedOf property MAY be referenced in the actor by id or as an embedded node object.

[aschrijver]

I was referring to how descriptive it is or isn’t without the need to consult the spec.

[eprodrom]

I don’t think that’s a design goal.

[eprodrom]

What is the benefit of these new terms versus as:attributedTo ?

First, when a client gets the collection ID, you can tell pretty quickly that it is the blocks or blocked collection of an actor. So, the client might not let the user Add or Remove from the collection directly, since it’s a special collection managed directly by the server.

A fallback is to use the attributedTo property, and then fetch that actor and check if the blocked or blocks property is identical to the ID (or is an embedded object, or whatever). That’s perfectly fine, too; blockedOf or blocksOf saves a tiny bit of ambiguity.

I’m trying to provide inverse properties when I can to give more clarity and information, especially when it’s a one-to-one relationship. If you don’t find them useful, and can’t imagine your users finding them useful, just leave them out.

[eprodrom]

On a different topic, the way the FEP is written implies that Block-related collections literally exist in and are managed in the server (see the “Processing requirements” section). However, the dereferenced collections are generally just serializations of some internal server representations of blocking relationship.

You’re right; it’s an abstraction. I don’t think it would be clearer to say, “modify your internal representation so that the collection object you produce will appear to have a new object in it.”

I think the properties would be more clear if they were named something like blockedActors and blockActivities . I find myself repeatedly going back to the FEP to try to determine if I should use blocks or blocked .

I think the names are fine, and I’ve already implemented them, so I’m not going to change them.

If I just implement blocked and not the reverse properties, would my software still be considered an implementation of this FEP?

The properties are there for you to use if you want, as a tool to help other clients and servers interact with your software. If you use them, please structure the objects they refer to in the way described in this document. If you don’t do that, clients or other servers will not be able to use the information in those objects as easily or effectively; they’ll have to special case their software for your implementation.

[aschrijver]

@eprodrom

I don’t think that’s a design goal.

Is your naming proper English formulation that I can use in a sentence? Does it equate to good ubiquitous language that is broadly understood, intuitive? That would serve best in the specs. Or is blocked_of a kind of technical notation, maybe a convention in naming linked data relationships, and therefore useful?

“You can find that in blockedOf.”

“Blocked off? Who is blocked off?.”

[stevebate]

@eprodrom

You’re right; it’s an abstraction. I don’t think it would be clearer to say, “modify your internal representation so that the collection object you produce will appear to have a new object in it.”

I completely agree. That wouldn’t be clearer although it’s about the same level of abstraction as the current wording in the FEP.

@eprodrom

I think the names are fine, and I’ve already implemented them, so I’m not going to change them.

Thanks for letting me know. It’s sometimes difficult to determine if an FEP is intended to be documentation one’s personal AP project or a call for community discussion and consensus.

@eprodrom

they’ll have to special case their software for your implementation.

Or, if someone publishes an alternative FEP for this topic, a developer may need to special-case their software for your implementation.

[aschrijver]

@stevebate

It’s sometimes difficult to determine if an FEP is intended to be documentation one’s personal AP project or a call for community discussion and consensus.

They are generally a call for feedback, and improvement to the text that is to the discretion of the author, as is the implementation of course. Then afterwards the spec lives on to inform the broader dev community.

[eprodrom]

@stevebate

It’s sometimes difficult to determine if an FEP is intended to be documentation one’s personal AP project or a call for community discussion and consensus.

It’s absolutely a call for discussion, but this FEP is at its final feedback stage. It’s already been through multiple rounds of renaming and rewrites. You can always define synonym terms as mnemonics:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://purl.archive.org/socialweb/blocked",
        { "blockedActors": "bl:blocked",
        "blockActivities": "bl:blocks" }
     ]
}

@stevebate

Or, if someone publishes an alternative FEP for this topic, a developer may need to special-case their software for your implementation.

Let’s hope that if someone does that, they use another namespace, in which case nobody has to special-case anything.

[eprodrom]

I disagree. I think parallelism for inverse properties is more important:

inbox ↔ inboxOf
followers ↔ followersOf
liked ↔ likedOf
blocked ↔ blockedOf

If it’s important to you, you can define a synonym as a mnemonic:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://purl.archive.org/socialweb/blocked",
        { "blockedCollectionOf": "bl:blockedOf" }
     ]
}

[eprodrom]

Oh, I forgot to note: using inverse properties helps with spoofing, too. If A claims that A has a property with value B, it can help to check that B has the inverse property with value A. Probably less of a problem with blocks and blocked but a worthwhile habit to get into.