FEP-2c59: Discovery of a Webfinger address from an ActivityPub actor

Standards Fediverse Enhancement Proposals
, ,
43

How will this be related to or reconciled with name and preferredUsername as currently implemented by Mastodon-like servers? It feels like embedding presentation-related preferences into the aliases collection ordering will lead to confusion. It also doesn’t fully specify the presentation considerations, such as how the preferred alias (possibly something other than an acct: URI), will be transformed for presentation and display purposes.

Mastodon doesn’t generally follow this policy. For example, in displayed posts, I am often referred to @steve rather than by my domain-qualified Mastodon account “handle”.

44

+1 for a more generic property. Maybe sameAs or a similar name would make a difference between it and alsoKnownAs a bit more clear.

I have a use case in FEP-ef61 where a yet-to-be-decided property needs to specify identifiers that resolve to the same object. I think this is sufficiently close to the Webfinger use case, especially considering @trwnh’s idea to skip JRD.

45

The reasons I like using XRD aliases are

  1. The semantics are reasonably well understood already, because everyone already implements WebFinger
  2. Someone else (the XRD WG) already documented them
  3. This allows you to skip WF in the ActivityPub id to acct: handle direction. If you broaden this concept more widely into a syntax for transferring XRDs/JRDs, then it also directly gives us a method to do what @trwnh proposed with skipping JRD by basically defining a syntax for JRD-in-JSON-LD/AS2
46

The current way Mastodon (and most implementations) handle this doesn’t align with what the spec says, in a way that’s deeply unfortunate

As the spec says:

preferredUsername
A short username which may be used to refer to the actor, with no uniqueness guarantees.

There’s a reason its termed “preferredUsername” and not just “username”

Presentational characteristics are really implementation specific but I think we can encourage

  • If wishing to display the user’s “name”, use the display name
  • If wishing to display the user as a plain “handle”, just use preferredUsername alone (and expect it to be non-unique)
  • If wishing to display a “user@domain” ID, use the first acct: URI in the aliases list
  • If wishing to present a HTTPS URI for the user, use the “url” property (as is done today)
47

In my understanding, WebFinger in Fediverse is used as a serialization of Web Linking to establish a self link from an acct: resource to an Activity Streams actor, and I wonder if we can also formalize the reverse discovery in terms of the Web Linking framework.

Come to think of it, Activity Vocabulary helpfully defines the Link type, which serves as a JSON-LD serialization of Web Linking. So I think we can use it to link an Activity Streams actor to an acct: resource, like the following:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://social.example.com/users/1",
  "type": "Person",
  "name": "John Doe",
  "url": [
    "https://social.example.com/@John",
    {
      "type": "Link",
      "href": "acct:John@example.com",
      "rel": "alternate"
    }
  ]
}

I think the benefit of this approach is that it can be expressed in the core Activity Vocabulary terms without inventing an extension property or borrowing an external vocabulary.

1 Like
48 
    "webfinger": {
      "@id": "wf:webfinger",
      "@type": "xsd:string"
    }

IIUC, JSON-LD strings are xsd:string by default (https://www.w3.org/TR/2020/REC-json-ld11-20200716/#data-model: “A JSON-LD value is […], a string (which is interpreted as a typed value with type xsd:string), […].”) so I think the expanded term definition can simply be "webfinger": "wf:webfinger".

1 Like
49

Pleroma seems to have started to signal the webfinger property:

1 Like
50

I wrote a short FEP describing the aliases property: feps/d2da/fep-d2da.md at main - silverpill/feps - Codeberg.org. However, I don’t need this property anymore, so this FEP will likely remain unpublished.

For the specific use case discussed here, webfinger seems to be good enough.