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.
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
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.
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
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.
- Backwards compatibility with legacy implementations
- Filter the
attachment array for items of type
content from each remaining item.
- If none are found, filter the
attachment array for items of type
http://schema.org#value from each remaining item.
If actor has both
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#value from each remaining item if there is no
Note with the same
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 and optionally
- otherwise, take
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.)
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.
The updated algorithm still discards legacy items if
Link attachments are present (If none are found, filter…). Isn’t deduplication a better strategy?
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.
I think consuming impls should be more forgiving and use deduplication. Consider the following edge case:
- The publisher uses legacy
PropertyValue for profile metadata, but also adds a payment link (with
- The recipient accepts attachment with type
Link and stops processsing.
- Metadata fields are getting ignored.
Two new commits added to the PR:
- “If none are found” → “If none are found (or if items remain in the set of
- 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
name if present, take one of
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?
So you want to allow attachments without
type, like this one?
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…
I’m trying to think of cases where
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?
I can’t think of an object with
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.