Hello!
This is a discussion thread for the proposed FEP-fb2a: Actor Metadata. Please use this thread to discuss the proposed FEP and any potential problems or improvements that can be addressed.
Summary
It is useful for actors to publish additional structured information about themselves without necessarily defining an extension property or additional vocabulary. This FEP describes a way for actors to publish generic key-value pairs representing their metadata.
General-purpose actor metadata fields SHOULD be included in the
attachmentarray 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.
@trwnh If a more specific property doesn’t exist in ActivityStreams vocabulary, what would you recommend? Is it preferable to use an attachment with a more specific type or to define a new property?
It seems to me that grouping similar things under the same property makes more sense.
The intention is to support generic name-value pairs, but without using unnecessary external vocabularies.
By “specific properties”, I meant vocabulary with a better-fitting semantic meaning. If you wanted to define or use an existing property definition for “age” or “pronouns”, you could do that… perhaps your implementation supports something like schema.org and actually makes use of its properties (instead of just PropertyValue and value). But if you didn’t want to do this (or if you otherwise wanted to keep things simple), you could just use generic metadata as defined here.
It is possible there might be some duplication if you want to support some extension or other vocab, and also have that information visible to ActivityPub-only implementations. Say you wanted to share your email to anyone viewing your profile. You might put that information in schema:email, but you might also put that info in a generic profile field as actor metadata (attached Note with name = email, content = your email address), and/or you might put it directly into your bio (using as:summary). Any or all three are valid.
is this something new or a better way to encode mastodon’s tables?
Largely just a more generic way to do “bio fields” / “profile fields” / etc as seen on Mastodon, Pleroma, and Misskey
The problem with those is that they depend on a broken definition for the schema.org context – Mastodon’s context currently/historically defines a term schema which maps to the base IRI http://schema.org#, but it should map to http://schema.org/ or https://schema.org/ instead. When you expand this with JSON-LD, you get http://schema.org#PropertyValue instead of http://schema.org/PropertyValue, which breaks parsing.
There is Fix schema.org context while preserving compatibility with older Mastodon versions by ClearlyClaire · Pull Request #18393 · mastodon/mastodon · GitHub which attempts to migrate from the “incorrect” to the “correct”, but it requires a complicated hacky solution that amounts to basically issuing each field twice in two separate attachment fields, which must be compacted in order to be understood by anyone special-casing the old behavior, and doesn’t really clean things up much for the new behavior. And after all this, you still depend on the schema.org namespace for just this one feature.
Therefore, the goal of the FEP is to propose a simpler alternative: Just use Note/name/content instead of PropertyValue/name/value. Why it wasn’t done like this in the first place years ago is beyond me.