[TRACKING] FEP-d556: Server-Level Actor Discovery Using WebFinger

silverpill commented

2024-01-20 21:50:45 +01:00

Owner

The proposal has been received. Thank you!

This issue tracks discussions and updates to the proposal during the DRAFT period.

Please post links to relevant discussions as comment to this issue.

dateReceived: 2024-01-20

If no further actions are taken, the proposal may be set by editors to WITHDRAWN on 2025-01-19 (in 1 year).

The [proposal](https://codeberg.org/fediverse/fep/src/branch/main/fep/d556/fep-d556.md) has been received. Thank you! This issue tracks discussions and updates to the proposal during the `DRAFT` period. Please post links to relevant discussions as comment to this issue. `dateReceived`: 2024-01-20 If no further actions are taken, the proposal may be set by editors to `WITHDRAWN` on 2025-01-19 (in 1 year).

silverpill added the

FEP Draft

label

2024-01-20 21:50:45 +01:00

silverpill commented

2024-01-20 21:53:56 +01:00

Author

Owner

Discussion: https://socialhub.activitypub.rocks/t/fep-ceee-instance-level-actor-discovery-using-webfinger/3861

silverpill referenced this issue

2024-01-20 21:54:16 +01:00

FEP-ceee Instance-Level Actor Discovery using WebFinger #242

silverpill commented

2024-01-21 02:43:09 +01:00

Author

Owner

FEP updated via #247

silverpill changed title from ~~[TRACKING] FEP-ceee: Instance-Level Actor Discovery using WebFinger~~ to [TRACKING] FEP-d556: Server-Level Actor Discovery Using WebFinger

2024-01-27 20:00:50 +01:00

silverpill commented

2024-01-27 20:03:08 +01:00

Author

Owner

FEP updated via #251

silverpill commented

2024-07-22 15:40:46 +02:00

Author

Owner

FEP updated via #377

FEP updated via https://codeberg.org/fediverse/fep/pulls/377

silverpill commented

2024-10-26 17:28:12 +02:00

Author

Owner

FEP updated via #429

silverpill commented

2025-02-19 22:12:35 +01:00

Author

Owner

FEP updated via #506

FEP updated via https://codeberg.org/fediverse/fep/pulls/506

silverpill added

FEP Final

and removed

FEP Draft

labels

2025-03-16 18:58:08 +01:00

silverpill commented

2025-03-16 18:58:31 +01:00

Author

Owner

Finalized: #522

Finalized: https://codeberg.org/fediverse/fep/pulls/522

jerger commented

2025-06-02 14:41:42 +02:00

The general idea seems to help in our case get-public-key as sketched out here:

meissa/forgejo#18/files

But I request to make this spec more precise for following questions:

How exactly is the instance resource constructed?
1. What happens if the server is not working on default port? How exactly the port will be part of initial webfinger request (e.g. GET /.well-known/webfinger?resource=https://server.example:9000/) ? Context of this question is described here: https://codeberg.org/meissa/federation/src/branch/federated-user-activity-following/doc/user-activity-following/manual-test.md
2. Are other schemes beside of https supported (e.g. GET /.well-known/webfinger?resource=http://server.example/) ?
3. What happens with trailing path (GET ...?resource=http://server.example/ vs. GET ...?resource=http://server.example)
4. What happens with uppercase chars (e.g. GET /.well-known/webfinger?resource=Https://Server.example) ? Normalization is not part of webfinger spec ...
Pls. define the response more exact - at least to find a way to the public key material. I think it should be easy & uniform to bootstrap the key exchange which is at the moment hard & implemented different.
1. Describe a minimum set of rels MUST be present ( e.g. "rel": "https://www.w3.org/ns/activitystreams#Service" or singleton)
2. Describe the minimum requirement for the Service rel.
  1. The Actor linked MUST provide a public key and
  2. MUST be type-of Application (as implemented in Mastodon) or Service (as implemented in GTS) - having just one spec conform type would be a cool improvement :-)

The general idea seems to help in our case get-public-key as sketched out here: https://codeberg.org/meissa/forgejo/pulls/18/files But I request to make this spec more precise for following questions: 1. How exactly is the instance resource constructed? 1. What happens if the server is not working on default port? How exactly the port will be part of initial webfinger request (e.g. GET /.well-known/webfinger?resource=https://server.example:9000/) ? Context of this question is described here: https://codeberg.org/meissa/federation/src/branch/federated-user-activity-following/doc/user-activity-following/manual-test.md 2. Are other schemes beside of `https` supported (e.g. `GET /.well-known/webfinger?resource=http://server.example/`) ? 3. What happens with trailing path (`GET ...?resource=http://server.example/` vs. `GET ...?resource=http://server.example`) 4. What happens with uppercase chars (e.g. `GET /.well-known/webfinger?resource=Https://Server.example`) ? Normalization is not part of webfinger spec ... 2. Pls. define the response more exact - at least to find a way to the public key material. I think it should be easy & uniform to bootstrap the key exchange which is at the moment hard & implemented different. 1. Describe a minimum set of rels MUST be present ( e.g. "rel": "https://www.w3.org/ns/activitystreams#Service" or singleton) 2. Describe the minimum requirement for the Service rel. 1. The Actor linked MUST provide a public key and 2. MUST be type-of `Application` (as implemented in Mastodon) or `Service` (as implemented in GTS) - having just one spec conform type would be a cool improvement :-)

silverpill commented

2025-06-04 12:17:24 +02:00

Author

Owner

Pinging the author of this proposal: @steve-bate

It has the FINAL status, but FEP process permits minor changes as long as they don't affect existing implementations.

Pinging the author of this proposal: @steve-bate It has the `FINAL` status, but FEP process permits minor changes as long as they don't affect existing implementations.

steve-bate commented

2025-06-05 07:23:08 +02:00

Contributor

Hello @jerger, I reviewed the changelist and the WebFinger usage wasn't clear to me. However, I can still address some of your comments and questions.

For the first group of questions, this is covered by the WebFinger and URI specifications. The resource query parameter is a URI rfc3986. Based on the URI specification: ports are allowed, non-https schemes are allowed (e.g., 'http', 'acct:', 'did:', 'urn:', ...), a trailing slash is a different URI than one without the slash (different number of path segments), and the hostname component of a URI (if any) is case-insensitive (but lowercase is recommended).

For the second group of comments, this sounds like an excellent candidate for a short use case-specific FEP based on the general FEP-d556 proposal.

(As a side note: I self-host a forgejo instance and I'm a big fan of the project. Thanks for your work on it.)

Hello @jerger, I reviewed the changelist and the WebFinger usage wasn't clear to me. However, I can still address some of your comments and questions. For the first group of questions, this is covered by the WebFinger and URI specifications. The `resource` query parameter is a URI [rfc3986](https://www.rfc-editor.org/rfc/rfc3986). Based on the URI specification: ports are allowed, non-https schemes are allowed (e.g., 'http', 'acct:', 'did:', 'urn:', ...), a trailing slash is a different URI than one without the slash (different number of path segments), and the hostname component of a URI (if any) is case-insensitive (but lowercase is recommended). For the second group of comments, this sounds like an excellent candidate for a short use case-specific FEP based on the general FEP-d556 proposal. (As a side note: I self-host a forgejo instance and I'm a big fan of the project. Thanks for your work on it.)

daenney commented

2025-11-05 16:26:42 +01:00

I'm looking at the FEP and there is something that is unclear to me, specifically as it affects setups that use a split-domain:

Accounts use domain.tld
API domain/URIs use sub.domain.tld

In this case, the Server Actor account URI is (typically) acct:sub.domain.tld@domain.tld with an actor URL along the lines of https://sub.domain.tld/sub.domain.tld.

When trying to request the instance actor, which of the two domains should the request be expected for? Since typically you'd request acct:local@domain.tld, it stands to reason it should be https://domain.tld/. But if a request were to come in for https://sub.domain.tld/, should that elicit the same response?

I'm looking at the FEP and there is something that is unclear to me, specifically as it affects setups that use a split-domain: * Accounts use `domain.tld` * API domain/URIs use `sub.domain.tld` In this case, the Server Actor account URI is (typically) `acct:sub.domain.tld@domain.tld` with an actor URL along the lines of `https://sub.domain.tld/sub.domain.tld`. When trying to request the instance actor, which of the two domains should the request be expected for? Since typically you'd request `acct:local@domain.tld`, it stands to reason it should be `https://domain.tld/`. But if a request were to come in for `https://sub.domain.tld/`, should that elicit the same response?

daenney commented

2025-11-05 17:39:00 +01:00

There's one other thing I'm not eniterly clear on. The spec states:

The subject would typically be the resource URI. This proposal does not depend on any specific URI for subject, although the ActivityPub actor URI is recommended.

However, it's also possible for the document to return multiple server level actors, as it shows later on in the spec. In that case, the recommendation of using the Actor URI seems like it wouldn't work, as there can be multiple. Since this is about discovering server-level actors, shouldn't the subject always be the instance/server domain?

There's one other thing I'm not eniterly clear on. The spec states: > The subject would typically be the resource URI. This proposal does not depend on any specific URI for subject, although the ActivityPub actor URI is recommended. However, it's also possible for the document to return multiple server level actors, as it shows later on in the spec. In that case, the recommendation of using the Actor URI seems like it wouldn't work, as there can be multiple. Since this is about discovering server-level actors, shouldn't the `subject` always be the instance/server domain?

Rows
Columns

[TRACKING] FEP-d556: Server-Level Actor Discovery Using WebFinger #243