FEP-4adb: Dereferencing identifiers with webfinger


Please use this thread to discuss [FEP-4adb(https://codeberg.org/fediverse/fep/src/branch/main/fep/4adb/fep-4adb.md) and any potential problems or improvements that can be addressed.

In this FEP, we will formalize the process of derefencing an URI using webfinger in order for usage in ActivityPub. The main goal is to enable the usage of URIs of the form acct:user@domain or did:example:12345 as ids for objects used in ActivityPub. While this FEP only discusses this in the context of actors, it should be applicable for general objects. In order for a smooth introduction, it is recommended to start deployment with actor objects.

This FEP first presents the algorithm and examples, then discusses the usage in the context of the Fediverse. This means the first two sections are for people wanting to implement this FEP, the following sections are for people wanting to decide if this FEP is a good idea.

Full text: FEP-4adb: Dereferencing identifiers with webfinger

cc: @helge

1 Like

I’d like to suggest considering the adding nostr:pubkey:<pubkey>, where the pubkey is a 64-character, lowercase hexadecimal key.

I’m currently in the process of developing a dereference function for this element. The function would be capable of retrieving this information either from relays or cached content available on the web.

To provide a clearer understanding, here are some practical applications:

  1. A standard profile: Profile Example
  2. A well-known profile: Well-known Profile Example
  3. JSON-LD auto discovery: JSON-LD Auto Discovery Example

Although it’s still early days, I’m actively working on a website, some libraries, documentation and a social graph to support this feature.

I believe this addition could greatly enhance ability to interop with other like minded communities in the FLOSS eco system.

Consideration of this idea would be greatly appreciated!

I think you need to write an email to somebody to get nostr included in Uniform Resource Identifier (URI) Schemes. Specifying the format is not even necessary then.

Once this is done the FEP covers Nostr. Nostr will have the same problem of did-key to verify the authority of using that handle.

@helge thanks for the response. I will look into this with the Nostr Community Group and the wider nostr community.

An interesting application of webfinger is data cloning.

Imagine that object IDs are not URLs, but URNs:

    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:360bd565-07d1-4478-866e-3cbdc041b234",
    "type": "Note",
    "attributedTo": "https://alice.example/user",
    "content": "Hello world"

The ID here is location-independent, so the object is not tied to a particular server. However, it is not clear how it can be retrieved. We can solve this problem by adding a list of servers to the ID:


Here is a reply to this Note:

    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "urn:uuid:42a0c931-9d1a-41c9-b4dc-3070c4204674?hosts=bob.example,backup.example",
    "type": "Note",
    "attributedTo": "https://bob.example/user",
    "inReplyTo": "urn:uuid:360bd565-07d1-4478-866e-3cbdc041b234?hosts=alice.example,backup.example",
    "content": "Test"

The recipient of this reply can use webfinger to find a referenced object:

GET https://backup.example/.well-known/webfinger?resource=urn:uuid:360bd565-07d1-4478-866e-3cbdc041b234

This approach provides redundancy without the downsides of using hashlinks, ipfs:// URIs or other immutable pointers.

The integrity of objects can be proved using FEP-8b32 integrity proofs.

1 Like

cc @silverpill @codenamedmitri

I feel it would be useful to include the mechanism proposed in fep/fep-ae97.md at main - fep - Codeberg.org of using


in order to specify where the lookup should happen in this FEP. Do either of you see any problem that would arise?

Is this a behavior one should mention in the Did-core W3C issues ?

1 Like

I also feel that hosts= might be in scope of this FEP.
I haven’t given it much thought, but in theory it should work. Maybe there needs to be a separate endpoint that will translate DIDs (and other URIs) to ActivityPub objects in one step, but WebFinger is a good starting point.

Overall, I like the idea behind this FEP. However, I have a few questions.

If the document was received through a POST request and doesn’t contain an id , or the id is an URI, the domain the POST request originated from should be used.

Is there an example of this case in the FEP? How will the “domain the POST request originated from” be determined? HTTP Referer header? DNS reverse lookup based on the remote IP address of the network socket?

The “id is an URI” phrase in that sentence is a bit confusing to me. A URL is a URI, but the algorithm requires using the domain of the URL for the WebFinger query. Should it be “id is a URI without a domain”?

It also seems like you’d want to use the URI authority (or at least domain[:port]) rather than just the domain/hostname. For example, …

  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://chatty.example:9999/ben/456",
  "type": "Note",
  "attributedTo": "did:key:z6MkekwC6R9bj9ErToB7AiZJfyCSDhaZe1UxhDbCqJrhqpS5",
  "to": "acct:alyssa@social.example",
  "content": "Hello"

Wouldn’t you want to use https://chatty.example:9999/.well-known/webfinger for the lookup (including the port)?

This is more of a general FEP question. I see this FEP from @helge and FEP-ef61 from @silverpill both define the ‘aliases’ term, but differently. It looks they have the same semantics. If so, is there any concern about the multiple term definitions with the same compact “aliases” name?

I will likely change property name in FEP-ef61 to something less ambiguous like sameAs.

1 Like

A small clarification request/question. In the FEP the algorithm specifies a step 2 like so:

  1. Determine the link property with "type":"application/activity+json".

Could filtering for the media type instead of the relation return something not intended, taking into account that Webfinger can theoretically provide multiple links for the same rel and return them in a priority order of preference.

Would it be better to clarify to filter for rel=self and type=application/activity+json or is it irrelevant and already guaranteed?

I might be missing something fundamental as I am quite new on understanding the literature, which is quite a significant amount.