From ee17b7dc740c10cf041bf4585011a67edc4b7380 Mon Sep 17 00:00:00 2001 From: a Date: Thu, 7 Sep 2023 12:56:10 -0500 Subject: [PATCH 1/6] Update FEP-fb2a to be compatible with profile links and provide more examples --- fep/fb2a/fep-fb2a.md | 103 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 99 insertions(+), 4 deletions(-) diff --git a/fep/fb2a/fep-fb2a.md b/fep/fb2a/fep-fb2a.md index 9b4acf6..44d3d11 100644 --- a/fep/fb2a/fep-fb2a.md +++ b/fep/fb2a/fep-fb2a.md @@ -26,25 +26,120 @@ Rather than depending on an additional (and unnecessary) vocabulary, it makes se Thus, we can define a standard for actor metadata, largely drawing from prior art. -## 2. Defining actor metadata +## 2. Defining generic actor metadata as key-value pairs General-purpose actor metadata fields SHOULD be included in the `attachment` array on the actor. If a more specific property exists and is a better fit for the specific metadata being expressed, then implementations MAY use that instead of or in addition to the more generic actor metadata. -- Each metadata field MUST have a type of `Note`. +- Each generic metadata field SHOULD have a type of `Note`. - Each metadata field MUST have a property of `name` representing the name (key) of the field. - Each metadata field MUST have a property of `content` representing the content (value) of the field. -## 3. Backwards compatibility with legacy implementations +## 3. Defining generic actor metadata as links + +Actor metadata fields may also take the form of a link rather than a content value. + +- Each generic link SHOULD have a type of `Link`. +- Each link field MUST have a property of `href` representing the value of the link. +- Each link field SHOULD have a property of `name` representing a label for the link. +- Each link field SHOULD use `rel` values if an appropriate link relation exists. + +## 4. Backwards compatibility with legacy implementations of profile fields using incorrect schema.org IRIs (This section is non-normative.) -Existing implementations currently using `http://schema.org#PropertyValue` and `http://schema.org#value` may wish to maintain backwards compatibility during a transitional period. The following algorithm may be used to support the legacy implementations while also favoring the implementation within this FEP: +Existing implementations currently using the incorrect IRIs `http://schema.org#PropertyValue` and `http://schema.org#value` may wish to maintain backwards compatibility during a transitional period by serving both legacy representations as well as representations according to this FEP. The following algorithm may be used to support the legacy implementations while also favoring the implementation within this FEP: - Filter the `attachment` array for items of type `Note`. Take `name` and `content` from each remaining item. - If none are found, filter the `attachment` array for items of type `http://schema.org#PropertyValue`. Take `name` and `http://schema.org#value` from each remaining item. After some transitional period, implementations may wish to simplify their logic by filtering only for items of type `Note` and drop support for `http://schema.org#PropertyValue`, `http://schema.org#value`, and the schema.org context entirely (assuming those implementations do not use any other vocabulary from the schema.org context). +## 5. Examples of current legacy implementations compared to serialization according to this FEP + +Consider a profile which has the following profile fields: + +``` +Pronouns +: they/them + +My portfolio +: https://example.com/ +``` + +A legacy implementation might currently serialize these as such: + +``` +{ + "@context": [ + "https://www.w3.org/ns/activitystreams", + { + "sc": "http://schema.org#" + "PropertyValue": "sc:PropertyValue", + "value": "sc:value" + } + ], + "id": "https://social.example/someone" + "type": "Person", + "attachment": [ + { + "type": "PropertyValue", + "name": "Pronouns", + "value": "they/them" + }, + { + "type": "PropertyValue", + "name": "My portfolio", + "value": "example.com" + } + ] +} +``` + +For implementations that do not include the same incorrect IRI term mapping in their contexts, compaction would result in the following: + +``` +{ + "@context": "https://www.w3.org/ns/activitystreams", + "id": "https://social.example/someone" + "type": "Person", + "attachment": [ + { + "type": "http://schema.org#PropertyValue", + "name": "Pronouns", + "http://schema.org#PropertyValue": "they/them" + }, + { + "type": "http://schema.org#PropertyValue", + "name": "My portfolio", + "http://schema.org#PropertyValue": "example.com" + } + ] +} +``` + +Implementation according to this FEP might result in a simpler and more semantically correct serialization but equivalent representation like so: + +``` +{ + "@context": "https://www.w3.org/ns/activitystreams", + "id": "https://social.example/someone" + "type": "Person", + "attachment": [ + { + "type": "Note", + "name": "Pronouns", + "content": "they/them" + }, + { + "type": "Link", + "name": "My portfolio", + "href": "https://example.com", + "rel": ["nofollow", "noopener", "noreferrer", "me"] + } + ] +} +``` + ## References - [ActivityPub] Christine Lemmer Webber, Jessica Tallon, [ActivityPub](https://www.w3.org/TR/activitypub/), 2018 From 5e1eb94eedbae3f6b7f46ab1e6644570bba99811 Mon Sep 17 00:00:00 2001 From: a Date: Thu, 7 Sep 2023 13:08:48 -0500 Subject: [PATCH 2/6] Add note about legacy verification of rel-me links --- fep/fb2a/fep-fb2a.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fep/fb2a/fep-fb2a.md b/fep/fb2a/fep-fb2a.md index 44d3d11..c1bcc5b 100644 --- a/fep/fb2a/fep-fb2a.md +++ b/fep/fb2a/fep-fb2a.md @@ -49,7 +49,7 @@ Actor metadata fields may also take the form of a link rather than a content val Existing implementations currently using the incorrect IRIs `http://schema.org#PropertyValue` and `http://schema.org#value` may wish to maintain backwards compatibility during a transitional period by serving both legacy representations as well as representations according to this FEP. The following algorithm may be used to support the legacy implementations while also favoring the implementation within this FEP: -- Filter the `attachment` array for items of type `Note`. Take `name` and `content` from each remaining item. +- Filter the `attachment` array for items of type `Note` or `Link`. Take `name` and `content` from each remaining item if the type is `Note`, or take `name` and `href` if the type is `Link`. If the type is `Link` and the `rel` contains `"me"`, attempt to verify this link using rel-me verification. - If none are found, filter the `attachment` array for items of type `http://schema.org#PropertyValue`. Take `name` and `http://schema.org#value` from each remaining item. After some transitional period, implementations may wish to simplify their logic by filtering only for items of type `Note` and drop support for `http://schema.org#PropertyValue`, `http://schema.org#value`, and the schema.org context entirely (assuming those implementations do not use any other vocabulary from the schema.org context). From c048d08d40acda9d7d6d8ba819543416f01fa37f Mon Sep 17 00:00:00 2001 From: a Date: Thu, 7 Sep 2023 13:09:50 -0500 Subject: [PATCH 3/6] Bump type inclusion from SHOULD -> MUST in order to make filtering easier --- fep/fb2a/fep-fb2a.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fep/fb2a/fep-fb2a.md b/fep/fb2a/fep-fb2a.md index c1bcc5b..ef4b281 100644 --- a/fep/fb2a/fep-fb2a.md +++ b/fep/fb2a/fep-fb2a.md @@ -30,7 +30,7 @@ Thus, we can define a standard for actor metadata, largely drawing from prior ar General-purpose actor metadata fields SHOULD be included in the `attachment` array on the actor. If a more specific property exists and is a better fit for the specific metadata being expressed, then implementations MAY use that instead of or in addition to the more generic actor metadata. -- Each generic metadata field SHOULD have a type of `Note`. +- Each generic metadata field MUST have a type of `Note`. - Each metadata field MUST have a property of `name` representing the name (key) of the field. - Each metadata field MUST have a property of `content` representing the content (value) of the field. @@ -38,7 +38,7 @@ General-purpose actor metadata fields SHOULD be included in the `attachment` arr Actor metadata fields may also take the form of a link rather than a content value. -- Each generic link SHOULD have a type of `Link`. +- Each generic link MUST have a type of `Link`. - Each link field MUST have a property of `href` representing the value of the link. - Each link field SHOULD have a property of `name` representing a label for the link. - Each link field SHOULD use `rel` values if an appropriate link relation exists. From 7c335c93da324bcccb24ff042f28735ad530602e Mon Sep 17 00:00:00 2001 From: a Date: Thu, 7 Sep 2023 13:11:09 -0500 Subject: [PATCH 4/6] Add mention of rel-me to requirements for profile links --- fep/fb2a/fep-fb2a.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fep/fb2a/fep-fb2a.md b/fep/fb2a/fep-fb2a.md index ef4b281..8c2006a 100644 --- a/fep/fb2a/fep-fb2a.md +++ b/fep/fb2a/fep-fb2a.md @@ -41,7 +41,7 @@ Actor metadata fields may also take the form of a link rather than a content val - Each generic link MUST have a type of `Link`. - Each link field MUST have a property of `href` representing the value of the link. - Each link field SHOULD have a property of `name` representing a label for the link. -- Each link field SHOULD use `rel` values if an appropriate link relation exists. +- Each link field SHOULD use `rel` values if an appropriate link relation exists, such as `"me"`. ## 4. Backwards compatibility with legacy implementations of profile fields using incorrect schema.org IRIs From dafe0a5faeaeff52016af1aeda9ddeec4e67b85e Mon Sep 17 00:00:00 2001 From: a Date: Mon, 11 Sep 2023 22:25:07 -0500 Subject: [PATCH 5/6] Suggest continuing processing if items remain --- fep/fb2a/fep-fb2a.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fep/fb2a/fep-fb2a.md b/fep/fb2a/fep-fb2a.md index 8c2006a..92e8015 100644 --- a/fep/fb2a/fep-fb2a.md +++ b/fep/fb2a/fep-fb2a.md @@ -50,7 +50,7 @@ Actor metadata fields may also take the form of a link rather than a content val Existing implementations currently using the incorrect IRIs `http://schema.org#PropertyValue` and `http://schema.org#value` may wish to maintain backwards compatibility during a transitional period by serving both legacy representations as well as representations according to this FEP. The following algorithm may be used to support the legacy implementations while also favoring the implementation within this FEP: - Filter the `attachment` array for items of type `Note` or `Link`. Take `name` and `content` from each remaining item if the type is `Note`, or take `name` and `href` if the type is `Link`. If the type is `Link` and the `rel` contains `"me"`, attempt to verify this link using rel-me verification. -- If none are found, filter the `attachment` array for items of type `http://schema.org#PropertyValue`. Take `name` and `http://schema.org#value` from each remaining item. +- If none are found (or if items remain in the set of `attachment`), filter the `attachment` array for items of type `http://schema.org#PropertyValue`. Take `name` and `http://schema.org#value` from each remaining item. After some transitional period, implementations may wish to simplify their logic by filtering only for items of type `Note` and drop support for `http://schema.org#PropertyValue`, `http://schema.org#value`, and the schema.org context entirely (assuming those implementations do not use any other vocabulary from the schema.org context). From 92182b8473b86f9621ed8fa0fc950b4d95a25085 Mon Sep 17 00:00:00 2001 From: a Date: Mon, 11 Sep 2023 22:25:52 -0500 Subject: [PATCH 6/6] Add mention of deduplication strategy --- fep/fb2a/fep-fb2a.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fep/fb2a/fep-fb2a.md b/fep/fb2a/fep-fb2a.md index 92e8015..a089c38 100644 --- a/fep/fb2a/fep-fb2a.md +++ b/fep/fb2a/fep-fb2a.md @@ -50,7 +50,7 @@ Actor metadata fields may also take the form of a link rather than a content val Existing implementations currently using the incorrect IRIs `http://schema.org#PropertyValue` and `http://schema.org#value` may wish to maintain backwards compatibility during a transitional period by serving both legacy representations as well as representations according to this FEP. The following algorithm may be used to support the legacy implementations while also favoring the implementation within this FEP: - Filter the `attachment` array for items of type `Note` or `Link`. Take `name` and `content` from each remaining item if the type is `Note`, or take `name` and `href` if the type is `Link`. If the type is `Link` and the `rel` contains `"me"`, attempt to verify this link using rel-me verification. -- If none are found (or if items remain in the set of `attachment`), filter the `attachment` array for items of type `http://schema.org#PropertyValue`. Take `name` and `http://schema.org#value` from each remaining item. +- If none are found (or if items remain in the set of `attachment`), filter the `attachment` array for items of type `http://schema.org#PropertyValue`. Take `name` and `http://schema.org#value` from each remaining item. If `name` is a duplicate of an existing `name`, ignore the item. After some transitional period, implementations may wish to simplify their logic by filtering only for items of type `Note` and drop support for `http://schema.org#PropertyValue`, `http://schema.org#value`, and the schema.org context entirely (assuming those implementations do not use any other vocabulary from the schema.org context).