FEP-fb2a: Actor metadata

Standards Fediverse Enhancement Proposals
1

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.

1 Like
2

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.

@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.

3

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.

1 Like
4

is this something new or a better way to encode mastodon’s tables?

5

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.

1 Like
6
  1. Backwards compatibility with legacy implementations
    …
  • 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.

If actor has both Note and PropertyValue attachments, this algorithm will discard all attachments of the second type.
Wouldn’t it be better to deduplicate by name instead?

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 there is no Note with the same name.

7

hmm, at time of writing i think i meant it more like “check if there are any Notes, if not, then fall back to your old logic”

looking back at it, i think it is unnecessarily restrictive as indeed you could deduplicate by name if you simply didn’t care about type. you could reduce the FEP to something like this:

  • for each item,
    • if has href, take href and optionally name. *
    • otherwise, take name and content. if you can’t take content, take the incorrect schema:value instead.

*(this is something i want to add to make it compatible with the payment links FEP and also links in general, such as rel-me links to potentially replace current usage of alsoKnownAs in a backwards-compatible way)

*(also the reason name is optional is because you may just have a set of links, maybe some of them have rel and that might be all you need. it’s up to implementation details. but using a name is still recommended so i might make it a SHOULD on links.)

1 Like
8

I saw Streams server sending Note attachment and decided to try FEP-fb2a as well. For now, I implemented only the receiving side, with a deduplication by name if there’s a mix of Note’s and PropertyValue’s.

1 Like