PropertyValue attachments serialize with invalid type for AS2 Object/Link validation

[rmdes]

Description

When Fedify serializes actor attachment properties containing PropertyValue items (used by Mastodon for profile metadata fields), the resulting JSON-LD uses schema:PropertyValue as the type:

"attachment": [
  {
    "type": "PropertyValue",
    "name": "Website",
    "value": "<a href=\"https://example.com\">example.com</a>"
  }
]

The ActivityPub spec defines attachment as containing AS2 Object or Link types. PropertyValue is a schema.org type (https://schema.org/PropertyValue), not an ActivityStreams type. Strict validators like browser.pub reject this:

/attachment: ❌ Invalid object, Invalid link
/attachment/0/name: ✅ Valid activity property
/attachment/0/name: ✅ Valid xsd:string
/attachment/1/name: ✅ Valid activity property
/attachment/1/name: ✅ Valid xsd:string
/endpoints: ✅ Valid @id
/endpoints: ✅ Valid activity property
/endpoints: ✅ Valid single-value
/endpoints: ❌ Invalid endpoints, unknown properties: type (@type)
/endpoints/type: ❌ Type not found: as:Endpoints
/endpoints/sharedInbox: ✅ Valid @id
/endpoints/sharedInbox: ✅ Valid activity property
/endpoints/sharedInbox: ✅ Valid single-value
/endpoints/sharedInbox: ✅ Valid ordered collection

See the debug view on this page

Context

This is the same class of issue as #576 (Endpoints serializing with invalid as:Endpoints type), but for a different non-AS2 type. The PropertyValue type is used universally across the fediverse (Mastodon, Pleroma, Misskey, etc.) for profile metadata fields, so removing it would break compatibility.

The Dilemma

Unlike Endpoints, this is tricky because:

1. Mastodon expects PropertyValue — removing the type breaks profile field display across the fediverse
2. AS2 spec says attachment should contain Object or Link — PropertyValue is neither
3. Every major fediverse server emits PropertyValue — it's a de facto standard despite not being in the AS2 vocabulary

Questions

1. Is this something Fedify could address (perhaps by including the schema.org context so PropertyValue is properly defined)?
2. Or is this a browser.pub strictness issue where the validator should accept widely-used extensions like PropertyValue?
3. Should PropertyValue be treated similarly to how Mastodon's toot: namespace extensions are handled?

Environment

• Fedify: ^1.10.3 (also affects 2.0)
• Discovered via browser.pub validation of a Fedify-powered ActivityPub server

[dahlia]

Thank you for reporting this. As you noted, this is indeed the same class of issue as #576 (Endpoints), but with a key difference: unlike Endpoints, we cannot simply remove the @type from PropertyValue because Mastodon and other fediverse software rely on it to identify profile metadata fields.

Here's my assessment:

What Fedify is already doing correctly

Fedify's actor serialization already includes the schema.org mapping in its JSON-LD @context:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "schema": "http://schema.org#",
      "PropertyValue": "schema:PropertyValue",
      "value": "schema:value"
    }
  ]
}

This means PropertyValue is properly defined within the JSON-LD document. The validation failure comes from browser.pub enforcing strict AS2 vocabulary constraints on the attachment property (which the spec defines as Object | Link), rather than accepting widely-used extensions.

The real problem: a de facto standard without formal specification

PropertyValue in attachment is used by virtually every fediverse implementation (Mastodon, Pleroma, Misskey, GoToSocial, Akkoma, etc.), but it has never been formally specified. Defining a new type like toot:PropertyValue that extends AS2 Object would theoretically solve the type hierarchy issue, but the migration cost would be enormous—every implementation would need to support both old and new forms, and the transition period would effectively never end (especially given the existing URI confusion between http://schema.org#PropertyValue and http://schema.org/PropertyValue).

Suggested path forward

I think the most practical approach is to formalize the existing practice through a FEP (Fediverse Enhancement Proposal) rather than inventing a new type. A FEP documenting the current schema:PropertyValue usage as an official extension would:

1. Give validators like browser.pub a specification to reference for accepting PropertyValue
2. Document the http://schema.org#PropertyValue URI quirk (vs. the canonical http://schema.org/PropertyValue)
3. Avoid any breaking changes across the fediverse

Since there's nothing actionable on Fedify's side—we're already serializing PropertyValue correctly with proper JSON-LD context—I'll close this issue for now. If a FEP gets written and suggests implementation changes, we can revisit.