forgejo-contrib-federation-issues-71.md
Watch21
Star82
Fork
You've already forked federation
CodeIssues 16Pull requests 8Projects 2ActivityActions
resource format specification #71Open
opened 2025-11-10 20:02:11 +01:00 by 0xllx0 · 7 comments
0xllx0 commented 2025-11-10 20:02:11 +01:00
Collaborator
Copy link
In the Milestone 2 description, it is suggested to use the format @user@[email protected] for federated search of a remote repository.
After discussion with @famfo, an alternative format @[email protected] could be used to match the WebFinger RFC. Because + is in the subdelim set of characters from the acct URI RFC, it likely wouldn't require any code changes for existing ActivityPub implementations. Using @ might require some code changes, since it is in the gendelim set, which is not a valid userpart character set.
There is still some potential for ambiguity using the + character as a delimiter, since it could also be included in a valid username, or an organization name. So, introducing the new format @user@[email protected] may end up being the more workable format.
Each @ symbol would be percent-encoded:
GET /.well-known/webfinger?
resource=acct%3A%40user%40org%40instance.url
This encoding also matches with the acct URI RFC:
In order to use
her email address as the localpart of the ’acct’ URI, the at-sign
character (U+0040) needs to be percent-encoded as described in
[RFC3986]. Thus, the resulting ’acct’ URI would be
"acct:juliet%[email protected]".
Parsing would be trivial:
@https://instance.url/org/userIn the Milestone 2 description, it is suggested to use the format @user@[email protected] for federated search of a remote repository. After discussion with @famfo, an alternative format @[email protected] could be used to match the WebFinger RFC. Because + is in the subdelim set of characters from the acct URI RFC, it likely wouldn't require any code changes for existing ActivityPub implementations. Using @ might require some code changes, since it is in the gendelim set, which is not a valid userpart character set. There is still some potential for ambiguity using the + character as a delimiter, since it could also be included in a valid username, or an organization name. So, introducing the new format @user@[email protected] may end up being the more workable format. Each @ symbol would be percent-encoded: GET /.well-known/webfinger? resource=acct%3A%40user%40org%40instance.url This encoding also matches with the acct URI RFC: In order to use her email address as the localpart of the ’acct’ URI, the at-sign character (U+0040) needs to be percent-encoded as described in [RFC3986]. Thus, the resulting ’acct’ URI would be "acct:juliet%[email protected]". Parsing would be trivial: - split on @ - check number of parts - match parts to their semantic object - convert to local URI, e.g. https://instance.url/org/user
0xllx0 added this to the Milestone 2: Federated Search milestone 2025-11-10 20:02:11 +01:00
silverpill commented 2025-11-10 20:13:23 +01:00
Copy link
Because + is in the subdelim set of characters from the acct URI RFC, it likely wouldn't require any code changes for existing ActivityPub implementations
Some implementations further restrict the set of allowed characters in username. Mastodon might be one of them, it only allows alphanums, dot, hyphen and underscore, if I remember correctly.
>Because + is in the subdelim set of characters from the acct URI RFC, it likely wouldn't require any code changes for existing ActivityPub implementations Some implementations further restrict the set of allowed characters in username. Mastodon might be one of them, it only allows alphanums, dot, hyphen and underscore, if I remember correctly.
👍 1
0xllx0 commented 2025-11-10 21:22:33 +01:00
Author
Collaborator
Copy link
Some implementations further restrict the set of allowed characters in username.
I think it may make sense to extend either the ForgeFed, or upstream ActivityPub spec with a Search activity type.
We could base it on the current conventions used by existing implementations, like Mastodon, GoToSocial, Lemmy, etc.
This is something we briefly discussed, and I think an FEP with ActivityPub to codify the convention could be a good way forward. That way ForgeFed would inherit the spec.
Mastodon might be one of them, it only allows alphanums, dot, hyphen and underscore, if I remember correctly.
That sounds like it could allow us to move forward with either + or @, and codify that in whichever spec extension. Am somewhat partial to using @ because it is currently in the Milestone text. It also has precedence in the acct spec, and the convention used by Mastodon: search for @[email protected] extends to @user@[email protected]. It could just as easily extend to @[email protected]. This might be where the preference for what is in the Milestone text, and the acct spec example might be the deciding factors. 🤷
> Some implementations further restrict the set of allowed characters in username. I think it may make sense to extend either the ForgeFed, or upstream ActivityPub spec with a Search activity type. We could base it on the current conventions used by existing implementations, like Mastodon, GoToSocial, Lemmy, etc. This is something we briefly discussed, and I think an FEP with ActivityPub to codify the convention could be a good way forward. That way ForgeFed would inherit the spec. > Mastodon might be one of them, it only allows alphanums, dot, hyphen and underscore, if I remember correctly. That sounds like it could allow us to move forward with either + or @, and codify that in whichever spec extension. Am somewhat partial to using @ because it is currently in the Milestone text. It also has precedence in the acct spec, and the convention used by Mastodon: search for @[email protected] extends to @user@[email protected]. It could just as easily extend to @[email protected]. This might be where the preference for what is in the Milestone text, and the acct spec example might be the deciding factors. 🤷
0xllx0 referenced this issue from forgejo/forgejo 2025-11-13 17:35:25 +01:00 federation: add federated search for repository #10107
famfo referenced this issue 2026-01-20 11:46:20 +01:00 doc: add federated search documentation #74
famfo commented 2026-01-20 11:48:59 +01:00
Collaborator
Copy link
I don't think that we need any spec extensions to use a certain acct separator in Forgejo. The only requirement for Forgejo is local uniqueness since this concerns the mapping of repositories to actors using webfinger.
I don't think that we need any spec extensions to use a certain acct separator in Forgejo. The only requirement for Forgejo is local uniqueness since this concerns the mapping of repositories to actors using webfinger.
famfo referenced this issue from forgejo/forgejo 2026-01-20 14:30:04 +01:00 federation: add federated search for repository #10107
famfo commented 2026-01-20 14:36:24 +01:00
Collaborator
Copy link
Something I have missed before, the format of an acct URI is slightly different:
acctURI = "acct" ":" userpart "@" host
userpart = unreserved / sub-delims
0*( unreserved / pct-encoded / sub-delims )
A second "@" would have to be pct encoded.
Something I have missed before, the format of an acct URI is slightly different: acctURI = "acct" ":" userpart "@" host userpart = unreserved / sub-delims 0*( unreserved / pct-encoded / sub-delims ) A second "@" would have to be pct encoded.
0xllx0 commented 2026-01-20 16:35:39 +01:00
Author
Collaborator
Copy link
@famfo wrote in #71 (comment):
I don't think that we need any spec extensions to use a certain
acctseparator in Forgejo. The only requirement for Forgejo is local uniqueness since this concerns the mapping of repositories to actors using webfinger.
A second "@" would have to be pct encoded.
The percent encoding of the second "@" symbol would work with the current WebFinger (and related) specifications.
The extension we might want to add, once we decide on the final format, would be to standardize that format for other implementations to use. Whether that means that we percent encode one of the "@" symbols, or if we extend the spec to not need to percent encode.
Also, if we decide to percent encode an "@" symbol, which one do we consider the "first" symbol, and which additional ones would need to be percent encoded?
@famfo wrote in https://codeberg.org/forgejo-contrib/federation/issues/71#issuecomment-10002207: > I don't think that we need any spec extensions to use a certain acct separator in Forgejo. The only requirement for Forgejo is local uniqueness since this concerns the mapping of repositories to actors using webfinger. > A second "@" would have to be pct encoded. The percent encoding of the second "@" symbol would work with the current WebFinger (and related) specifications. The extension we might want to add, once we decide on the final format, would be to standardize that format for other implementations to use. Whether that means that we percent encode one of the "@" symbols, or if we extend the spec to not need to percent encode. Also, if we decide to percent encode an "@" symbol, which one do we consider the "first" symbol, and which additional ones would need to be percent encoded?
famfo commented 2026-01-20 16:47:35 +01:00
Collaborator
Copy link
@0xllx0 wrote in #71 (comment):
The extension we might want to add, once we decide on the final format, would be to standardize that format for other implementations to use.
If we are following the standard, we do not have to standardize things.
@0xllx0 wrote in #71 (comment):
or if we extend the spec to not need to percent encode.
We're not going to change the RFC
@0xllx0 wrote in #71 (comment):
Also, if we decide to percent encode an "@" symbol, which one do we consider the "first" symbol, and which additional ones would need to be percent encoded?
According to the standard, everything after the "@" is the hostname.
@0xllx0 wrote in https://codeberg.org/forgejo-contrib/federation/issues/71#issuecomment-10008024: > The extension we might want to add, once we decide on the final format, would be to standardize that format for other implementations to use. If we are following the standard, we do not have to standardize things. @0xllx0 wrote in https://codeberg.org/forgejo-contrib/federation/issues/71#issuecomment-10008024: > or if we extend the spec to not need to percent encode. We're not going to change the RFC @0xllx0 wrote in https://codeberg.org/forgejo-contrib/federation/issues/71#issuecomment-10008024: > Also, if we decide to percent encode an "@" symbol, which one do we consider the "first" symbol, and which additional ones would need to be percent encoded? According to the standard, everything after the "@" is the hostname.
0xllx0 commented 2026-01-20 21:32:39 +01:00
Author
Collaborator
Copy link
@famfo wrote in #71 (comment):
According to the standard, everything after the "@" is the hostname.
My point was, the userpart can contain any number of pct-encoded "@" symbols. Even in an example from RFC 7565:
GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1
The single "@" symbol is not the literal, but percent encoded.
We're not going to change the RFC
Did I suggest we would? I was talking about adding either an ActivityPub FEP or ForgeFed enhancement to standardize how WebFinger discovery works. It would be an extension of existing specs.
@famfo wrote in https://codeberg.org/forgejo-contrib/federation/issues/71#issuecomment-10009125: > According to the standard, everything after the "@" is the hostname. My point was, the userpart can contain any number of pct-encoded "@" symbols. Even in an example from RFC 7565: GET /.well-known/webfinger?resource=acct%3Abob%40example.com HTTP/1.1 The single "@" symbol is not the literal, but percent encoded. > We're not going to change the RFC Did I suggest we would? I was talking about **adding** either an ActivityPub FEP or ForgeFed enhancement to standardize how WebFinger discovery works. It would be an extension of existing specs.
Sign in to join this conversation.
No Branch/Tag specified
main
feat/add-generated-threat-analysis
n0toose/admin-panel
n0toose/readme-forgefed-mention
n0toose/ap-username-changes
ap-username-changes-for-pr-9254
adr-signing-and-encryption
No results found.
Labels Clear labels No items
No labels
Milestone
Clear milestone
No items
No milestone Milestone 2: Federated Search
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
Notifications Subscribe
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
No due date set.
Dependencies
No dependencies set.
Reference
forgejo-contrib/federation#71
WritePreview
Loading…
Add table
| Rows | | | Columns | |
CancelOK
Add a link
Url Description Hint: With a URL in your clipboard, you can paste directly into the editor to create a link.
CancelOK
CancelSave
Reference in a new issue
Repository
forgejo-contrib/federation
Title
Body
Create issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
No Yes