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.