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
9

#156 - Update FEP-fb2a to be compatible with profile links and provide more examples - fep - Codeberg.org submitted, targeting the above discussed changes.

1 Like
10

The updated algorithm still discards legacy items if Note or Link attachments are present (If none are found, filter…). Isn’t deduplication a better strategy?

11

i suppose it’s a matter of preference, but i can mention a deduplication strategy if you want, yeah. i think the assumption is that legacy implementations will publish the exact same set, but twice. so the duplication rate is 100%, and you can process either set. it would not be a good idea to publish different sets of profile fields in the legacy vs FEP format.

12

I think consuming impls should be more forgiving and use deduplication. Consider the following edge case:

  1. The publisher uses legacy PropertyValue for profile metadata, but also adds a payment link (with Link type).
  2. The recipient accepts attachment with type Link and stops processsing.
  3. Metadata fields are getting ignored.
13

Two new commits added to the PR:

  • “If none are found” → “If none are found (or if items remain in the set of attachment)”
    • this change should allow the option of continuing processing
  • append to end: “If name is a duplicate of an existing name, ignore the item.”
    • this allows picking up new legacy fields while not overriding FEP-format fields

At this point the only uncertainty I have is whether the type inclusion is better as a MUST or as a SHOULD. An alternative algorithm that does no filtering is to just iterate once over the set of attachment, take name if present, take one of http://schema.org#value or content or href, and if it’s an href (i.e. a Link) then check for rel. Based on what you have taken, convert it to a profile field or a link or whatever application-specific abstraction you are using (i.e. if you are constructing mastodon-style profile fields then you filter for name, but if you are constructing youtube-style channel links then you filter for href). So if it’s not actually “required” then maybe it shouldn’t be a MUST?

14

So you want to allow attachments without type, like this one?

{
    "name": "abc",
    "content": "xyz"
}

An algorithm that doesn’t take type into account would enable forward compatibility. However, I see two algorithms as mutually exclusive: either you’re relying on types, or you’re using heuristics. The FEP should recommend only one of them, but implementers may have different opinions about the best one…

15

I’m trying to think of cases where name and content don’t make a “profile field” out of something inside attachment. Basically, what would you possibly put in an actor’s attachment set that takes that form, but isn’t profile metadata? There’s a sort of implicit statement in the whole FEP that attachment is for actor metadata. I’m not sure what other metadata you can put in there aside from name-value pairs, or links with a possible link relation (and maybe a label). The “breakpoint” is essentially, can we predict or foresee a future usage of an attachment that has a name but isn’t metadata for that actor?

16

I can’t think of an object with name and content properties that is not profile metadata.
However, FEP-c390 identity proofs are attachments that can not be easily converted into metadata fields (and probably shouldn’t). So the door for non-metadata attachments is already open.